State of Enterprise AI 2026: Aaron Levie on Tokenmaxxing, Rise of Headless, and AI-Proofing Your Job

Hey, good to be back. Appreciate it.

Interestingly, we've always sort of played this role. And if I had to distill maybe the singular concept we've always tried to think about, it's basically our job to take super-advanced technology breakthroughs and bridge them to the real world. So, at the very early stages of cloud computing, it was like, oh, we can now move infinite storage into the cloud. Well, to get that in the hands of most businesses, you would need a simple interface and you need advanced security.

So we've always sort of been this bridge. It lets us have a foot in both worlds: one world being the super-advanced, everything-is-moving-a-million-miles-a-second, and then the rest of the world, which is like, there's change management and there's systems that have to be upgraded and all that. So we saw that with the cloud, and now we're definitely seeing another version of that with AI again. I think there's one tiny little asterisk, which is it's sort of not just Silicon Valley versus everybody else.

It's Silicon Valley engineering versus everybody else. And then engineering, though, to be clear, I would say if you're tapped into AI right now and you're at one of those name-brand companies and you're in engineering, you probably could look fairly similar to Silicon Valley. So the bigger question is Silicon Valley versus non-engineering knowledge work. And that's the big question right now, which is: what is this path from AI coding agents that we know have totally reached escape velocity to now agentic work in the rest of the organization?

And what does that rollout look like? What are the use cases going to be? How do these get implemented? Needless to say, this is the number one conversation every single customer that we talk to has at this point. And I think I have a decent sample size, probably a couple hundred CIOs just this year across the Fortune 500, Global 2000 type of cohorts. And I would say this is the singular conversation dominating every single engagement that we have with an enterprise.

It's the main and primary thing that every enterprise is trying to figure out. We are still incredibly early. So that's probably the really big TL;DR. What's interesting, and the reason why we're early, even though it's like, okay, well, we've been in the AI wave for three to four years, let's say, is everybody just started figuring out their final rollout plans for the chat system in the enterprise. People have very appropriately been proud and happy that they finally got that thing out.

That's still rolling out in some organizations, to be clear. We still have five years of growth of the chat system for knowledge work. But right as that happens, then the capability has been extended even further. And so then everybody's sitting around saying, okay, as we move from chat, which is like, I ask a question, I get an answer back, and so the productivity gain is rate-limited by the human's ability to have a conversation. Now I actually want to go deploy an agent that's going to be doing things and producing real work in the enterprise, maybe handling tasks.

Maybe you kick it off via chat, or maybe it's just running in a stateful way and I'm pinging it, or it's kicking off in a workflow. So now everybody is sort of saying, okay, we think we know how the chat thing works. And by the way, even though they know how that works, I'd still say that it's a still-changing dynamic in market share. You're having a lot of changes in what people are rolling out there. Now everybody's saying, okay, we're going to go deploy agents.

These are going to be much more advanced, much more capable. And that's the big conversation. I would say we're in day one of that as an industry.

I would say, if I did the broadest sample, I think the mood would veer statistically more optimistic than maybe the framing that I think maybe you landed on—a few extra cynical CIOs in that. I think because what's happening is the CIO—and our main audience is the CIO—when we talk to the CIO, they know that their engineering teams are using Claude Code and Codex and Cursor, and they're seeing the productivity gains come out of those teams. And they're like, "Yeah, my teams are just building apps way faster."

They're able to tackle IT projects much more quickly. We're doing security reviews faster. They're seeing the productivity gains in their function. And I think they're often saying, "How do I bring those same productivity gains to the non-IT parts of the organization?" And they're having the business pull them and say, "I want access to Claude Cowork. I want access to Codex. I want access to these tools as well." So there's actually a certain kind of sex appeal to these tools right now, where the business is sort of demanding, "I want to be on the agentic train because I'm seeing all these great use cases."

And so I think the tone is actually remarkably optimistic and excited and positive, as opposed to—there's a sort of typical trough of disillusionment from Gartner and the hype cycle or whatnot. I think people are eyes wide open on: there's no free lunch in this. It's not going to just immediately transform our productivity. We're no longer in that part of the conversation, and maybe we were like two to three years ago. I think everybody is sort of very firmly aware: this thing doesn't just get deployed and magically go and transform the business.

But at the same time, they're having their employees say, "Actually, I would like this thing to be able to go review all my documents for me. I would like to go accelerate our client onboarding process. I would like to be able to generate digital assets in our marketing campaign process." So I think the demand is coming from the business, and the IT organization is seeing the gains happening in coding. And now it's a bit more of just practical, tactical issues, and I'm sure we'll get into some of them.

It's the token cost thing. It's the how do you actually roll this out? It's do you have the talent to go and deploy these things? So I'm finding the conversations to be fairly positive and increasingly ambitious, but with a sense and strong dose of reality that none of this stuff is coming for free, beyond even the cost side, but free in a deployment sort of manner.

Yeah, although, to be fair, I think the Microsoft one probably got spun in some interesting ways because there's probably much more of a reflection on they want to move to—yeah, Claude Code versus Codex. Yeah, it's like they're going to be spending on the tokens. It's literally going to ride on their infrastructure. So I think the press really liked to modify the sort of story on that one.

I don't know if I have good recommendations yet, actually. But I would say when we go and talk to organizations right now about where they are with agents, tokens, the cost of tokens, and budgeting and budget planning, all of this probably is at least one-third of the hottest-button issues that relate to AI. And it might even be tied for number one half the time. Because what they've seen is this move from—everybody's sort of calling it like we were doing subsidization as an industry.

I don't really think about it like that. I would say that the costs were just low enough that these things were included. Cursor just included a lot of usage, and maybe it was subsidization, but it was actually just like they could model that under their subscription fee in a fairly clean way. And then all of a sudden, what happened was these agents just can do way more work. Their context windows are way larger. The cost of inference is way more because they have way more parameters, and their capability is way better.

So we've just gone from a pricing model of a chatbot or type-ahead functionality in GitHub Copilot to that pricing model no longer working when one coding agent could be consuming $1,000 of compute on a single task. So clearly, you can't lump that all into a $20 per user per month fee. So that's really the jump that's happened, and it's all only happened in one year, maybe less than a year. I mean, it basically all correlates to—you can just look at the Anthropic revenue curve, and that is the period of time where everything has sort of been flipped on its head on the sort of cost modeling and token budgeting side.

Yes, 100%. But I think the one nuance is—I mean, it'd be good to get some of the lab folks on—I'm not 100% sure it's just the subsidization change as much as these models are just way bigger, and the hardware is not getting any cheaper anytime soon, and we have a capacity constraint. So you've got a few atypical patterns from normal computing, which is usually there are economies of scale and you don't have the same kind of shortage. And so then, as you build out, everything gets cheaper and you have Moore's Law.

We've compressed normally what should happen in 10 years of rollout into 18 months. They have pricing power. They don't need to lower their prices on anything. So you're not seeing the typical things that drive down the cost of compute. I'm highly optimistic that that happens over the next five to 10 years, but it's just clearly not happening yet. So we're not seeing the curve that you should see in a normal 10-year cycle of compute because that 10 years is now happening in 12 months.

So what's happening is enterprises are saying, "Okay, I'm quite surprised by these bills." And it's a surprise that is sort of like an uncomfortable acceptance surprise, as opposed to an "I'm not doing this anymore" surprise, because they're empirically getting the productivity gains or they just wouldn't be paying the bills. It's just now they are saying, "Oh, okay, this is a very real expense in the business. This is not the kind of expense that we just sort of add on $20 per user in our headcount and now it has solved the problem."

So one of the nuanced shifts that's going to happen is, I think the first two to three years of AI, the IT budget could kind of consume the AI costs. And this would show up as, okay, the company upgraded to Microsoft Copilot, or they did the add-on of the AI product of XYZ vendor, or they could kind of get the Cursor licenses within the IT spend. And as you know, IT spend is basically somewhere between 3% to 7% of revenue in a company, sometimes lower, sometimes higher, but it's kind of trapped at that.

So then the question is, well, where's the other 60%, 70%, 80% of revenue in an organization? It's OpEx, and it's just general-purpose OpEx across the business. If AI is truly adding this productivity gain to your engineering team or your client onboarding process or your marketing team, then clearly you don't want to be trapped by this 3% to 7% in the business. It's going to escape that, and it's going to move to the line-of-business budgets. On one hand, it's actually good for the AI industry because you're no longer going to be constrained by IT spend budgets in an organization.

On the other hand, you have all these now interesting downstream questions, which is, like, the line of business doesn't necessarily know how to budget for compute. They don't have FinOps for the marketing team. They don't have FinOps for the sales team. That was something that the cloud people had and the IT team could kind of go in and be confined to. So I think what's going to happen is, first of all, what's interesting is that you're going to have this tussle between the finance team, the line of business, the IT team. That's going to be this interesting kind of, how do you triage all of this?

You are going to, to some extent, have to centralize the management of the IT systems, management of what you procure. But then you also kind of have to decentralize the decision-making of how to use these things. Because really, the CMO should decide: do they want to spend $1 million of compute, or do they want to spend $1 million in doing marketing events or something else like that? That kind of can only come down to the business owner that is driving these decisions.

And that is, again, a new type of format of how do you manage a compute budget in your marketing budget and in your sales budget and in your global manufacturing budget. So that's a whole thing that now people have to go figure out. One of the things that we don't have tooling for is, like, how do you measure the ROI on the tokens? And it's, like, I think it's kind of absurd and hilarious to already be talking about ROI this early in the cycle.

But I see it as actually pretty practical. There are some things I could do on my computer right now that would cost the same amount of money as the lunch that my company provides me. I could press one button and it could cost me the free lunch that I get. So clearly a company is not going to be like, "Oh, let's just deploy a whole bunch of tools that people can just willy-nilly press a bunch of buttons and have the equivalent of 10 lunches in 10 seconds," without knowing, like, were you doing something that actually produced value for the organization?

And that's something that nobody has tooling for. Employees don't actually really know what the cost of compute is. So they're going to go about using these systems as freely as possible, not knowing that, yeah, that one little task you gave to that agent could cost $200 because you just happened to structure the query wrong. And now it's going to fan out across a bunch of systems, and it's going to read each document or each piece of data in your system, and then it's going to go and compute it all.

That one structure of that prompt is the difference between, again, your entire benefits for a month at that company. So how do we handle all this? I actually have no solutions. It's going to be one of the most interesting questions, and some mix of employee training, some mix of centralized capacity planning with decentralized decisions of how do you roll that out. You're going to need new pieces of software, probably. There's probably a $5 billion startup waiting to happen just in ERP for your AI compute, which is just like, how do I decide that all of this stuff is being used in the right way?

How do I measure the value that it's producing? How do I make sure that it rolls out to the right teams? So I think that's all up in the air right now. And I think this is so new that we're very short on best practices at the moment.

Wait, is there, like, do you have any royalty approach to this, or how does this work?

I got it.

In my long diatribe on all the problems, I mean, a few things that will inevitably happen. One thing that will inevitably happen is OpenAI has a great program, which is kind of this dedicated capacity, which is, okay, if you kind of know your workload, we're able to lock in certain pricing that helps support that. That's one way that you could kind of protect your costs. I think another thing that's going to happen is you're going to see this divergence, as opposed to, again, maybe two years ago I would have predicted a convergence, but let's go with the opposite now.

Frontier AI model capabilities get applied to coding and advanced life sciences and your contract process and your financial planning process, GPT-7 and whatever the model. But then once you have a task that you can now perform reliably, once that capability gets saturated and you can perform that task in a reliable way, then you can peel that off to a lower-cost model and run that on an ongoing basis. We just don't have a lot of maturity in doing that because really until maybe the past 6 to 12 months, the models couldn't do any of our tasks that reliably.

So as this starts to happen, you can say, yeah, for that one customer service interaction, I can now cap that at 50 cents per million tokens, and it will never go higher than that. In fact, it'll only go lower because I might swap it out with an OSS model, et cetera. But for my coding, I still actually want the highest capability. I think what's going to happen is you're going to have a mosaic of models in the enterprise. I think the average enterprise will certainly be using half a dozen models in their organization.

You're not going to throw everything at the Ferrari model from a performance standpoint. Companies will have to get better at that. You'll need to have some kind of deeper wherewithal on how do you shift tasks to different levels of compute. We're going to have new ways of measuring all this, back to the startup idea. There's some use cases I think companies will eventually realize, oh, actually maybe that's not something that I even need an agent for. It's like, oh, I just need software to get deployed into that.

And actually, software is actually cheaper because it's going to just run on a CPU.

Yes, software. It turns out that maybe you don't want your agent to re-render a UI every single morning, and that costs $30 per day of using the interface. So I think there's going to be a lot of mixed solutions on this, not to mention just good competition in the market that says, why don't we have some cheaper models that get produced? I think the market will sort of work as you'd expect, which is somebody will say, oh, there's actually an innovation opportunity here and go attack certain parts of the market.

They need way more vendors. The answer is always more vendors.

One hundred percent. But ideally subsidized VC-backed vendors.

Yes. There was a tweet—it's come up probably multiple times—which is: write as much code as you humanly can right now while some of these products are still subsidized. And it's actually kind of a funny concept because if you were really savvy, there's probably some parts of the market where you could be like, oh, I could somehow use this LP capital to do work for me as my startup. And there's a window where you can find those exploits.

So while the hottest topic might be tokens right now, just because there's press on it and it's a fun thing that surprises the CFO, I think probably the most realistic substantive problem and challenge is more one of technical implementation and the diffusion of AI in this form of agents across knowledge work. You've talked about this a lot, and you've had great guests that I think have covered this. I don't know how much I'll add to the contours of the conversation, but from what I'm seeing is, I think this is one of these things where you kind of have to have personally gone through the AI psychosis period and then come out the other side.

And I've had my phases of, I'll spend all weekend building projects, and I'm like, this is the most amazing thing in the history of human history. Obviously, you're going to have companies that are just one employee, and they're going to do everything. And then you come out the other end, you're like, wow, actually, maintaining that thing takes a lot of work. I'm having to catch so many mistakes that it's making. So I'm spending as much time after the project just reviewing everything and changing and modifying, or the model gets upgraded and it breaks everything that I just did, and now I have to go and redesign it again.

Once you're through the AI psychosis period, you land on the other side. I guess I'm benefited by both being a power user of these tools, but then seeing the real world and being like, oh wow, actually, in your particular environment, I think there's zero chance that you could have done what I can do on the weekend for fun because I would never allow that to happen from a security standpoint, or name your reason. So here's kind of the litany of things that are the work ahead.

So let's just say you use Claude Code or Codex and you're like, this is clearly the biggest breakthrough of all time, and it's obviously going to ripple through knowledge work and it's going to transform everything overnight, or all the jobs are going to be totally impacted. Here's just the quick ledger. In coding, you have a highly technical user. You have models that are hyper-trained on coding. You have effectively verifiable work because the code either runs and you can QA it and you can have tests on it, or not.

Back to the technical user piece, it's actually not a minor point. That technical user, the moment the agent does something stupid or runs into a problem, the user themselves knows how to go fix it and get it back on track. By virtue of them being technical and wired into this ecosystem, they're just consuming the news far faster and thus the best practices far faster. So when somebody says, oh, how's your skills file or your AGENTS.md file? They're like, oh yeah, well, it's got this and this, and it's stored here and it's accessible here.

That's not the dialogue and the language of a regular knowledge worker. And this has been talked about a ton by even, like, Dwarkesh, and I think Dario had a great conversation on this. The codebase has so much of the context in coding, whereas in the rest of knowledge work, the context lives across, like, 20 different things, some digital and some very not-digital mediums. And then this is kind of a relatively boring one, but it's going to be probably the most important, which is access controls in your codebase.

I can go to most teams in engineering, and they have access to the entire portion of work that they need to be working on. Conversely, you go to knowledge work and you constantly are running into either, oh, Bob actually had too much access to something, or Sally had too little access to something. So Sally has to go ask for something, or Bob should actually have less access. In both those cases, the agent equivalent that would have been doing coding that just can consume all of the codebase that it needs and generate whatever it needs, that agent in knowledge work is going to either bounce up against an entitlement issue immediately and it's not going to have access to a resource, or it'll have access to too much in terms of resources and then start to answer questions with data that it shouldn't have because the company didn't have a clean environment for access controls.

So you've got five or six reasons that AI coding looks very different from the rest of knowledge work. What the implications of this are is that diffusion is going to take time. We have increasingly the right kinds of applications for this. Claude Cowork is awesome. Obviously, Codex as a super app is emerging as this powerful workhorse. Gemini with Spark and whatnot. I think there's rumors that Cursor might try and evolve based on the SpaceX relationship. So I think the tools are increasingly coming and/or there.

Now you have the hard part of how do I deploy this in my organization in a way that is safe, in a way that is reliable, in a way that my employees aren't going to create some crazy blast radius of security challenges, in a way where employees know what is the right way to go wire up this workflow that ends up being useful for them. So you have this huge AI diffusion challenge. It's a much more technical problem than I think we sort of got used to with the chat paradigm because chat basically could do two things.

It could access search and it could access the LLM. That was amazing. But guess what? Neither of those things has a permission problem. Neither of those things required wiring up some other system where you could have massive data leakage.

Just a DLP problem. Honestly, in many ways, not that different from somebody going to Google to say, "I want to go research this customer," versus going to ChatGPT and saying, "I want to research this customer." Almost nothing has changed about the security paradigm of that enterprise. So maybe the prompt could include a little bit more IP, but the work you were doing was not like that. The blast radius of that work was quite contained. Conversely, I go to an agent and I happen to have access to the Salesforce MCP server.

And it's actually incredible. And it's actually one of the reasons why I totally believe in headless software. But I could do a lot of work with that, and I could pull out a lot of data, and I can ask a lot of very powerful questions. And a company is going to have to say, well, should every employee have the same level of access? And how should we make sure that we've cleaned up our access controls for that?

And how do we tell people again, what types of queries should they be doing that are going to have different kinds of cost profiles? And now you have to do that for each of your software vendors and applications. And then you have to figure out, like, what is the new workflow on the other end of this? Do you really want employees prompting their way through the workday across lots of stuff, or do you want some standardized best practices? And then you're like, okay, well, now I have to build skills internally, like capital-S skills.

And I have to have—or I have to have various kinds of knowledge graph or other ways of getting agents to the right information and the right kind of context. All of that is highly technical work that is going to take one, two, three, five years of building out across most organizations. The really good news for, I think, 90% of people, maybe other than the super AI accelerationists, is that work means tons of opportunity. It means actually there's a lot of opportunity for startups.

It means there's a lot of opportunity for new kinds of roles. One of the hottest topics also is we have a lot of customers asking us, what is this new internal FDE role or external FDE role? What is the technical talent I need to go and actually help me deploy these types of systems? So we are in for years of this kind of diffusion, and it's just non-trivial, and every company has to go through it one by one. This is the kind of journey that we are all now on.

Partly, I don't know how we define this, because I think it'll be a continuous evolution. Not to play semantics, but it's more like, what do we think the end state is? Again, I think AI doomers or accelerationists think there is some end state. I actually don't think there's an end state. I think this is a substrate of how work happens, and it will just constantly get better, and we will have to constantly move up abstraction layers.

And it's not even obvious to me what the end is. It's just like, it's a new way to basically execute work. In some areas, that will be a 5x productivity gain; in other areas, there'll be a 10% productivity gain, and that will roll out. And then, in five years from now, we'll find the next version of that. And I think it's this always kind of evolving landscape. But I think that we should totally be thinking on the order of 10 years as a rough timescale for whatever this might be.

If you want to be like, when does Coca-Cola or Procter & Gamble have agents running around doing every single task in the enterprise across every crevice of the organization hyper-successfully? That's a multi-year kind of transformation. I'm making up an example. Maybe they're already there in particular, but this is just what's going to happen. Now, a funny thing: some of this is actually weirdly a byproduct of the industry. If GPT-5 or Opus just snapped online right now, you could probably do this diffusion in two years or three years, and we could probably all do the change management collectively as an ecosystem.

The problem is, the breakthroughs keep happening faster than the customer can implement any kind of standard architecture. And those breakthroughs oftentimes basically undo or make obsolete the last thing you implemented. So it's this really bittersweet thing, which is, like, the technology is getting so advanced that it makes obsolete the prior thing that you implemented, which actually means that the rollout takes longer because there's no stable environment to roll things out in. If you went to an enterprise right now, it's actually a period of maybe the least amount of consistency I've ever seen in IT around the following question.

I want to go deploy an agent to do client onboarding or to review some set of knowledge work in the enterprise. I could probably lay out up to 10 to 15 reference architectures to all solve that problem. That means that every systems integrator, every software startup, every lab is pitching a customer 10 to 15 different variants of what they should do to solve that one problem. And so what that actually leads to, ironically, is more lengthy sales cycles, more complexity in decision-making, because you're like, man, that Anthropic managed agents thing looks incredible.

This is really awesome. That's exactly how we should do it. And then you're like, oh, this OpenAI Frontier is really good. And then you're like, oh, but this startup is actually pitching me something that means I'm neutral to either of those. And then you're like, oh no, actually my workflow vendor can now do this. It is a madhouse on that front right now if you're a CIO. One of the memes is nobody's signing up for more than one-year deals with the labs.

Part of that is because of the pace of innovation that's happening. It's a byproduct of actually how much innovation we are seeing. But that means diffusion ends up taking longer than I think most people think.

So the one part where I'm just like, I'm a hammer looking for nails, is I see most things as a data problem. And data with associated things like access controls and how well-defined is the workflow, et cetera. Most agentic challenges, I think, are inversions of basically, you have a data challenge. The agent can't get access to the right information to do the work. Maybe they have access to too much information, in which case then they're just going to roam around and do the wrong thing.

Or they have access to too little information, in which case obviously they're not going to work, or they don't have enough context to be able to execute the task, which means they need more information surrounding the task. So we see data problems everywhere that we look. And so I think one of the first steps is your enterprise just needs to be prepared from a data standpoint and from a core architecture. And I think for 20 to 30 years in IT, it was sort of okay to have all these systems, some redundant, some not well managed.

You could kind of throw humans at the problem and just sort of say, yeah, the data science team knows where the bodies are buried in the database, and they know what table to use and what table not to use, and they know how to work through that particular data model. When the business asks a question, the business goes to their analytics team or data science team and they say, hey, tell us our attrition rate, or tell us our growth in Spain, or tell us our upsell rate of this product.

The data science team is this constrained, centralized function. It's maybe 10 people or 100 people, but it's not every employee. They go and they know how to work the numbers, and they have another spreadsheet that's living on top of Tableau, and then they're moving some stuff in there and they're doing some calculations. And then they give you the answer. Now all of a sudden you're like, oh, well, I want to democratize that to everybody. And now I want to MCP into whatever the data store is of that thing.

And then guess what? Everybody's getting a different definition to their query because actually the way that company calculated things is like, no, they do an FX-adjusted number or they measure their net retention rate differently than what the model was trained on. And so all of this stuff where you now actually weirdly have a data problem and a data integrity problem and an access control problem, that actually becomes one of the more meaningful projects ahead. I think you're smiling way too much, which means either you funded something here or you're seeing it, or I don't know.

Oh, 100%. It's been the same problem for 20 years. But again, we could throw people at the problem before. At the end of the day, when I had a question about data, I knew exactly the person to go ask. And I didn't ever have to worry about it as Aaron in a company because the data science team had to worry about it. Now, if somebody gives me access to that data as a resource and I start asking questions, boom, that's a way bigger problem because I might go to somebody and be like, hey, why did we grow 13% in that one area?

And they're like, well, your data is wrong. It's actually 16%. You just didn't adjust for FX or whatever. It's a much bigger problem now when everybody can go and do that. And that's just the structured data. Think about all the unstructured data. Most enterprises have five different places where their contracts are being stored. Their roadmaps are across 30 different locations inside of their data environment. That's obviously the space that we see day in and day out. So if you're going to have a world of agents and you want to have some flexibility on what agentic platform you deploy and what type, deploy Claude Cowork or do you deploy managed agents or do you deploy Codex, then you need to get your data into a format that is going to work within that kind of agentic ecosystem.

So I think a lot of the work to be done is blocking and tackling in the enterprise on IT, which is like, how do I get agents that context? How can they make sure they have access to the right information with the right security levels, with the right entitlements? And that is a big chunk of work ahead to ensure that agents are going to work properly. To do that, that's where the internal FDE motion comes in. So we are seeing this increase.

Some of it is repositioned internal IT people or software engineers. Some of it is just straight-up hiring new kinds of people and talent for the organization. But I do think this is a highly technical skill. It's a highly technical role, which is, do you have technical people in your organization that you can say, "I'm going to have you go sit next to the business or within the business, and your job is to understand the patterns of how these people work and make sure that they have the ability to use agents to go in and do that work."

And some of that will be agents for people that are prompting, and some of it will be agents that are just working in the background and automatically producing value for that knowledge worker. But your job is to go understand the workflow, understand the process, and then marry that with the full potential of where technology is going and make sure that the data is set up the right way, the instructions for the agents are set up the right way, and you have the right human-in-the-loop elements of doing that work.

That's a lot of work for most organizations.

Yes. I think that might be an N-of-1 situation. For mere mortal companies, you're going to have people going and doing this, and those people are going to look like the next generation of a software engineer or IT engineer. I think it's actually incredibly exciting work because you get to go and transform: how does a life sciences company run? How does an industrial giant operate? How do marketing campaigns get produced? It's actually very exciting technical work, but a lot of companies don't have this talent right now, so they're going to actually have to go and hire people out of CS programs or be able to pivot engineers into these kinds of functions.

As an asterisk, it's actually why the doomers are also wrong about jobs, because this is actually going to be a very real sustaining job that is not like a one-time, you implement the agent and you upgrade the system and then it works forever. It's like, no, once the model changes, there's another set of work to be done. You have to make sure: did you get the gains of that model improvement, or do you have to leave behind some scaffolding that you had to build for the prior model?

Lots and lots of work to be done in this area.

Yeah, it's so funny because the AI super-accelerationists, which sometimes actually end up in the same quadrant of their views as the doomers, and the, let's say, I don't know, skeptics as another kind of end of the continuum, they land in the same spot on this particular topic. They're like, man, I can't believe we have to have people go and do this. It proves the skeptics right, and somehow the doomers and the accelerationists are like, oh man, it's not happening the way that we thought.

Then it's sort of this cynical thing. What's funny is you have people like me that are like, I just know enterprises, and it's like, this was obviously 100% going to happen. You guys are all crazy if you didn't think this was going to happen. It neither proves that the technology is not amazing, nor does it prove that—it obviously had to play out this way. Why did it have to play out this way? It's because we built this insane technology that's incredible at using computers, incredible at using software, incredible at writing code, incredible at using tools.

But guess what? It has a fixed amount of memory. It has a fixed amount of context it can work with. It could do totally dramatically crazy stuff with your data. So obviously it has to be implemented by somebody hyper-technical. Obviously it has to be implemented in a way that drives change management in an appropriate way for that organization. So to me, this was 100% priced in, and the market just took way longer to get there than I think anybody would've realized.

You could just feel this the moment you saw agents be real. You're like, yeah, this is amazing. And it's totally going to take a lot of work for enterprises to go and implement this.

I think the headless conversation ends up usually in the same kind of spot as almost every other technology trend in history, where you always think that the next medium fully eradicates the prior medium. And then you're like, oh no, actually, I do have an iPad and a MacBook and an iPhone. And for some reason, I don't just use my iPad as my phone and my computer. It's like, no, I have three devices. They all do something different. And so I think it's going to just be one of those things, which is, if I'm going to go and do a complex query that involves Box data, Salesforce data, Workday, and it's got to triage a bunch of stuff, I'm going to do that fully headlessly.

Inside of Claude Cowork, Codex, or something else, unquestionably. If I want to go and work on a set of documents and build a data room and go and make sure that I'm sharing all my contracts the right way, at some point, doing that via text is sort of slower than just doing that in a graphical user interface and with all the knobs that I know how to interact with, and I get a lot more leverage that way. So I think it's just going to be this sort of dual model.

With the one nuance being probably by database queries, headless will just be 100 times larger than the interface-driven way of doing work. And so we'll just have to understand that by volume, agents are going to be banging on these systems far more than humans ever did. The human will probably land as an end-user seat within that piece of software, and they'll get a certain amount of allocation of usage as that end-user seat. I believe that they should have a right to use that software and that data via agents up to a certain amount.

That certain amount will be different based on the vendor, depending on how compute-intensive that workload is. Then, past that certain amount or when it's fully just an agent, then it'll be a consumption model. I think any enterprise software company in three years from now that gets through this AI transformation period, it'll have a seat business model, assuming it has an end-user component, and it'll have a consumption business model. And that consumption business model in some businesses might be bigger than the seat model, and some might be smaller just because the seat still takes up such a big chunk of the work.

But I don't believe that we move fully to consumption and fully to headless because I think there are a lot of reasons why you still want to go into the interface and poke around.

I think this is sort of a tougher category because it all depends on the agentic use case. I can totally see a world where we already have some customers playing around with this idea of, should agents have a Box seat? Because they actually need to store data that gets retained and governed over a long period of time, and you want to be able to track it and manage it just like a person, but it's got to be stateful. That kind of makes sense.

We have to give it a name and a thing in our system to make that work. Do we charge the same as a regular end-user seat? Probably not. Probably it's got to be cheaper. But then there are a lot of situations where the agent doesn't need an ongoing seat; they just need to be doing a lot of operations, in which case it's probably just pure consumption. I think it really depends on where your software category lands on: is there a reason why you'd have an agent be stateful in that organization and kind of take on an identity and take on ongoing work, versus it's a thing that just every employee calls on demand?

And that would probably determine what that business model looks like.

We kind of think about it as everything you would ever want to do with your enterprise content, you should be able to do via an external agentic interface. And so the examples are, let's say you want an agent to go and read through 100 contracts or review a data room that you've created for risks in a client. We just launched this example with the Claude for Legal Solutions announcement. So you can put all your contracts in a folder, and then the agent within Claude Cowork can go in and kind of work through all of that data and use it as a knowledge repository for its work.

You could do a client onboarding process where the client has to upload a bunch of documentation. It's got to get stored somewhere and then processed. All of those are situations where Box will be the backend, sort of behind the scenes for some kind of agentic work that's happening, whether the user is interacting with the agent or the agent is just running on some kind of deterministic or non-deterministic event that happens. We conveniently have not had to do massive, crazy transformations of the model because we've always had an API.

Basically, almost on day one of the business, we had an API. So for us, whether it's a headless agentic user or a headless system machine application user, eventually it talks to our system in roughly the same way. There are some nuances, which is like headless users might want to sign up for the service on their own. And so we've had to think about account provisioning differently, or they might use our search in a different way where they need more context than what a platform deterministic use case would have looked like.

They're going to use our search tool very aggressively. So we have to inform them, as they're doing their searches, how to think about this certain context that's inside these files. So there's a lot of work that we are doing to make our system better for agents. But the concept of being headless and the concept of being API-first is kind of wired into our DNA.

This sort of relates to the AI coding versus the rest of knowledge work. And I kind of set it up at the very beginning on, obviously, this diffusion thing. But the reason why I'm less concerned about the job part and more optimistic is, when we most get fearful about jobs, we look at coding as the example. Again, back to this coding issue. Coding has this other unique property that's kind of different from a lot of the rest of knowledge work, which is, if I write code and it's super sloppy because the agent is writing this code, it kind of, at the end of the day, doesn't matter, short of a security risk or maybe it's using extra memory that it shouldn't use or whatnot.

If the software just runs, I could have an application that has 100,000 lines of code or 1,000 lines of code. If it's doing the thing that it needs to do, it really doesn't matter. This is sort of why you're seeing a little bit more hands-off-the-steering-wheel emerge in coding. It's like, we're just going to throw agents on agents on agents, and then that's going to go and solve the problem. The other maybe most topical category is legal as an alternative. In legal, you can't do that.

I can't have, on line 2,004 of the contract, it sort of adjusts the liability rate slightly because I had an agent go and write this thing whole cloth. There's no way for me to verify the—I mean, I can layer on agents and agents and agents, and they review each other, and then they review each other again, and I can get kind of down to smaller and smaller percentages of risk. But at the end of the day, you're still going to have some lawyer that has to basically say, I believe that this is 100% valid and I can put this up for my client or I can go and ship this.

This last mile of agentic work, I think, is going to remain in a much broader set of knowledge work areas than I think we realize. I've mentioned this a little bit in the past, but there was this funny article from the Financial Times, like three weeks ago, of lawyers being inundated with all of these contracts that their client created, or the client went to ChatGPT and asked a bunch of legal questions that now the lawyer has to go and adjudicate and provide answers on.

I think it's a microcosm of the real-life application of AI, which is it can accelerate one thing massively. I can review the contract far faster, and I can go and get to the risky areas or can generate a contract much faster. But in both those scenarios, there's still a lawyer on either end doing real work. So I've removed one part of the bottleneck, still unconstrained by another part of the bottleneck. That's just why the jobs don't get eliminated as the first thing.

The second thing is, we've talked about this and the market is, I think, fully beaten over the head on Jevons paradox, but nobody ever factors in the Jevons paradox thing. I mentioned this with designers, but designers are kind of a maybe minor example relative to all of the areas where this is going to show up, which is if you go to Caterpillar or Eli Lilly or Johnson & Johnson, John Deere, I'm just naming big industrial companies, just not in Silicon Valley.

These companies forever, they want the top engineers like everybody else. They are working on incredibly mission-critical areas of creating a new drug, building autonomous industrial equipment. They need top engineers like everybody else. They have to go and sign up for similar-level scale projects as everybody else. But those engineers have largely seen that you go to CS and then you go to Google or you go to Meta, et cetera. What's going to happen now with agents is all of a sudden all of those other companies are going to light up far more technical projects and technical work in their organizations because, for the first time ever, one of their engineers now has the capacity of three or five or 10 or whatever metric you want.

And so that's going to get them to sign up for way bigger projects than they would have been able to afford, which means that they now have a greater demand for that engineering capacity. And then you throw in one more category, which is every basically small business on the planet is going to be able to go in and augment any of their functions that they wouldn't have had internally before with agents. And each of those functions, back to the human-in-the-loop component, often will need some human to be going and doing the extra work that it takes to make that agent actually effective.

So let's say you want to do the marketing campaign agent and you're like a solo entrepreneur. Maybe it's a three-person team and you're doing it and you're moonlighting, but then you're like, oh, this is actually really effective. This marketing campaign is working. Probably the next thing I'm going to do is go hire a marketing person to go and manage these agents to go and do this at scale. I'm a complete Jevons paradox-pilled person because, first of all, I see it in our own business.

I see it in customers and I see it in small startups where these startups are hiring as fast as possible because they have all of these job functions that their productivity gains are causing them to need to hire for. So you can kind of pick your argument, but there's multiple reasons why the job argument ends up falling on its face once you start to see actually how AI is rolling out in a lot of organizations.

For us, as an N-of-1 example, we continue to hire in a decent percentage of the functions that we've always had. Just the work that those functions are doing is going to look entirely different in the future because they should be augmented meaningfully by agents doing additional work for them. It's certainly changing what we can invest in and what we tilt toward. But some of that is actually just a byproduct of our business evolution and where we're seeing demand in the market. But we're hiring people in marketing, we're hiring engineers quite actively, we're hiring people in IT to build these agents, we're hiring sales reps.

So those contours aren't shifting as much as one would expect at the name of the job title. If I had to really lean into the future scenario, I think what happens is there's some kind of embedded AI/IT capacity in most functions. There'll be an AI person or team in sales and an AI person or team in marketing and at different subsections of marketing. They already exist in engineering because engineering has been going through these productivity gains. And I would assume that that person or team, their job should be looking at, like, hey, what do you do every day as a demand gen person?

And how can I bring automation to that? So we could be testing five times the number of campaign ideas and keywords, and we could be integrating one part of the design process to a campaign lifecycle much faster. So you have a kind of technical person wired up next to the business. Over time, like in 20 years from now, is that maybe just the new expectation of one of those businesspeople? It could very well be. Then you'd compress that, which is like the new job.

It might be that in 10 years from now, if you go into marketing, you also basically are going to be a CS minor equivalent of whatever agents are doing. Your job is, you better know how to wire up a fully agentic marketing workflow. Again, I chatted with ChatGPT, but I could deploy a full end-to-end marketing campaign as one of the tasks in marketing. Right now, that doesn't really exist in most areas of knowledge work. That might change again.

I think it feels like it's every function augmented by agents, and then in some companies, I can totally see the scenario of where the perceived risk is. So in some companies, you're like, I had 10 designers, but if I had an agent next to my top five designers, they would just do all of the stuff. I think that's very, very plausible. But there's going to be then equally 20 companies that say, I can now do design for the first time ever in a very high-quality way.

And those people will just take those five designers and employ them for the first time. So on a net jobs basis, this is why I'm largely unworried. I think what happens is there are definitely some companies that reached saturation of their particular demand of a function already with humans. So agents coming in, they don't have more work to do. But I think that's true of maybe 10% of the economy. The rest of the economy is like, oh my gosh, actually, if I could have one designer that now does the work of 10 designers, then that's the first time I can go and hire that designer because now they can be doing websites and campaigns and videos.

So I think you're going to see some collapsing of, obviously, all of the micro-adjacencies of functions, but not so far that it breaks and collapses entire domains of work. I think that there are people that have an eye for design, and I think the people that have an eye for design will just be both designers and managers of agents doing design. I don't think that means you take a copywriter and you make them a world-class designer. Just as in engineering, where we're already seeing, obviously, this kind of tension, I think we're already coming to the other end of it.

There was this period which is like, oh, the product manager can ship production code. And it's like, okay, but it's probably going to be slop. Or the engineer doesn't need the PM because they can write their specs. And it's like, okay, but who's going to get on the call with the next 20 customers when you want feedback on that feature? Do you really want your engineer taking from their engineering capacity time to go do that? And it's like, no, those actually make sense as specialist jobs.

Like Adam Smith figured this out a long time ago. Division of labor is a really powerful thing. Agents haven't fundamentally changed the concept of division of labor. There might be some new definitions of where the divisions fall, but you probably want your designers being really good at design. You probably want your sales reps really good at selling. You don't want them having to do lead generation as a side project. You don't want your product manager trying to figure out how to become a designer.

I think that there's less collapse than the super hype train is on right now, but there's probably incrementally more collapse than what we would've thought 10 years ago.

Not to get too paternalistic on this, but I do think that companies owe the employees and broadly society some help in this regard. I think there is a social contract, which is like, you probably do want the next generation to be having jobs, and you probably do want people to not have complete and utter fear when they're leaving college of, are there jobs on the other end of this, or am I moving into this ruthless dystopian environment?

Totally. And that's just the beginning of the issue. I'm the most deeply pro-AI, pro-innovation, pro-acceleration person you'll find, up to the one point, which is if you stop caring about the overall sort of societal impact and people side, then I'm not even worried about the revolts of, like, we're going to get socialism or whatever as a political matter. It's just like society works really well when people want to work at companies and they can feed their families, and you don't want to blow that up just because you wanted one extra point of

operating margin. So I do think companies owe their employees and the future employees a real shot at upgrading their skills and upgrading their talent. So some percentage of this is on the companies themselves for the upskilling, for the training, for the enablement, for all of that. Now, once you've done all of that, and as a hedge, as an employee, I'd be doing this no matter what, because I'm relatively likely to go on my own and do everything. So it's very easy for me to say, but as an employee, I would be spending 5% of my time, 10% of my time, whatever you can carve out, just getting really good at this stuff.

I mean, your podcast alone would probably add like 30% extra knowledge to every person on the planet if they were just listening to your average episode, maybe minus this one.

Okay. But they should just be doing this, and there's five other podcasts that do this, but not as well. Not nearly as well, because mostly it's just fighting with Jensen. So first of all, everybody should be consuming some percentage of this content and having a fluency. You have to use the tools. There's no way around that. I mean, you should try and find a way to spend $100, $50 a month, some number. Like, turn off one of your cable subscriptions to do this and just start to use agents a lot.

Use Codex, use Claude Cowork, use Perplexity Computer, use Cursor if you're semi-technical, and just figure out what these things are doing, how they work, connect it up to a couple systems, try it out on a personal workflow, have some fluency, and then let your mind kind of wander a little bit of like, well, what would I do if I had this sort of—everybody has a slightly different analogy for it. One of the best ones, I guess, that's emerging is like, what if I just did have a chief of staff that I could throw any task to and it could go and do all of that stuff and then come back?

What would you give an unlimited chief of staff to kind of work on? That kind of opens up your mind a little bit of, oh, this is actually the power. How would you rewire that workflow in your organization? I think there's a lot that you can do. It doesn't require insanely high agency to do this. You don't have to be a YC startup founder to do anything that I just said. It's available to every knowledge worker. You should give it a shot or use the free tools that are out there.

Please use the VC subsidies to your advantage as much as possible and start playing with these tools. Even I have had to rethink my way of thinking about work multiple times in the past year. One fun shout-out: Perplexity Computer, I find, does a better job than any other computer-based agent for just being a workhorse for going through websites and doing search-related things where you have to click on the page and you have to read the page and all that.

And so I give it these tasks where I start to think like, man, actually, if I did have an agent that was always running ongoing and it was doing XYZ thing—these are maybe a sales workflow—I could probably very quickly make a lot of extra money by doing that on an ongoing basis. But I wouldn't have known that if I didn't, at 11:00 PM one night, go in and start a project that I actually just pushed the limits of this thing. And on the other end of it, I'm like, oh, this is incredibly powerful.

Now, fun asterisk: at the end of that project, after doing it, my conclusion was, man, I don't ever want to do that again personally. I'd rather hire somebody to go do that for me. Another example of the job creation thing is I have multiple tasks where if I hired a person to go and use agents to do something for me, I could easily pay for that person overnight, but I'm not going to myself go and do all the wiring up and all the prompting.

You will actually see, interestingly, if you're an executive and you start to do this, you'll see lots of areas actually where you should hire more people because you're like, oh my God, this thing is spitting out an incredible goldmine of value. But who's going to go and run with that? What are you going to do next with all that value that was created? That's the next set of jobs. So I think as an employee, you got to be using the tools and pushing your kind of thinking on this.

I remain pretty confident and optimistic on the need for a kind of a bridge layer from the AI capability to the end-user workflow. And some might sort of say that this gets kind of Bitter Lesson'd out, which is, oh, these things are wrappers on the model. And at some point, there's a training run where it just is the final training run that renders the kind of vertical app or function-specific app not as useful. And I think that is a little bit too much of an accelerationist view of what people are doing with the tool, which is, like, it's not just what the model is spitting out or the model's ability to review information.

It is, how is the thing wired up into the business workflow? How did it get the context that it needed to be useful? I think if you're in an industry or a line of business, there's a heavy amount of integration with datasets, heavy amount of bespoke workflows that that company does. That usually means that there's going to be a need for change management, implementation, ongoing support, ongoing expertise. And unless the labs build out literally the equivalent of hundreds or thousands of people for every single vertical in every single line of business, that means that there's actually a lot of opportunity in that kind of bridge area of the work.

Now, what is the exact mix and makeup of what that work looks like and what those opportunities are? I think that's ongoing. And I think this is sort of one of the big kind of questions now. There's this interesting thing that I'm trying to think through and workshop a little bit, which is the labs are obviously going to keep moving up into the applied use cases, and they're going to do some well and some not well. We're seeing the announcements all the time, and I think there are some announcements where I'm now using the lab for that thing as opposed to using the vertical application because it was so good, and there's some where it's like, no, that was still like the poor man's version of that.

And so you still need the vertical application. And there's a mix of all of these. I do think at some point maybe things will settle out where the labs will have to decide: do you want these things to be plug-in intelligence for applied use cases? Do you want everything to orbit within your application? I think we're going to have to see where the tension ends up landing on this. Some of it is, to some extent, an account control issue. If you're a lab, you don't necessarily want to have a vendor above you that can swap you out at any moment per the token cost point earlier.

So it's very strategic. It makes sense, which is like, I don't want you to go and be able to swap me for another model the moment that you find one tweak that could make that more efficient. So I need control of that account. But obviously, by virtue of having control of that account, now there's sort of less to be done in that vertical layer. So we have to kind of figure that out. I think we're very early in where that lands, but I could see some world where maybe there's a kind of a peace treaty, which is like, if you bring in the intelligence from this lab, then X happens inside this product. Very, very hazy.

The hyperscalers actually had to figure this out, interestingly enough, where they basically had to figure out where are they going to compete in the applied layer versus where are they going to partner and kind of be a pull-through mechanism. You can see things like the AWS Marketplace be, I think, a very successful project on their end, and they are pulling through tons of products that they might otherwise normally compete with because the bigger prize for them is the most amount of infrastructure. The labs might equally think about this as, okay, well, actually, the biggest prize is the ultimate amount of inference.

So we do need to make sure that there's a balance of that ecosystem. I think we're just in the early stages of how these kind of things land. The great thing is capitalism is very good at this, which is if some companies lean too heavily in a non-ecosystem approach, then somebody else emerges and you can balance it out that way. But I still remain very bullish on a lot of the applied layer of AI, simply because the level of focused approaches you need for these things tends to be much more intense than I think people realize.

The difference between us doing a prompt with AI, seeing this incredible outcome, and we're like, oh my God, obviously that thing could completely destroy this one application, to then the ongoing daily mechanics of that product, the implementation of it in a workflow, the knowledge worker that doesn't have time for any of this stuff—they don't want to know where the skills file was stored in their file system. They're like, no, I just need to move on with my day—are going to have their opportunity to compete.

Thanks, Matt. Appreciate it.