loading
loading
init() fireside recap: Aaron Levie on the work of bringing agents into the enterprise Box CEO Aaron Levie at WorkOS init() on why engineering adopted agents first, what a bank must settle before an agent sends a wire, and why he backs FDE roles. Aaron Levie told the init() audience he had been with a bank that morning, where the question was when an agent should be allowed to make a wire transfer. Three years ago, he said, a bank would not have treated that as a serious problem. Now it is a live one, and only the first item on his list of open questions was about whether the agent can do the job. Levie, the CEO of Box, sat down with WorkOS founder and CEO Michael Grinich for the first session after lunch at init() on October 7, 2026, at SFJAZZ Center in San Francisco. The full init() 2026 recap covers the keynote and the rest of the day. For people building agent products, the useful thread was the gap between what agents can do and what large companies are ready to hand them. Aaron Levie and Michael Grinich during their fireside chat at init(). Photo: Dan Lynch. Where his read on adoption comes from Box was working on AI years before ChatGPT. Around 2016 to 2018, Levie said, a Box team used the vision models of the day for classification, OCR and image detection, then shelved the work because every customer problem needed its own trained model and the processing cost far too much. ChatGPT, in his telling, finally gave end users a form factor for asking questions of their own data. The remaining problem was getting the right context into the model, which meant RAG infrastructure at the time and has since moved toward tool use. Michael described Box as changing direction to go all in within about ten days of the launch. Levie said it took about a week and a half and that he wouldn't call it a pivot. Box started building the core of the next generation of its platform. His check on the hype is customer time, which he says takes most of his hours. Online, AI can feel like a takeoff. At a real bank or insurer, people are still in meetings talking to other people, and those visits are how he sizes up the capability and diffusion gaps. The wire transfer question Michael asked about the personal agents that had appeared over the previous two months or so. Levie suggested, a little against type, that a persistent agent with its own goals, identity and access controls may work better in personal life than at work. A person controls what data their own agent gets, so the blast radius stays small. At a company, the same agent has to talk to colleagues and pull from other systems, and the cyber risk grows with it. On capability he is optimistic. Even six months earlier, he said, he might have doubted that browser use and computer use could handle the long tail of tasks. Now he expects that within one to two years an agent could probably carry out a five-to-ten-step real-world task, like phoning someone to gather information and then doing the next couple of steps. That shifts the open problem to scaffolding, such as the identity and security handshake between your agent and a vendor it is working with. On whether a bank should let a personal agent send a wire, Levie's questions ran roughly like this: - Is the capability ready? - How do you trust that nobody stole a token or session to make the request? - Is the security handshake sound? - What approval notification should the user get? - Which industry standards for verifying what is happening still need to exist? He stayed upbeat. The industry has a lot to build, he said, but being able to tell an agent to do a real-world task and have it done would be completely net positive for society. If you build agents that act for someone, those questions become design requirements. Your system has to know which user the agent acts for and whether the session carrying that identity still belongs to them. It also needs a way to put an approval in front of a person before an irreversible action runs. Enterprises don't have to wait for consumers Michael offered the usual pattern. Consumer technology tends to lead, as social networking did before Yammer and Slack, and as iPhones did before people wanted them at work. AI has run the other way, and he asked whether personal agents are what will get everyone else using it. Levie said maybe, but he doesn't lean that far toward consumer. He called AI largely an industrial technology, since intelligence is scarcest and most valuable inside enterprises, and said he doesn't know that enterprises need a consumer breakthrough to take off. He sees consumer agents as a separate category and doubts they will flow back into work the way the iPhone did. What holds enterprises back, in his view, is about a decade of diffusion work. Companies have to change workflows, get data into an environment agents can use, set up access controls and data security so agents reach the right information, and decide where the human sits in each process. Then there's accuracy. A system can be 95% accurate with nobody knowing which 5% is wrong. In a loan or drug trial workflow that looks great on evals, one real-world mistake can be existential. Engineering went first because its output can be checked Asked where enterprise adoption stands, Levie described something close to a bimodal split, with coding as the solved case. Engineers can't do the job without AI anymore, and they keep moving up abstraction layers, from one agent to several to a fleet, until the work is describing the project and making sure it gets tested and deployed. Most other jobs lack that path, he said, because their output isn't something you can run a regression test against. A banker or sales rep goes to meetings and negotiates with people, and a lawyer has to work out what a client intends and how much risk they'll accept. Levie said people sometimes treat engineering's head start as incidental, since the companies building AI are engineering companies. He disagrees. In his view engineering went first because code is what this technology is very good at. Two code bases, one at 10 million lines and one at 100,000, can both run production correctly and never lose data. A 500-page contract is a different matter, because the counterparty has to read all of it and nobody can easily confirm that paragraph 76 didn't change something elsewhere. Other kinds of work don't yet have the verification and testing systems engineering has. Below engineering, he said, legal AI products seem to be working and investment banking shows early product shapes, while much other work depends on fragmented data that agents can't readily reach. In life sciences, AI can widen the search for new ideas, but nobody knows how good a discovery is until a lab tests it, so physical labs become the limit. Implementation means adding labor Levie separated rolling out software tools from rolling out AI. A tool is mostly deterministic. You add it to a workflow and train people once, and after that they know what each button does. With AI, he said, an organization is taking on labor, which raises staffing questions. Where does the labor show up in the process? Who tunes it over time? What happens when a new model swaps out its brain and something breaks? He expects the change management and continuous improvement that follow to take many years. That is why he is bullish on forward-deployed engineering (FDE) roles of every kind, whether at vendors, at systems integrators or inside the enterprise. Somebody has to bridge model capability and the company's workflows. Michael framed FDEs as help for organizations that can't do this work themselves. Recalling his own early jobs building websites for companies, he asked whether the role is transitional. Levie pushed back. Even a company that could do it alone may not want to rediscover every best practice a vendor learns across its other customers, and at this pace everyone needs help. He pointed out that Michael's old web job still exists inside large companies. He expects someone to still be bringing AI into workflows in ten years, testing and governing it and connecting it to the right data, even if the job gets relabeled. Maybe, he suggested, the IT department becomes the AI department. Both of Levie's main arguments come back to verification. Code went first because you can check it. The wire transfer is still hard because the bank has open questions about the session behind the request and how the user approves it. If you sell agents into enterprises, expect customers to ask how they can verify and govern what your agent did, and expect someone, on your team or theirs, to do the deployment work Levie described. The full afternoon program is on the init() event page.
document fetched 2026-10-24 10:07