Browse · Writeups
Every Agent Needs a Box
Enterprise agents need useful context, bounded access, a workspace, and human oversight. Making those pieces fit an organization is as much a workflow problem as a model problem.
Source and teaching reviews passed · Human editorial review pending.
The answer is in a file nobody opens
A new employee needs to understand a project. The answer may already exist in research, memos, or roadmap documents that colleagues stopped opening when their immediate work ended. Agents could make that information useful again: find it, answer questions, and use it to produce new work. That possibility anchors Every Agent Needs a Box, published March 5, 2026, where enterprise file management—permissions, sharing, and collaboration—becomes infrastructure for agents. That is the publication date; the recording date is unspecified.
Two operating models create different requirements: - An agent acting as its user accesses information through that user's authority. - An independent collaborator has its own computer, tools, and restricted working environment, with selected access to other people's information. The second model gives the conversation its proposed tagline: every agent needs a box. It needs somewhere to work, and Box sees a potential role for its enterprise content platform.
The security concern is concrete: malicious instructions could steer an agent through a customer-management system to retrieve data it should not reach. Permissions and data governance must bound that access across systems and workflows. Responsibility remains unsettled, particularly in financial services: an agent might face requirements analogous to a human's, or accountability might rest with whoever created or used it.
Oversight without unrestricted access
Aaron Levie argues that file-system access makes agent identity a problem Box must help solve alongside identity vendors. An ordinary employee account is an inadequate template. Employees have separate accounts and privacy expectations; an agent's creator needs oversight and, Levie expects, will bear substantial responsibility for its actions. That is an account-design argument and an expectation about liability, rather than a settled legal rule.
The hard case arises when an agent collaborates beyond its creator's permissions. It may work with another person on restricted documents while its creator remains responsible for supervising it. Visibility into the agent must not automatically expose the collaborator's work. Levie contrasts this with agents using a person's authenticated services in Claude Code, Cursor, and Codex: their authority follows the user. Independent agents need explicit boundaries among access, their own storage, and human supervision.
Sharing can also be finer-grained than a file: a person might show a colleague one passage without granting access to the whole document. The system described in response uses waterfall inheritance: sharing a node in the file tree grants access to everything below it. This supports collaboration at different levels of the tree, but leaves unresolved what a creator may inspect when an agent combines several people's information. These boundaries matter even in small organizations; an interviewer already needs them within a conference team.
Why coding gave agents a head start
Coding offers unusually favorable conditions for agents. Engineers commonly receive broad codebase access, much of the work is text-in and text-out, and models are heavily trained on code. AI developers also use coding agents themselves, creating a daily feedback loop between product limitations and improvements. Developers can install tools and exchange techniques without waiting for formal training.
A banker may instead need someone to grant access to a deal-room folder, obtain information from another organization, and recover requirements from customer calls or in-person conversations. Some context is restricted; some has never been digitized. A codebase does not contain everything an engineer knows either, but specifications and documentation give software a substantial head start over many other kinds of work.
The proposed transferable lesson is workflow adaptation. Developers changed their work to make agents effective, moving toward instructions and review. Other industries would need usable context, appropriate access, effective prompts, and training. The forecast is a multiyear transition, with early adopters potentially accumulating advantages as they learn.
How much must the customer change?
An interviewer challenges the reorganization prescription: a product requiring extensive consulting could lose to one that accommodates existing workflows. Real enterprise data contains duplicates, poor names, and outdated files. Requiring customers to clean everything up first creates a demanding sales prerequisite.
The response proposes a workable middle ground: authoritative, reasonably current information in predictable locations. Some process redesign remains necessary because a more capable model cannot reliably recover unavailable context. Better information management also gains two incentives: wrong inputs become more consequential when agents act on them, and disorganized companies risk missing productivity gains their competitors capture.
Internal Box agents illustrate the problem. Roughly nine months before the conversation, agents searching a full account reportedly often chose documents that looked relevant but were wrong. Pressure to respond promptly encouraged premature answers; a couple of failures could be enough for a knowledge worker to abandon the system.
The retrieval process fans out across multiple searches, gathers candidates, and lets the agent rank the documents. Opus 4.5 and Opus 4.6 reportedly improved at rejecting superficially plausible matches when their position in the file tree or expected access patterns conflicted with the question. Better judgment still depends on usable information. An informal diagnostic offered here is to ask whether a capable human could solve the retrieval task from the available material in five or ten minutes; if not, do not assume the agent can.
Search needs a stopping judgment
Context engineering here means selecting useful information from a large enterprise corpus for the model to work with. Putting every potentially relevant file into the prompt is considered too costly at the time of the conversation. An illustrative comparison sets ten million documents against a 60,000-token working budget. That budget is a conversational assumption, not a measured accuracy threshold; the point is how much selection remains necessary even with a large context window.
A recurring internal scenario asks an agent for addresses corresponding to ten named offices. No single document contains all the answers. Separate office documents exist, but an agent may return six addresses and say it cannot find the remaining four—a behavior described as especially common with lower-tier models, without a measured failure rate.
Not found is not the same as nonexistent. Another query might uncover an address, or the requested office might not exist. Reading every file to establish absence could be prohibitively expensive. The desired search behavior is adaptive: try different queries, check the results, and stop when further searching appears unlikely to help. Improvements in this judgment are reported, but no controlled result is given for the office-address task.
Reliability also depends on the deliverable. In the contract example, small variations across repeated generations could change the document an organization relies on. That differs from judging software through a working interface despite messy implementation underneath. Scope control is especially consequential in law and healthcare, and the comparison is explicitly narrowed to software after civil engineering is raised. Human managers must decide what they are accountable for reviewing, separately from questions of legal liability.
Keep the lesson, remove the failed trajectory
A participant reporting agentic-search stress tests describes agents repeating an action even after their reasoning trace recognizes it as a bad idea. The proposed explanation is that the failed trajectory—the sequence of attempted actions—remains in context as an example the model may imitate. Recognizing the mistake does not necessarily prevent repetition.
The suggested intervention is context pruning: remove the failed sequence while retaining a concise warning about what went wrong. This preserves the lesson without repeatedly presenting the unproductive path. Self-pruning is proposed as a promising capability, with no demonstrated improvement supplied here. It complements the stopping problem: an agent must judge both which paths deserve further exploration and which should leave its working context.
Evaluate the model and its harness
Box supported the Apex evaluation with information about professional data workspaces, including the documents lawyers and investment bankers use. Its own evaluation uses industry documents and a rubric of required outcomes. A one-shot model test evolved into an agentic evaluation of both the model and the harness, the surrounding system that enables the agent to perform its work.
The evaluation uses nonpublic data across roughly ten industries, including government filings, research data, financial data-room materials, and investment prospectuses. Models run in a constrained agent mode intended for like-for-like comparisons. Gains are reported between generations, including Sonnet 4.5 and Sonnet 4.6, but the spoken account lacks precise scores, a scoring scale, and resource budgets. Published industry results are selected examples rather than the entire evaluation.
Operationally, the evaluation answers two questions: - Which model should the team adopt or recommend? - Did a change to the agent introduce a regression? The broader prediction is that enterprises will need comparable tests for sales materials, proposal generation, and invoice processing. BrainTrust and LangSmith are mentioned favorably in this anticipated expansion of tools for inspecting and evaluating agent behavior.
Agents also become a third customer category for Box, alongside humans and applications. Their requirements reach into file systems, metadata, data management, and search. A core agent team, estimated at a few dozen people, draws on supporting teams while testing and discarding approaches. The effort operates like a startup within the company, supported by existing security, compliance, and governance capabilities.
A workspace for reading and writing
An agent needs storage for more than its inputs. It may read enterprise content to answer questions, then write a deliverable or intermediate working files. Reading is described as the harder problem so far because it requires selecting a small amount of useful information from a vast corpus. Storing content the model produces is comparatively straightforward.
Authoring introduces its own reliability problem: ask for an update to one PowerPoint slide, and fonts elsewhere may change or a shape may move. Those errors are immediately visible in the deliverable. Preserving the rest of the document is part of completing the edit.
Box's stated direction includes native agents powered by leading models, with a potentially larger opportunity in letting agents from any system use Box as their working file system. A separate agent workspace could hold memory files, specifications, Markdown, and generated PDFs, with human collaboration and sharing. These are conceptual plans that include capabilities not yet generally available.
The company cannot be documented once
Writing company processes into agent skills files does not finish the job. A customer, market, or internal decision can make last week's instructions stale. Humans are expected to supply those updates for now. Agent traces—the records of what agents did—also miss organizational activity that has never been captured or digitized.
Companies resemble apprenticeships in this account: employees spend one to three months absorbing tacit knowledge, the understanding colleagues carry without writing it down. Capturing it could shorten onboarding, reduce repeated work, and spread experienced employees' expertise. Those benefits still depend on permissions. Making information searchable does not make it appropriate for everyone to read; the company-as-filesystem idea must preserve the organization's access boundaries.
The knowledge-graph debate becomes a practical question about how much explicit structure is useful. More structured representations compete with simpler Markdown files, while everyday collaboration continues in Slack, Teams, Google Docs, and Box. The adoption analogy is the earlier expectation that entire enterprises would run through wikis: Confluence succeeded in engineering, but people also wanted flexible collaborative workspaces. The position is compatible with connecting to external graphs and letting agents work across systems.
One hypothesis is that useful relationships can emerge in an agent's understanding and evolve over time. A more concrete proposal is an agent-maintained wiki: linked Markdown files serving as persistent memory, with additional structure added when needed. DeepWiki is praised for helping both humans and agents, though its enterprise access controls are left open. The proposed pattern does not require a formal graph at the outset.
Delegation concentrates responsibility
The Box founder describes delegating most operations while staying involved in consequential choices: customer messaging, the sales pitch, and investment priorities. AI architecture, features, and platform interfaces receive much closer attention because he considers them existential. His operating principle is selective involvement, with leaders responsible for execution and strategic decisions made collaboratively.
Strong leaders still need meaningful ownership. Small decisions can compound into failure, but dictatorial control makes excellent people harder to hire. The founder's contribution is two decades of experience anticipating customer reactions, coupled with accepting ultimate responsibility. Quarterly business reviews and brand check-ins monitor delegated operations; agent and platform work receives continuous attention.
That intensity is explicitly portrayed as unhealthy. A planned late-night Zoom about agents leads into jokes about struggling to enjoy a party while paid-for compute sits idle. The humor captures a new pressure: even leisure time can feel like a missed opportunity to keep agents working.
Public writing, film, and company-building
Public writing serves as a feedback loop for running Box: encounter an internal problem, discuss it publicly, learn from others, and bring those lessons back into the business. The respondent says he writes his own posts, often using about twenty minutes of the evening commute to distill the day. He illustrates that longstanding impulse with an internship anecdote: he recalls losing a New York film-production internship shortly after asking whether he could blog about the experience.
Film also connects to Box's origins. An interest in bringing movies online ran into licensing difficulties, while a Paramount internship exposed how awkward traditional enterprise software made file sharing. Similar problems at school helped motivate the company.
The creative promise of AI filmmaking is easier access to ambitious production: a high-school student could attempt explosions and car chases. The accompanying concern is preserving distinctive artists and worthwhile films. Preferred uses include difficult computer-generated effects, plot exploration, previsualization, and backgrounds, surrounding a process that still includes actors, cameras, and direction.
One optimistic scenario is educational children's entertainment with more ambitious production quality. Animators might oversee more content with agents, but the employment implications remain explicitly unknown.
Company-building returns through a recollection placed around 2006: meeting Emily Melton at a Michael Arrington/TechCrunch house party led to an introduction to DFJ and Box's Series A. Asked how Latent Space could offer a similar launchpad, the response emphasizes gathering people at a formative moment. A contest is optional; short fundraising presentations could also connect founders and investors, while meetups could bring future collaborators together. An interviewer reports an additional community outcome—at least one marriage—followed by the necessary joke that the couple were humans.
Cheaper software makes adoption more important
Companies need direct channels to their audiences, and agents add another audience for technical communication. Developer relations, or DevRel, helps people discover and use technical services; the emerging task is also to make services discoverable and understandable to agents. The prescription is to treat media as a serious operating function, whether built internally or acquired.
Staffing creates a tension: strong communicators may prefer independent creator businesses. Equity-backed, part-time arrangements are proposed as one answer, while the other side emphasizes the need for full-time employees. Helping customers use services also extends into implementation inside their organizations, blurring the boundary with consulting.
The economic forecast is that more code and features per dollar will shift spending toward getting software adopted. More choice increases competition for attention; faster change increases customers' need for technical guidance. Building agents, deploying them, integrating systems, and helping people use them remain technical work. That is the basis for the optimistic engineering-career outlook.
An interviewer connects the AI-engineer theme to an early-2023 conviction that AI would amplify programming expertise. The closing argument challenges the idea that easier code generation removes the reason to learn programming. If enterprises build more of their own software, someone must still translate business problems into requirements, maintain systems, and update them. Engineering practices—and engineers themselves—could extend into more business functions.
How far custom systems will displace packaged software remains unresolved. The expectation is that software becomes more important as agents make more activities programmable. The participants close by acknowledging the obvious professional bias: three software people have reached an optimistic conclusion about software engineering.