Right before AI, I was totally fixated on like everybody should just get cash flow positive and people shouldn't burn money. I've completely inverted again. I don't think margins matter right now. I think delivering agents that work matter, and that's the only thing that matters, because if you can deliver an agent that works, in two years from now that agent will cost you a tenth of what it does today to run. So just build agents that work.
Aaron, thank you so much for joining us for Greylock Change Agents. This is a new series that we put together where we're talking with CEOs of Agentic Products to really understand what it means to be building software using agents.
I didn't actually pick up on the pun of the thing until now. I saw the email. I was like, 'Change agent. Let's call them a change agent.' But it's actually just really about the AI agent.
A lot of marketing minds that one.
Aaron, you have been the co-founder and CEO of Box for 20 years now.
And public CEO for 10 years.
I feel like this is a perfect year to get you.
And you've been extremely vocal online and in the product around applying agentic AI, not just into Box but into the landscape as a whole. So we're really excited to have you on for tonight.
Awesome. We're going to dive deep into how people are using agents, how far they can go, and your theories of really what the future of SaaS looks like.
Yes, we're not predicting the future. We're inventing it right here.
So maybe to start, tell us a little bit about how you've adopted agents at Box, both in the context of the product at Box and also how you've used them internally.
Yeah. I'll do the internal just super quickly because I think the product gives us a little bit more terrain. Internally, we're probably adopting very similar to how you would expect any company that has, unfortunately, years and years of processes that have been built up and people managing those processes, which means you can't blow up everything the way you can as a brand new startup with a clean sheet of paper. So it's a lot of bottom-up adoption of things like Cursor and the latest tools, with some degree of more targeted implementation of agents in a variety of workflows like customer support, inbound, and sales. But probably the greatest usage and impact is on AI for coding and our own internal tools for knowledge work. We've been very clear we're going to go AI-first as a company. It's not novel if you're a brand new startup because we're all trying to look more like that, but it's novel if you're a really large enterprise, and we can move a little bit quicker than maybe some of the largest enterprise software companies out there.
Yep, that makes sense. What have you seen? There are a lot of different ways it seems like you've adopted agents in the product. Today, what is the ceiling that you've seen for what agents can do for a company or a product like Box?
Yeah. The reason we're so excited, as you could tell from the tweets, is that I think we're like the 90th, 95th, or 98th percentile of things we've always wanted to do with our software versus things we couldn't do. If you look at the intersection of software companies that have wanted to tap into some set of use cases but the technology didn't allow it, we are at the peak of the peak. The reason is we deal with unstructured data, and unstructured data is so messy that it's very hard to automate things around it. For years, we'd go to customers and say, 'You have all your contracts in Box. What if you could better understand them and orchestrate a contract workflow? Or you have all your invoices in Box, what if you could handle them more quickly? Or you have all this research data for clinical drug trials, what if you could understand it?' We've had all this promise that has been relatively unmet or underexploited because it's really hard to do those things in a pre-AI world. People would implement OCR technology, an RPA solution, or send data to a BPO provider to get it processed. All of those solutions don't scale. They're way too expensive, going use case by use case to bring automation to the work, so it rarely ever actually happens as promised. So what's emerged is we manage lots of data, hundreds of billions of files, exabytes of information, but most of that data goes underutilized. In our space, about 90% of corporate information is unstructured, and the vast majority of that looks like contracts, marketing assets, research files, invoices, and marketing campaigns. We imagine a world where you could tap into all of that, and up until the past couple of years, that was not possible. Now we see a future where you can actually bring agents to all of that data, answer any kind of question the customer has, and eventually automate any kind of workflow. Most work is around unstructured data, so that means you could bring automation to most work in the future as a result of these technologies. We want to be the best place to manage the information, bring the agents to the data, and then federate to any of the applications that customers work in.
Yeah, that makes sense. I'm going to structure the rest of the questions in two big buckets. Bucket number one is how are agents going to be differentiated and how do you build this differentiated experience with agent AI? The second big bucket is what do enterprise business models look like over time? Starting with differentiated agents, to start open-ended, what makes an agent great? How do you envision a delightful experience for a customer adopting one of your agents?
That in and of itself is about a four-hour podcast. There are probably a few different things it could break out into. At a minimum, there are two big categories: the scenarios where the customer doesn't even want to worry about whether it's an agent or not. We have a bunch of these use cases where the user interface doesn't change at all, but an agent behind the scenes is doing something, updating a field, moving something along a workflow. The UX hasn't changed much, but the agent is bringing the work that the person used to do into that. The area where there's a bigger change is when I'm an end user interacting with an agent, sending it off a task, and it has to go do a bunch of work in the system. It has to use various tools within Box, search for data, upload and download files. That's probably the bigger area of change we're working on. It has interesting properties like what is the future of human-computer interaction, human-agent interaction. We spend a lot of time figuring out how to get that right. How do we nail the experience of handing a task off to an agent, seeing the work it's doing as it happens, and then landing at a point where I can go review it, double-check its work, and ensure the full process is orchestrated well? We're spending a lot of time on how to deliver that in a delightful way with transparency but not so much that the user gets confused. For example, everyone uses Claude and can see the work it's doing, the code it's writing, the MCP calls it's making. The MCP tool names are janky because they're named by engineers, and most people would be scared if they saw all the things the agent was doing. So finding the right balance of showing the user what work is happening without showing too much of the inside of the computer. The big axes we're focused on are how much data an agent can work through, how long the tasks can be, the accuracy of what the agent can operate on, and the human-in-the-loop element.
Yeah, one thing you've said time and time again is we've been building software for humans, and now we're building software for agents. There's the UX component and also how the buyer decisioning works on which piece of software to buy if it's abstracted away from them. I'm very convinced that users are still going to want to see a lot. As long as the user wants to see a lot and touch buttons and move things around, then I think you have a very strong case for dedicated SaaS plays per category of software. You have to build software that is super powerful for the user to manage the agents and also makes the agents really effective. Starting from scratch, it's easier to do that, but you don't have a lot of existing data. If you're starting with some position in the market, you have a lot of existing data but can't blow up the whole interface because you have to bring your users along. It's actually great because there's an even playing field between startups and incumbents, as each advantage becomes a disadvantage on the other side. We'll just have to see how these markets play out.
One thing you keep saying is the data advantage is a big advantage. You said once that 95% of enterprise data isn't being used in a valuable way.
I think the number is probably far larger.
But at the same time, you've talked about context rot. How do we give these agents the right amount of context to actually make them valuable? How much do we train the end user to decide what to tell the agent?
We think about it a lot. This is one of those things where if you had a conversation in Silicon Valley, you could decipher the things we can productize and make the rest of the world understand, and then there are things where 0% of the rest of the world will ever understand. This is one of those. I've talked to engineers who almost talk as if they have this deep understanding at any given moment of where the context window is going to fail them, and they change their prompting. They decide, 'Okay, this is the moment where I need some kind of compaction step.' They can feel their way through the conversation looking at tokens used. Literally, no knowledge worker in the world will ever do that outside of an engineer in Silicon Valley. For that category, we don't know how to build software to make that easy. I have no idea how you could build software that helps a person understand that their conversation with the agent is going on quite a while and is probably going to start to screw up. That would totally freak everybody out.
Do you think you'll need to be able to do that, or do you think...
No, we just need the labs to fix this problem. Why don't we have larger context windows? The models have to be able to handle larger context windows. You still see extreme jumps in failures after like 50 to 100k tokens. The idea that a model can do two million tokens is kind of worthless if it drops off at 100k. This one exceeds my product understanding because the amount of understanding a user would have to have of what's going on behind the scenes is so crazy. Not to mention, the tool use actually took up a lot of the tokens, but the user has no conception of that. This is why tasks are going to remain relatively discreet in knowledge work for a while. This is why you have to have some degree of human in the loop to provide oversight. It's actually why I'm very bullish on the need for applied solutions in the enterprise. If you don't have a way on a per-use case basis to understand these things and help the user understand them, it's very hard. We can't take everything we see in Cursor or Claude Code and port it over to regular knowledge work because the understanding that users of those systems have of the internals won't translate to the lawyer, marketer, or invoice processing person in the real world.
Yeah, you've talked about this a lot where there's so much context within each function or vertical of how they operate. It's not like the model layer is going to build it all; you actually have a lot that you need to build on top of the model layer.
Yeah, there's a lot to build. Back to the context rot point, a lot of what we spend time on is how to get the intersection of the most amount of context for the model without it being too much, and the most accurate context. The fun problems we deal with are things like in our environment, pre-AI maybe you cleaned things up, but just think about a due diligence deal for a company. You arbitrarily want lots of data about that company—contracts, invoices, financial documents. The users supplying those have lots of different versions, version one through 73, and what is the pristine copy, the authoritative source of truth? Multiply that across a large enterprise of hundreds or thousands of employees. Just think about how messy everybody's data is. Agents are going into those environments, and the user says, 'Show me the latest contract with this client,' and there are 43 conflicting things that look like they might be the latest. A person can ask the colleague, 'Hey, I couldn't find it. Where do you think it is?' A human would know the internal semantics, like we always do underscore v1 for the draft version, and the one without the underscore is the final copy. The agent doesn't know any of this stuff. In most real live environments, there's a huge gap between the workflow we imagine and where it is today. That gap approximates a context problem. How do you make sure the agent knows how to find the right document? How does it decide small things like the difference between working through a document to find a set of facts versus using a document as knowledge to answer a question about another document? All these problems are super messy, and this is where we spend all our time.
How do you bring the customer along with you? You work with some of the largest customers in the world. How do you tell them, 'I promise you X,' with non-determinism?
This is the long slog of selling software. We're kind of used to it. The non-deterministic version is different. It's harder in some ways and not easier in really any way other than there is general market demand and pull, which is exciting because customers are deeply passionate about it. I'm a very big believer that evals are not going away, and that's a very good market right now. Customers are going to need evals on every important dimension of their business process they want to automate. We always sort of talk about vibe checks in Silicon Valley, but people aren't going to do vibe checks for their invoice processing system. They're going to want an eval that says it's delivering 99.9% accuracy, and we know how to kick it off to a user to review when that's not happening. One interesting micro thing: we work with customers where they give us ground truth data. We have a document processing system that extracts intelligence from documents and puts it into a database. A lot of customers don't even have ground truth data for that process. They come to us and want us to work on it. There might be a future job of just a ground truth labeler of enterprise data within a company or outsourced. As we remove jobs from one part, there'll be another set of jobs labeling the ground truth data to drive automation. The biggest impediment for most large enterprises is simply that you have to change your workflow so dramatically to get significant outcomes from AI. If you don't re-engineer your process for agents, you're capped at 20% productivity gain or something. You're not going to get 20x productivity gain if you don't re-engineer the process.
If you create an agent to reflect human work, you'll supercharge that human, but you'll never create a process that could be even better than what the human process was in the first place.
Even if you tried to replicate what the human is doing, the human comes with so much extra context that the agent doesn't by default. Most of our code bases weren't written to teach an agent that knows nothing about our codebase how to code. The engineer can just Slack their colleague or sit next to a person and bug them. The agent doesn't have that context. It doesn't have the context of what guidelines for a contract are good or bad in that organization, because that was just tribal knowledge. If you're going to deploy agents, you have to re-engineer your process for a world where a super intelligent person shows up but knows zero about your business and forgets everything 10 minutes later. How would your process work if that person showed up at their desk every day and forgot everything from the prior day? What would your process look like? Most people have not designed their workflows for that world.
