Phil pods with Box co-founder and CEO Aaron Levie

Hey, thanks Phil. Good to be here.

Sure. So I'm co-founder and CEO of Box. We started the company back in 2005, and this was after a number of years trying lots of different startups. We actually dropped out of college, so my startup experience is more like in high school and in college, building different ideas with a variety of friends. And one of those ideas that we landed on was Box, and ultimately what we're doing today.

It is interesting that everybody does seem to be getting younger. I'm getting emails from 16-year-olds that are looking for funding. So I would say we now sort of have built the formula for how to drop out of high school or college, how to build the startup, how to get funding. So it's been fun to watch the next generation.

Yeah, I've been fortunate. When we moved to Silicon Valley, it was in the mid-2000s, so we were in the ramp-up of the SaaS wave and the early days of cloud. And so I've been very honoured and fortunate to be able to get feedback over the years from folks like Marc Benioff, who was extremely helpful in building up Box, and some OG names like Tom Siebel or Michael Dell, giving fantastic advice over the years. So I've had amazing mentors and helpers along the way. And then I'm very religious about trying to learn as much as possible from the history of software and technology. So I've got a lot of benefit of all the literature and content and books in the space that have documented all the various strategies. So we've tried to put all of that information and advice to good work, and it certainly helped us scale over the years.

Yeah. So I think what's interesting is the first phase of AI is that we're augmenting the work we're already doing. That was the chatbot era. This is where you're writing code and it's typing ahead a little bit faster. You're writing an email and it helps generate the content. That leads you to maybe a 10 or 20% productivity gain inside of a workflow, but is less likely to completely transform what the business outcome is that you're getting. The closest parts of work where we've seen those business outcomes emerge is in coding, because we've moved from agents that can add a couple hundred lines of code to now agents that can go and do thousands, or tens of thousands, or even millions of lines of code in a single run or a single session. And that breakthrough was basically letting agents actually go off and do lots of work for you, and make decisions, and execute the full plan. But that type of work is, so far, largely bottled up in the engineering department. And there are some interesting reasons why I think those gains have been captured most by the engineering org.

Engineering is an area where your direct value creation often can be correlated to the amount of code you write. Obviously it has to be good code and useful, but it can just be a lot of text that comes into a single file, and that actually correlates to value generated. There's a lot of work in the enterprise that doesn't have that same correlation. If I wanted to go and apply automation to our sales team, or our marketing team, or our HR organisation, that's much more about workflows that have to be executed. That's many, many stages of a process where at different points in time another person has to enter the process and make a decision or add value, or maybe you need feedback from a customer. And so those are not workflows that are as prone to being automated in the same way that we've seen with, let's say, agentic engineering. And so I think we're in for a very long journey now of diffusion of AI into the business, and some of the lessons will be learned directly from looking at what happened with engineering. But in many areas it's going to actually take really re-engineering the underlying business process and workflow itself to get the full gains of agents. And that's the area where most enterprises are running into the next phase of agentic adoption: okay, I actually have to go and re-engineer the workflow. I have to get data into a new environment. I have to set up agents in the right part of a process where they can be useful. I have to figure out where the human now is in that workflow so they can review the work and make sure the agent doesn't go off the rails and execute the wrong task, or produce less useful outcomes or work product. That's a lot of work ahead for probably realistically the next decade in most enterprises.

I think what happens is, for probably the first few years of AI, it was still largely a CIO budget, because it sort of was an output of the technology organisation, and so everybody thought that okay, well, the funding of ChatGPT and the funding of Claude and the funding of these agents is going to come from IT. The challenge is, as you reach a certain threshold of expense where you're no longer paying a couple million dollars for AI, but now you're paying tens or hundreds of millions of dollars for AI, it's just unreasonable to trade off that type of expense envelope with other more deterministic parts of your software stack or technology stack. Having to decide between your networking gear spend and your inference and AI token spend — those are completely orthogonal investment areas of a business. And so what naturally happens is it starts to flow into the line of business, because the line of business — i.e. the marketing department, or the HR department, or the R&D department — actually has to make trade-offs between what do they want in their organisation to be agentic, and what do they want to be either human labour, or other areas of expense, outsourcing to partners or other organisations. So ultimately agents look a lot more like how you would have funded a BPO firm in the past than they look like buying software. The BPO firm wasn't funded by the IT department, unless the BPO was IT work. It was funded by: I'm the customer support team, and I want to be able to have customer support tasks be done by some agency. Then the customer support organisation ultimately is the holder of that line item in the budget. Agents kind of have that similar product, which is: if I'm the head of engineering, I have to determine, given a hundred dollars of organisational spend, do I want ninety dollars to be on people? Do I want ninety-five on people? Do I want eighty-five on people? And then what do I want to do with the five or ten or fifteen dollars? Do I want to put that into tokens? Do I want to put that into training up my engineering team in different ways? That's actually who needs to hold on to the budget once you've reached a certain scale of spend, which agents clearly have ended up hitting.

I think it's still pretty mixed. You could probably get in a room, let's say, with ten lawyers, and you would say, "How do you want to pay for your AI?" And five of the lawyers would probably say, "I want it to be per unit of task. I want it to be per contract reviewed or per contract generated." And then the other five would say, "I want this to just be the amount of usage of the system, because I want to be in control of my level of efficiency and how I'm using your tool to save money or spend more." And so a lot of it is the business model of the end customer, and how they bill their customers. Do they do cost-plus as a pricing model for their customer base, or do they want everything folded into their overall service fee? I think there are just so many different dynamics at play here. In general, my rough sense would be that we should expect that AI will largely converge with a volume-based, resource-type-based pricing model. I think it's very hard to do these kind of fully packaged-up outcomes, except for areas that are relatively uniform across large sets of customers. So responding to a customer support ticket is relatively uniform. There can be difficult tickets, there can be easy tickets, but the economy has figured out roughly what that should cost. Whereas going and doing a large software project is completely bespoke, and a snowflake for every single company on the planet. So it's very hard to have uniform outcome pricing on software projects, which means eventually it converges on some form of cost-plus or volume-oriented approach. Which is why I think you're going to spend your tokens. I think your token pricing will largely be some kind of volume orientation on just what are you trying to tackle with agents inside the enterprise.

Yeah, I'm a little bit mixed on this one. I would say to me the issue is less about the shared nature of learning specific things, and much more about: do you need extra performance on a particular task or dimension that the horizontal models or the closed models are not able to support? So I would be less worried about the models themselves training off of you, because you can generally sign contracts with all the model providers to prevent that from happening. Even the Figma issue is a little bit unique, because there were dynamics where a board member was overlapping. It was less about the model itself being trained on the data. So I think the way I would think about it is: if you are able to get high-quality outcomes at an affordable price from frontier AI models — whether they're closed or open doesn't really matter — I would still currently bet on that. Because what's going to happen is you're going to see continued amazing progress from these models. They're just going to get better and better and better. And so you want to ride out that improvement curve. If there are some areas where the cost profile makes it completely impossible to use that frontier intelligence, or where you need the model to be trained on your set of data for some very specific type of task — like you're doing fraud detection at a large bank, or you're doing clinical life sciences research and you need to give the model a lot of bio data — those might be areas where training your own model, or having some kind of sovereign intelligence, can be useful. But you're making a judgment call, which is that you actually want to fork the model and go off on your own direction, which means you're not going to get the same benefits of the constant model progress that's been happening. And a lot of times that makes complete sense. There are a lot of software providers where, if you're Sierra or Decagon, or one of these customer support agents, there are a lot of use cases where you have so much data about your task type that it makes more sense to train your own model as opposed to use something off the shelf, because you can get it to be both cheaper and higher performance.

But then there are a lot of industries where it's just premature to veer off from this frontier set of progress, because you actually still need the ultimate gains that are left to come from these AI models, and you want to be able to ride out that progress curve quite a bit more. So I think there's a judgment call that has to be made in each individual organisation. The thing that I think is critical and non-negotiable is you should find ways of separating your corporate intelligence, your corporate knowledge and your corporate intellectual property from the model. So that way you have the ability to swap out models as new use cases arrive, or as new models are able to have greater capability. So there's this really interesting new era and art of IT architecture in a world of AI, which is: how do I ensure that I get all of the ongoing gains from technical progress in the AI space, and not accidentally force-fit my workflows or my business process or my knowledge work into one particular model paradigm? Having that abstraction layer ends up being incredibly important, I think, for most enterprises.