Aaron Levie, Box CEO: Advice for CIOs on AI Agents

There was a brief moment where you could rely on the subsidization from venture capitalists and then get tokens for your coding agents. It was a beautiful moment in history. It lasted about a year and we all had a great time. Every company wants AI agents, but few CIOs can run them safely at scale.

We are still in the very early stages of what agentic work looks like in the enterprise and what the rollout looks like. We have an interesting dynamic which is sort of a tale of two cities. We have AI agentic coding which has clearly taken off within engineering teams, and everybody has kind of figured out what the new practices are around the future of engineering. We can get into a little bit on what the differences are between the engineering side and the rest of work. Engineering obviously had a complete vertical takeoff of AI agents. And then you get into the real messy environments of knowledge work where things are quite a bit different. It's a lot harder to deploy agents at scale. The agents don't always have access to the right data. The users are less technical, so they don't know how to always steer them properly. You have to do a lot of work to verify the work that the agent is doing in a way that in software you can just test the software and see if it worked, but you can't do that in a lot of areas of knowledge work. So I think we're in this really interesting phase where we've seen what the promise of agents looks like in coding in particular, we've seen what the promise of chatbots looks like in knowledge work, and now the question is what's the full promise of agents across knowledge work. This will be the defining topic over the next few years within the enterprise.

The promise of coding is honestly just an incredible gift. We've all done large engineering projects and we know how much time, maybe 60, 70, 80% of your engineering time, goes into the work that doesn't actually make the project differentiated per se. It's necessary work. It's differentiated in the sense that if you didn't do it, you wouldn't be successful, but it's the very labor-intensive, time-intensive things like upgrading the version of a library to the latest version, doing all the edge case testing of our software, building all the end-user features that are necessary for the functionality to be delivered. That's where most of the time of engineering goes. That could mean that you want to take on a big project and from a standing start it could take six months or a year or two years before you see the value of that product delivered to your customers. So the promise of agentic coding is, what if we could have agents go and do lots and lots of that blocking and tackling work that is necessary? And then our job is making sure that we're giving the agents the right plan to work with, steering agents in the right direction, reviewing the work of those agents, deploying testing and security solutions for whatever they've worked on. Could we shrink that one-year project into two months? That was a fantastical concept that honestly people would not have believed you three or four years ago if you had said that, because all we had was type-ahead functionality in our code editor. Now that promise is reality. We're seeing this every single day internally at Box. We're seeing it from our customers. We might be able to literally do 3, 5, 10 times more work than we were able to do before, and the corollary is you might be able to do it 3 or 5 or 10 times faster. This is what we're seeing on the engineering side. At Box it means that we can just build a much more significant product roadmap for our customers. It means that they can take on way bigger problems than they could have before, which is amazing. So that's the promise.

That's the promise and actually what we're starting to see the early signs of on the engineering side. So now everybody kind of sits around and says, we want that exact same kind of output and outcome in knowledge work. And you do have a couple differences that have to be figured out. The first is that in engineering you've got a lot of great properties for agentic work. The work is mostly in a text-based medium, so you're mostly just writing code. AI agents have been trained on this data, lots and lots of code examples on the internet. Your users are obviously much more technical because they're engineers, so they can both implement the technology themselves and keep up with all the updates that are happening in AI. It's much easier when a new model comes out to implement that latest model, or when some new kind of alpha emerges in the industry like configuring MCPs or CLIs in a certain way, they can adopt that much faster. You have another property, which is that the work is more or less verifiable. If I build a bunch of code, I can go and do a regression test on it to see if I broke anything or if it still works. Now compare that to knowledge work. You generally have a less technical audience just by definition, and the work is sort of less verifiable by definition. A contract you can't compute whether it's correct or not. It has to experience reality, the red lines from the other party, somebody taking that case to court. So you have to review the work a lot more to make sure it actually does what you wanted it to do. You have to review the final financial analysis to make sure it pulled all the right data in the right way from your set of spreadsheets. And the agents don't have access to data in exactly the same way that they have access to the data inside of engineering. In engineering, from an access control standpoint, if you're an engineer working on a project, you already have access to the entire codebase relevant to that project. So by definition, the agent that you're deploying also has access to all of that data. In the enterprise, we're constantly asking for permission to other systems and other resources and other data environments. An agent is only as good as the data that it has access to. But in the enterprise, we have lots of systems that are either not well-maintained or the agent can't get access to the right data, or maybe even worse, you have too much access to information. We had security through obscurity in your organization. So now all of a sudden the agent is leaking data to the wrong people. Think about that T-chart that I just went through, and think about how many differences there are between agentic coding and agentic knowledge work. The project ahead for all of us across the economy, whether you're a tech company or a user of technology, is how do we take those same gains that are happening in coding and bring them to the rest of the world and the rest of our organizations? That is going to be a very big project that will take years and years of diffusion into organizations. I'm extremely excited by it because it means there are all new roles that are emerging to go do this. The upside on the other end is tremendous because now you can actually accelerate your organizational productivity. But make no mistake, this is a very real effort that companies have to go through right now.

I have my own experience of AI and I've seen it from peers and other people in the industry. I think I have a good pulse on this. I use AI as much as any CEO out there. I'm using it for prototyping of new products, developing new ideas, doing lots of market research, automating customer intelligence. I'm using AI all day long. At the very start of that journey, you do these things like prototype a piece of software or do some market research and you're like, oh my god, this thing is going to just automate everything. What are the implications of this? You almost have this sort of existential dread for a few moments. For some people it lasts longer. I think I got through it maybe in a couple weeks. It ebbs and flows because a new model comes out and a fable emerges and you're like, oh my god, I'm experiencing it again. So there's a juncture where you can end up on one end, which is, oh my gosh, we have to retool everything and what are the people going to do? It gets very existential. The other end is you start to see that there's still lots of bugs that the agent wrote, lots of security issues that were generated or discovered by the agent that now have to get fixed. There's all the ongoing maintenance of the system that we just deployed. In the other areas of knowledge work, you find things like the agent pulled from the wrong piece of data, which meant that if I hadn't reviewed that report, I would have come to exactly the wrong conclusion. So I had to steer the agent more and it took a lot of work to prompt it in the right way. On the other fork in the road, you end up post-psychosis, where you realize that there's still a lot of work that has to get done to make these agents effective. So there's this journey of instant existential dread or high, to a bit more pragmatism. That's where I landed and I have a number of friends that also landed here, which is that this is actually a technology that is going to boost our productivity and let us do far more than we were able to do before, but it is not as doomsday as some of the commentary comes out, because it's going to take a lot of time to fully deploy these agents to get the work done that we need. That last mile thing, or the closeness to the problem, is really the issue. A CEO by definition is the furthest away from the real work happening in the company. You couldn't get further from any other role other than maybe the board of directors. For us it's very easy to be like, oh well, I could just automate that engineer or I can go automate that marketing campaign. But when you're closer to the problem, you realize that you probably just can't have an agent do all of that without any human supervision, because it's going to do the wrong thing or the taste of what the agent delivers is going to be off or it's going to introduce a bug. That keeps the humans in the loop for the foreseeable future. The thing I encourage CEOs is use the technology so much that you get to the other end of that psychosis and can actually see in a much more practical and pragmatic way all the places where humans are still necessary to get the ultimate gains from this technology. Don't just stop when you prompt an agent and ask it to generate a research report and then get blown away and think that's the only thing that's going to happen in the future.

My instinct is always biased toward being more ambitious with what you can do. That will more often lead you to seeing better productivity gains, but also you'll see the edge of this technology much faster. Anytime you hear stories about people not getting real ROI from agents, I do think it often approximates not pushing them hard enough and thus doing very kind of more menial type of work as opposed to actually pushing the limits of this technology and getting the gains out of it. It's hard to have a full general piece of feedback other than I would always bias toward being more ambitious, pushing the limits much further. Then importantly, if something fails with AI with whatever that ambitious idea was, you almost have to try it again six months later, almost every single time no matter what it is, because the model progress that's happening right now is still at an incredible rate. You often have to say, you know what, I have to forget about the fact that six months ago this didn't work in this particular part of our codebase or in this particular marketing campaign. If you relied on your understanding of image generation as a marketer from six months ago, that's already been blown up. The latest image gen models are perfect at being able to do text and have photorealistic capabilities in a way that wasn't possible six or 12 months ago. So if you were in marketing campaigns, you'd want to reset your understanding. In software projects, something like Fable or GPT 5.5 is another step function improvement on what these agents were capable of. We had a project just yesterday where we tested Fable versus Opus 4.8, and you'd think these should be on the same trajectory of progress, and the thing that Opus 4.8 couldn't do, Fable just finally actually did. So if you don't constantly recheck what is now possible with AI, you will fall into the trap of believing that maybe the productivity gains aren't there or you're not able to accomplish as much as you wanted. So I think have very ambitious expectations, constantly be trying the technology, and keep pushing the limits.

I actually think there's going to be a role for effectively an internal FDE. This is some kind of IT business AI automation engineer type role. I think often it's going to live within the technology or IT organization but be embedded within the actual line of business that it's trying to bring automation to. There's the internal version and then there's the external version coming from either the vendor or the systems integrator or maybe a new consulting firm. If we go back to what's the difference between coding agents and the rest of knowledge work, a lot of it does come down to how technical the user is and their ability to navigate around all the challenges that agents run into. One of the big challenges is, do agents have access to the right data to be able to work with? Do they have access to the right internal systems to pull context into the context window to be effective? An engineer knows their way around those different systems, how to get access to resources, how to set up MCP servers, how to set up CLIs, how to deal with compute sandboxes that the agent might need. This is just not necessarily how most knowledge workers were trained. These are not the things that we've ever had to think about. We're used to going into PowerPoint, Word, GDoc, Slack, generating stuff, creating files and sharing them. But for an agent to be really effective, they need access to all the right data. The data has got to be in the right format. You probably need skills files and readme files in the process. This is the agents.md phenomenon that has emerged. You have to have the permissions to turn on MCP servers. All of that is technology work. There's almost no way for that to not be done by somebody who is at least either formally trained or has figured out how to be highly technical. So the job of FDEs is basically to help companies first understand today's workflow and then figure out how to bridge the capability of the technology that is emerging and constantly changing with the workflows of that organization. Sometimes you can get lucky and embed agents in an existing business process and it sort of miraculously works. But often you have to re-engineer the process, migrate the data sources into a modern system, and change the workflow so agents can be more effective. All of that is the work of the forward deployed engineer. That forward deployed engineer could come from a vendor like Box or Salesforce or Palantir, or from a systems integrator or maybe a new consulting firm. So I think there's going to be all these new roles that emerge, which are basically the technical talent that has enough business acumen to get into the business processes of that organization and successfully implement the tools of AI to bring agents to bear in those workflows.

I think we're still at a point where I would bet on either a technology company or an end user of the technology that has simultaneously the frontier models that they're leveraging and the best ability to get those models the right context to be able to work with. Sometimes you want to do this thought experiment: if you were starting your company from scratch, what would it look like to be able to get the full gains of AI? I think it's pretty intuitive that if you could start your company from scratch, you'd basically design your business processes in such a way where the agent has an innate ability to get access to the context it needs to help you automate work. If we started a one-person company, you'd probably start with a file system that had all of the context of your business: all of your goals, marketing strategy, customer language, and then you'd build your company up from that foundation. Agents always need access to the right data to answer the right question or automate the workflow. So if you were to build your company from scratch, you would do both the frontier intelligence and you'd have proprietary information and insight that you're giving that agent, and you'd develop a flywheel. As you hired more people, you would try to maintain that ability for agents to keep having access to the right data. You'd really value sources of truth and authoritative knowledge banks. One of the problems that traditional enterprises have is that our sources of truth are everywhere and many of them are not well-maintained. But if you were starting from scratch, you would always write down your final decisions in a way that agents can get access to, so the agent doesn't land on the wrong resource or get the wrong insight. So to the question, what should you do right now in any kind of meaningful or large enterprise? You are basically trying to do whatever you can to get to the point where a company from scratch sort of is built up in this kind of way. So I would be betting on frontier intelligence right now with the combination of access to the right context for those agents to be effective, and making sure that your organization is built in such a way where you can get those agents the right data in those workflows. To your second question about the extent to which models are becoming commoditized, architecturally, that doesn't mean you bet entirely on one frontier model. You probably want to design some kind of neutrality. Right now, I think you should still try to exploit the gains from frontier intelligence as much as possible, but in one, two, or three years from now, you're going to see a stratification between the cost of frontier intelligence and the cost of the second best frontier intelligence that can do the job extremely well for a bunch of longtail tasks. I think you're going to end up in a world where model routing becomes very important. Maybe something like a Fable-esque model gets the planning and review part of the work, but the in-between massive token usage comes from something that is a more cost-effective model for that type of work. So you want to invest in the right kind of architecture that can deliver on that type of outcome. That's probably where we're heading from a tokconomic standpoint. Making sure that you can design an IT architecture and a data architecture that lets you deliver that is super important.

We definitely preferred the world where it was being subsidized. Those days are over. It was fun while we got it. There was a brief moment where you could rely on the subsidization from venture capitalists and then get tokens for your coding agents. It was a beautiful moment in history. It lasted about a year and we all had a great time. There was a period where you could have really exploited it and had 10 years of software development paid for by LPs and VCs. Unfortunately, those days appear to be coming to an end. Now we're in a much healthier environment where you're more or less going to be paying for the real underlying costs that it takes to deliver this. That's just capitalism, microeconomics 101: where are you getting the right ROI from these agents? You should deploy agents at the work where it's most effective, where you are getting that ROI. We're fortunately in a little bit of a sweet spot because we're an enterprise software company, and because of what we build, we have a pretty good pulse on our customer base. We kind of know how to deploy agents in a way that makes us more productive and lets us ship more software that we think is valuable. We're kind of smack in the middle. If you had a token maxing company, we're not that. We don't have a leaderboard internally or incentivize the most number of tokens. On the other end of the spectrum, maybe you'd have a company where everything is locked down and it's hard to get access to frontier agents. We don't want to be that either. We try to rely on more mature, sophisticated approaches. As long as we have a really good product roadmap and really good product managers and engineers working on designing that, then I'd rather move that product roadmap forward as fast as humanly possible. If the token spend goes up exponentially, that should be correlated with a good thing: we can deliver more software to our customers faster. Then it's more of a CFO exercise: how do you plan for that, how do we budget for that, what are the trade-offs? I do think we're well past the point where the IT organization can hold the entire budget of AI. That's actually a healthy thing. IT budgets run at maybe 2-5% of total revenue depending on the industry, and that's an artificial cap on what AI's potential could be. Maybe you want AI alone to be 5% of your total revenue, which would be a doubling of the IT budget. To do that, you ultimately need the line of business to own the budget and own the deployment of where AI is used in the organization. I think we're in a renaissance of the IT organization. Your job now is to bring some form of intelligence to the entire business and be the experts in the technology and what you're going to be able to deliver. You're going to partner with the business on where it should be deployed. That's this interesting budget-use-case-meets-technology-and-capability pairing that we're going to have for quite some time.

I think this is an incredible time if you're super curious, if you're excited by technology, if you're one of these people that geeks out on the latest version of the iOS release or now the latest version of Claude Code or Codex release. I would go very deep in the technology. I would be experimenting with it constantly to push the limits of what these tools can do. The awesome thing is that it's one of the first moments in history where almost everybody has the same amount of access to information at the same moment. Twenty years ago, there was a huge advantage if you were in Silicon Valley: you would see the iPhone first because you could go to the developer conference, or you saw what was happening in SaaS because most companies were located here. Today in 2026, maybe I have an hour heads-up of information from anybody else because there's some chat thread with Silicon Valley founders, but other than that, we all have access to the same technology effectively at the same moment. That means if you're paying attention to the right resources — this podcast being one of them, there are other great AI podcasts — you can be as informed as the best expert in the world right now. You get the same news feed as Andrej Karpathy, Greg Brockman, Dario Amodei, and Sam Altman. If you're getting the same news feed, then there's very little that they have access to other than maybe what's in their research labs that you can't take advantage of. I think we have this cool moment in history where information sources are keeping up with the pace of innovation. It doesn't mean our organizations are, but our ability to tap into what's happening is there. So I would just be playing with this technology constantly, pushing the limits, breaking things. Then I would try to figure out what are the implications of this technology to an organization I already work with or one I want to work in. Those kinds of people and personalities will be the ones that get ahead further.

It's a key insight that some people miss a lot. You're always so used to thinking about this as kind of anthropomorphizing the technology, probably sometimes too much, but it's not just an engineer or just a marketer. It has the ability to have all of the skills in one. I'll often go to AI for product prototyping and I might give it a prompt that is very specific, but sometimes I'll actually add something like "feel free to add anything else you come up with" into the prompt. That will be an explicit sentence or two, and it will come up with an idea that far exceeds what I ever would have been able to prompt it to do because it can take in all these extra domains. If you're doing product prototyping, try not to just limit to your own imagination. Give it that extra nudge: "Hey, if you also have better ideas than what I'm telling you to go do, come up with it and show me what you're thinking about." The cool thing about AI, and it's getting more expensive no question, is that you can just have five tabs running and have it go do five different versions. I'm often prototyping in parallel just to see if there are things I'm missing and to expand the use case or capability I was trying to come up with.

This is a big question across the software ecosystem: what's the new value proposition of software in this world of agents? We've been pretty clear that people can have different takes on this. For the most part, you're not going to go and build from scratch a CRM system or an ERP system. You shouldn't be building from scratch a core system of record for your documents and enterprise data because you're benefiting from the fact that there are also another 100,000 customers that need the same technology. It's the job of that vendor to get really good at doing that one thing really well. With AI, we can actually do that for you even faster and even better. There's been some confusion about where we're probably going to be applying these tokens and capabilities. The value of the core systems of record continues to matter a ton. But then the question is what can you do with agents on top of those systems of record and where can I get even more value from my technology? That's what I get really excited by because I think we're just going to be using our tools far more. I'll give you one example. I use Salesforce more today than at any point in history, maybe five times more, because I have an MCP server connected to Claude Code and I'm constantly using it for customer intelligence, market intelligence that I would have never done manually. I actually think there's been a misread on the market opportunity: we're going to move to a world where there are maybe a hundred times more agents than people using software. In that world, what are we going to use these tools for? We're going to use them for so many more things in our organization. We have an interesting lens because we get to see it from our customers where they're processing data at a scale that never would have been possible before with humans. All of a sudden the value of your unstructured data assets has gone up, the value of your CRM systems has gone up, the value of what you can do with your ERP system has gone up. So that's how the value shifts over time. Things like governance become really important for making sure you can effectively get those gains from those technologies.

I think you should really treat this as a technology for abundance. You almost have to look at your business and stop and ask yourself in every part of your business: if I had unlimited capacity in XYZ area, what would I do differently? With unlimited capacity for combing through information, using judgment, accessing data, what would change about that workflow? You can quickly think through that there are actually a lot of parts of my business where I've been constrained by my ability to deploy human resources at certain problems. If I get incrementally unconstrained because agents can go do a lot of that work, what would I do differently? Easy example in our world as a B2B company: if I could deploy agents to comb through our customer base, we would have much better insights about the right time to have the right message for our customer. If I could deploy unlimited compute, it would know everything that's going on in every single one of our customers so we can be that much more helpful in our relationship or partnership. You asked about HR. I posed this question to our recruiting team the other day: if you could just comb through all of LinkedIn and not stop at the LinkedIn profile but hop over to the internet and see the GitHub projects that person worked on, their thought leadership in the press, and build a full profile of that individual, and at the right moment when something's going on in that organization that was the time to talk to them or recruit them, how would that change recruiting? You can kind of go through your entire organization and see where your business could have completely different returns if you had unlimited capacity to work on things and unlimited information. To a CFO, there's a huge wealth of examples: what if I could analyze my business totally differently, see where there's waste from an operational expense standpoint, take those dollars and reapply them to areas where we need to drive growth, or which parts of my customer base are unprofitable so I can tweak the business model, or where are insights in market opportunities that we should be doubling down in? All of these things are constrained today by the amount of people you have to work through spreadsheets, ERP systems, and analytics data. Now you can actually throw compute at that problem and you're no longer constrained by the number of people on the team. So I think we're in this real renaissance of the kind of workflows that we can go and execute. But that really does take looking across the organization of where you would have a lot more upside if you could bring unbounded resources to those areas.

I'm definitely a big fan of value maxing, and I'm glad that terminology has already taken over from token maxing pretty quickly. Honestly, it's hard to be too generalizable about this. It's probably no different than if you were to ask that exact question 20 years ago before any form of AI or cloud technology. You'd say, how does somebody measure the ROI in the marketing team or in the sales team or in finance? You'd have to use whatever tools we've always thought about: I have a certain amount of dollars, I can deploy those dollars against a variety of things in my business. I could do events, marketing campaigns, build products, hire people at a certain price point. I can do an infinite set of things. How have we ever measured ROI? It's basically amongst all of these choices and opportunity costs, where is the most effective use of the incremental dollar going to go? The bittersweet news here is that it is no harder or easier to do this with AI than at any other point in history. It's always been this kind of squishy thing where there's some judgment and sometimes you guess and sometimes you guess wrong, and when you guess right you keep doubling down. AI is no different. You're going to be experimenting. You need high judgment people. Maybe the one difference is that with the wrong prompt and wrong limits, you could probably spend $50,000 and wake up the next day with that bill. So you have to be pretty thoughtful about where you're going to deploy these tokens. But short of making catastrophic mistakes like that, the problem looks pretty similar to the history of business: you need people close to the business with budgets, who have high judgment, understand the technology, understand what it's capable of, and you need a rigorous process to constantly review where you're getting the ROI from these deployments. This is not a one-shot environment. It's an ongoing budget management process.

I do think it's really important to keep up with the technology. I don't know of a replacement to that. I know that was the qualifier to the question, but I think you just have to find a way to stay as current as possible, and it behooves companies for educating their employees on this as well.

I think that's about 90% accurate. The person who actually owns the delivery of a particular project is in the best position to know the rate of productivity they can get with AI, assuming they have religion on this. The only exception is when you have something that is either so expensive or transformational that you need senior leadership to get behind or identify. But I would generally bias toward that point.

The combination of both technical skill and business acumen is still the best approach. If you're interested in marketing, get really good at marketing and the core principles of marketing, but also understand how AI accelerates building a marketing campaign or doing market research. Being able to live at that intersection is still the most potent way to go and deploy this technology. I would tell that to someone doing clinical drug trials in life sciences: deeply understand that field but also understand how something like Claude Code or Codex helps accelerate that kind of work.

Squishy for sure. I think it's got to be mostly embedded, but there are some areas where it's got to be an adjunct.

Yeah.

I feel the pain all day long, so I completely agree.

I think it's the most exciting moment in history to be a CIO. There's so much change within technology. If you're even remotely curious as an IT leader or in the IT organization, there's an incredible tsunami of new things to play with and technology to try out. I think the importance of the CIO role rises dramatically because this is back to a prior point: agents are maybe the most technical solution that has ever been deployed to non-technical people. You're deploying non-deterministic intelligence into the hands of every knowledge worker, and it will run wild and grab the wrong data and produce the wrong report, or produce the right data and generate the right software code. That's all determined by your technology architecture, how you've deployed these agents, and how you trained your users to use them. The role of the CIO becomes substantially more important. You're effectively providing work to your organization. This is the first time in history where IT is responsible for deploying the actual real output of the organization, not just the tools that enable the output. So this is an incredible time to be in IT.

Because of our customer base and how we've grown up as a platform, we see the danger in too much information in the hands of either the wrong people or the wrong agents. This is definitely a phenomenon where you have to make sure that only the right context gets to the agent. You can't just shove as much context as possible to the agent. First of all, that'll be a security nightmare, and second of all, it'll still get the wrong answer because it'll have too many things to put its attention on. The right context at the right time with the right guardrails is still a critical problem for agents to work with.

Our job is to help customers solve many of these problems with their unstructured data. The reason why we're so excited and passionate about AI is it's the first time in history where we can actually tap into all this data that we have in our organizations. At Box, we're trying to build the leading AI platform to help companies tap into all of this unstructured data and knowledge, and then work with your entire agentic ecosystem. I appreciate you having me on, and these are the topics that we get really excited by.

Thank you.