Aaron Levie on Enterprise AI Agents: Engineering Leads the Way, Finance Must Solve Accountability First

At WorkOS's init() fireside chat, Box CEO Aaron Levie shared his observations on bringing enterprise AI agents into organizations. As a founder who has long worked in enterprise content management and collaboration, Levie's perspective spans frontline engineering practice and the decision-making logic of large organizations. His core judgment: when AI agents enter the enterprise, technology is only the tip of the iceberg — the real obstacle is how organizations redistribute power and responsibility.

Why Engineering Teams Become the First Users of AI Agents

Levie points out that engineering departments are almost always the first group in an enterprise to embrace AI agents. The reason isn't complicated: engineers' work output is inherently verifiable — whether code runs, whether tests pass, whether builds succeed are all instant feedback. This verifiability allows the agent's output quality to be quickly evaluated and iterated, and it also makes engineers more willing to hand real tasks to agents.

By contrast, work in legal, HR, and finance often involves ambiguous judgment and multiple stakeholders' interests, and agent output is hard to measure by a single standard. Levie's observation aligns with several recent industry surveys: penetration of developer-tool AI products is significantly higher than in general office scenarios. This isn't just a matter of technical maturity — it's directly tied to how measurable the work itself is.

Another factor Levie emphasizes is the fault tolerance of engineering culture. Engineers are used to tolerating imperfection across version iterations, while the culture of most traditional enterprise departments leans toward risk avoidance — creating tension with the fact that agents inevitably make mistakes early on.

"Verifiability" in the context of AI agents refers to whether task outcomes can be objectively judged right or wrong by automated means. Software engineering is special because it naturally has a complete feedback infrastructure: unit tests, CI pipelines, static type checking, code review, and other mechanisms that can tell users within seconds to minutes whether this output is usable. This mechanism makes the agent's trial-and-error cost extremely low — errors are quickly exposed, and correct patterns are quickly consolidated. But in scenarios like drafting legal documents, performance evaluations, or budget allocation, judging whether an output is "good" often takes days or even months to surface, and involves subjective trade-offs and multi-party negotiation, lacking a single ground truth. The level of verifiability directly determines whether an agent can enter the "generate—evaluate—correct" loop, which is the fundamental reason for the difference in adoption speed across departments.

The Accountability Problem in Banking: What's Needed Before an Agent Can Send a Wire Transfer

The sharpest example in the conversation came from the financial industry. Levie mentioned that if a bank wants to allow an AI agent to initiate wire transfer instructions, it must first solve a fundamental problem: when the agent makes a wrong decision, who bears the responsibility?

This isn't a matter of insufficient technical capability. With current model capabilities, an agent can fully handle steps like account verification, amount reconciliation, and compliance checks. But the bank's core demand is the integrity of the accountability chain — regulators need to know who authorized the transaction, who is responsible if something goes wrong, and how responsibility is divided between human and machine. Levie believes the answer to this question isn't at the model layer, but at the organizational architecture layer.

His judgment is that enterprises need to establish a conceptual framework for agents similar to a "job role" — clarifying permission boundaries, approval hierarchies, and escalation paths for exceptions. Only when an agent's rights and responsibilities are defined as clearly as a human employee's can the door to high-risk scenarios truly open.

The accountability chain is a core concept in the financial regulatory system, referring to the ability to trace every step of the entire process — from decision initiation, authorization, and execution to outcome — back to a clear responsible party. In the traditional banking system, this chain is safeguarded by human approval signatures, dual review, operation logs, and tiered permissions. When AI agents are introduced, "non-human actors" appear in the chain, and regulators (such as the Federal Reserve, the Office of the Comptroller of the Currency, and national supervisory authorities under the Basel Committee framework) require institutions to demonstrate: who authorized the agent to perform that action, whether the agent's decision basis is explainable, and who bears the loss when it occurs. This essentially requires incorporating agents into existing governance frameworks rather than creating a separate set of exemption rules for them. Therefore, the speed at which banks open up agent permissions often depends on whether their internal control and compliance departments can provide an accountability scheme acceptable to regulators, not on model capability itself.

Why Levie Supports the FDE Role's Value in Enterprise AI Deployment

In the conversation, Levie expressed clear support for the FDE (Forward Deployed Engineer) model. The core work of this role is not building general products, but going deep into the customer site, understanding specific business processes, and connecting AI capabilities with the organization's actual workflows.

This stance relates to Box's own practice. Enterprise customers' AI needs are highly fragmented — every company's data permission system, approval process, and compliance requirements differ, and standardized products struggle to cover them directly. The value of the FDE is to serve as a translation layer between product capabilities and customer reality — avoiding excessive customization that leads to runaway maintenance costs, while also preventing product teams from building in isolation.

Levie's view echoes a shift happening in the enterprise software industry: deploying AI agents increasingly resembles a hybrid of consulting and engineering rather than pure product delivery. For vendors accustomed to the subscription SaaS model, this means both delivery methods and talent structures need to be adjusted.

The FDE (Forward Deployed Engineer) model was first practiced at scale and popularized by Palantir. Its core idea is to station engineers directly at the customer site, working alongside business staff to quickly understand and respond to real needs. Unlike traditional pre-sales consultants or implementation engineers, FDEs typically have full product development capabilities and can write code on-site, build prototypes, and directly drive deployment. The advantage of this model is that it shortens the feedback loop between "customer need—product implementation," avoiding information distortion through multiple layers of transmission. The cost is high labor expense and difficulty scaling, so companies like Palantir offset customization overhead by consolidating reusable platform capabilities. Levie's support for the FDE reflects a reality at the current stage of the enterprise AI market: demand is highly fragmented, general products struggle to hit the mark directly, and engineering capability close to the front line remains key.

The Real Path for Agents Entering the Enterprise

Taken together, Levie's sharing shows a clear sequence for advancing enterprise AI agents: first open up ground in engineering scenarios where outcomes are verifiable and fault tolerance is high, then gradually extend to high-risk areas that require clear accountability mechanisms. Technical capability is only the entry ticket — organizational design is the key variable determining how far agents can go.

For enterprises planning agent deployment, Levie's reminder has practical significance: rather than agonizing over model selection, first answer the three questions of permissions, approval, and responsibility attribution. The answers to these questions often determine whether an agent project can move from pilot to production.

One-line Summary

Levie believes the real obstacle to enterprise AI agent deployment is organizational accountability design, not model capability

Paragraph Summary

At WorkOS's init() fireside chat, Box CEO Aaron Levie shared his observations on enterprise AI agent deployment. He noted that engineering teams — because their work output is inherently verifiable and their culture is highly fault-tolerant — are almost always the first group in an enterprise to adopt agents, while legal, finance, and other departments lag significantly due to ambiguous judgment and sensitivity to responsibility. The sharpest example came from banking: the prerequisite for allowing an agent to initiate wire transfers isn't technical capability, but clarifying responsibility attribution and the accountability chain between human and machine. Levie supports the FDE (Forward Deployed Engineer) model, believing that going deep into customer sites to connect with business workflows is key to current enterprise AI deployment. His core judgment: the real path for agents entering the enterprise starts with verifiable, fault-tolerant engineering scenarios, then extends to high-risk areas requiring clear permissions, approval, and responsibility attribution. For enterprises, answering questions of permissions, approval, and responsibility attribution matters more than agonizing over model selection.