Author: Nataraj Sindam

As the artificial intelligence landscape becomes increasingly dominated by massive, cloud-based models, some innovators are looking in the opposite direction. David Stout, founder of Web AI, is a leading voice in the movement to bring advanced AI directly onto everyday devices. In a recent conversation, Stout details his journey from a farm in Michigan to pioneering the infrastructure for offline AI, a technology that prioritizes privacy, efficiency, and user ownership. Valued at over $700 million, Web AI is challenging the status quo with its vision of a decentralized “web of models”—millions of specialized AI systems working together across phones, laptops, and other hardware. This approach not only keeps sensitive data secure but also unlocks real-time AI capabilities in environments where cloud connectivity is impossible or impractical, from aircraft maintenance to personal health monitoring. Stout’s perspective offers a compelling look at a more distributed, accessible, and secure future for artificial intelligence.

→ Enjoy this conversation with David Stout, on Spotify or Apple.
→ Subscribe to our newsletter and never miss an update.

Nataraj: To set the context, could you give us a brief overview of your journey in the field of AI? When did you start working in AI or machine learning, and what was your journey like before founding Web AI?

David Stout: My background, as you mentioned, I grew up on a farm. When I was studying it, AI was very much vapor; machine learning was the actual field of study. NLP was progressing, but it was very early, even in regards to convolutional neural nets. I think this is important because my research started in a very much yet-to-be-defined space that was incredibly esoteric. There was no LLM to help you research; there were no AI tools. This was very much first-principles design.

We were looking at ways to bring convolutional networks like Darknet and YOLO to low-energy devices. At the time, these object detection or computer vision models were some of the most sophisticated and heaviest in terms of compute. They showed the most promise, in my opinion, of being truly disruptive. Having visual intelligence in spaces was going to be incredibly powerful. My research started there, and I was able to bring some of the best computer vision, object detection, and masking models to devices like iPhones and their Bionic chips.

Nataraj: And this was through your research at Stanford or at Ghost AI?

David Stout: This was through Ghost AI at the time, right around when I dropped out of school and started pursuing this full-time. We were bringing Darknet models to an iPhone. This got the attention of a lot of outside investors and technologists because it was the first of its kind. There was no TensorFlow Lite or PyTorch Lite tools that were bringing AI frameworks to devices. We wrote the whole thing from scratch, talking directly to shaders and primitives using the MPS framework on these devices. What we found, as in any moonshot, is you discover other things along the way. We realized that to bring these models to devices, we were discovering incredible compression and architecture techniques. This ultimately led to WebFrame today, which is our own in-house AI library and framework. Those early days mattered because it shaped what we ended up building. We had this desire to run models at the edge because, in computer vision specifically, if you didn’t have real-time AI processing, it was a null use case. Computer vision in the cloud is not super interesting. That’s where we started to really understand the value of AI at the edge.

Nataraj: What applications that we see today in the wild are a result of these efforts?

David Stout: The research of getting models to devices is continuing to play out; it’s not done by any means. A lot of these examples are still referencing a cloud model. Not a lot is happening on the device still. But yes, you are seeing basic object detection. A good example would be Photos on an iPhone. That’s running on-device, and you’re able to search and query basic object states or titles or names and index things. There are also modes on the iPhone in the magnifier that let you detect objects you’re looking at, and the audio kit will turn on. If you have a vision impairment, the object detector in real time will talk to you and tell you what’s in front of you. I think those are examples of some of that early work in the industry, but there’s still been a tremendous amount of focus on cloud AI. We’re seeing a lot more now in the private sector with people we’re working with where it’s multimodal, which we think is the ultimate paradigm.

Nataraj: You were working on compressing models onto devices, and in 2019 you started Web AI. What was the thesis for Web AI, and how has it changed over time?

David Stout: I started the company on three pillars. I’m a simple thinker when it comes to business and strategy; I wanted to know the utility value. I thought this cloud arbitrage is not going to work. This idea of big data and cloud compute is going to flip the whole cost structure upside down and is not super promising for AI in regards to individual ownership. It felt like we were going to copy the internet era and reproduce all the mistakes we made there. The thesis for Web AI, when we founded it in January of 2020, was: if we could bring AI to devices and run it privately in a way that a user or enterprise owns it, would people pay for that? Would people want that? If you could serve AI on a device and bring world-class intelligence and put it in someone’s pocket, is that valuable? The simple answer is yes, it’s worth pursuing.

The second question is what kind of use cases could you unlock that the alternative would be unable to do? A simple way to look at this is you have companies with IP-centric data that they can’t share with a foundational model. You have companies with regulated data they can’t share. And you have use cases that require real-time, no-latency decision-making that can’t go up to the cloud. These problems require an AI solution that lives in the environment, that they can directly engage with, and that’s state-of-the-art. That’s really the problem we were solving.

Nataraj: General audiences often think in terms of large models, especially post-ChatGPT. But before that era, it was all specialized models. When you identified these factors, what was your initial approach to productizing this? How did you focus, because the field is so wide?

David Stout: It is very wide. Actually, our strategy was the inverse. We said we need to be as horizontal as possible. We need to own the tooling, the methodologies, the frameworks, the communications. We don’t need to own the model. We want to be the pickax and shovel of an industry rather than be the best medical model company, and that’s all we do. The reason for that, and I think it’s played out quite like we thought it would, is that so many VCs told me, ‘You guys have great technology, you should just focus on one industry.’ We disagreed for the fundamental reason that we’re seeing now: if you’re not horizontal as a tech stack, you’ll get steamrolled by these incredibly smart, powerful foundational model companies. If you’re building an app focused on coding, I still think you’re at great risk of just getting steamrolled. I just don’t see how those companies have long-term staying power when the model that they rely so heavily on is not theirs. We decided to focus on the tools that made the models great, the way to retool these models so they could run anywhere, the connective tissue that lets the model talk to another model, to a device, to a person. And we will enable our customers to interact with their data with these models and make them better. That’s our staying power. We support everything from vision models to multimodal models across the ecosystem, with the idea that the platform is designed to be horizontal and not a point solution.

Nataraj: What type of customers use your product today? Can you give a couple of use cases to crystallize where Web AI plays a role?

David Stout: We work in industries where there’s highly contextual data that is not on the internet. It’s not on Reddit, whether it’s working on an airplane engine or with individual personal health data. It’s data that does not exist on the web that needs to be navigated, trained on, and personalized for each of these users to drive real results. We work with the Oura Ring, if you’re familiar with them. Additionally, we are working with major airline companies and aircraft manufacturers to improve maintenance as well as assembly. And outside of that, we are working with the public sector on all sorts of use cases that require AI to work anywhere, not just in a data center stateside. The ubiquitous connective tissue in all of our customers is they have data that no one else has. They operate in a privacy-mission-critical environment where data cannot go somewhere else, it needs to be highly accurate, highly performative, and it needs to operate at the edge.

Nataraj: I haven’t seen a lightweight personal model that exists on my machine yet. Is that model not possible, or why haven’t we seen that kind of experiment from any company?

David Stout: I think we haven’t seen it because the models that are easy to ship to devices are bad. People have become accustomed to a certain performance and intelligence capability. Web AI is actually in October releasing what you’re describing. We’re releasing our first-ever B2C solution, which is that: download it, run it on your machine, run it on your phone. Why it’s taken us time is we had to make some architecture changes so we have a great model that’s performative, that’s not disappointing, and that runs and lives on your phone. That’s a hard problem to solve. It’s always been easier to just have the cloud do it. I think a lot of companies are hitting the easy button on this one and just using the cloud. It works from a functioning perspective, it absolutely works; it’s just astronomically expensive and inefficient. The AI companies that are popular today are really focused on trying to solve the super-intelligence problem rather than solving the actual unit economics, monetization, and privacy problems. These tools will be valuable for users because now they have something that’s private that they own. It lives on their device, it’s personalized, and it’s ultimately safe.

Nataraj: There’s so much spending going on in data centers, rationalized by the argument that this will lead to something that looks like AGI. What are your thoughts on the trajectory of these foundational model companies and AGI?

David Stout: If we’re fairly pragmatic about what we’ve seen, there’s this common consensus that it will keep scaling, models will get better, and we’re going to steamroll everyone with the best model. My problem with that is the empirical evidence we have right now doesn’t say that. Pre-training, in all senses, is pretty much proven to be flattening. GPT-5 is an MoE, a model router. It’s a lot of post-model work. Most of the gains we’re seeing are post-training. For the last several iterations of these models, the majority of the advancement is happening post-training, which would indicate that we are hitting a plateau on this idea of training continuing to scale. I think we’re tremendously overbuilding. We have an energy problem, a water problem. It’s so early. I’m not a big believer in the long tail of the transformer architecture. To build all these data centers when we don’t even know the architecture… it’s questionable. For me, what makes the most sense is this idea that civilization is the only example of super-intelligence. You have groups of people with different contexts, talents, and abilities that build incredible things. We don’t have any example of singular super-intelligence. What I would say is much more likely is we see super-intelligence come out of millions and billions of contextual models that are living across the world as a compute dust that’s everywhere. That statement is far less risky than the one we’re talking about in parallel, which is, ‘I’m going to figure out a way to train this one model, it’s going to solve everything, and it’s going to be AGI.’ The civilization approach is not only theoretically accurate, but nature and science have demonstrated it to be true.

Nataraj: I was watching your talk where you had this very interesting line: ‘Prompts don’t pay bills.’ Can you elaborate on that?

David Stout: These companies have created bad habits. Prompting is horrible for their business model. They need to be proactive; they want to get prompting out of their business. Every question costs them money. It’s not the same model as internet companies, where a user coming to your website is a dollar sign. With OpenAI, when you log in and ask a question, you’re cutting into their profits. That’s a challenging business to be in. The philosophy of ‘prompts don’t pay the bills’ is about how we create AI interactions that are precognitive, working on behalf of the user so the user doesn’t have to ask another question. This supports the distributed model architecture as well. When you create an AI application on a foundational model, you use a system prompt to tell the model how to behave. Fundamentally, you’re telling the model to be smaller. You’re saying, ‘Be a doctor, answer this way, don’t talk about race cars.’ What Web AI would say is you just want a doctor model. And the doctor model is going to be far better than a system prompt model pretending to be a doctor. That’s how you get to super-intelligence: you have millions of models that are category-leading. They aren’t prompted to behave a certain way; they just *are* a certain way. This is why the internet beat mainframes.

Nataraj: What do you think about what XAI is doing? I feel like they are result-maxing for the leaderboards, but I don’t see XAI being used much in real applications.

David Stout: I think everyone trains towards leaderboards. You’ve seen the party games where people wear a sign on their head and have to guess who they are. AI is doing the same thing with a benchmark. When you train around a benchmark, you eventually realize what the benchmark is. That’s all that’s happening. A really interesting example we saw personally: we trained on open-source F-18 data for the Navy and ran a retrieval task against it. We got about 85-90% accuracy on a really complex maintenance manual. We did the same exercise with GPT-5, and it was 15% less accurate than our Web AI system. What was interesting is on the open QA benchmark, OpenAI was only seven points lower than us. So on the leaderboard, it seemed like we were far closer in performance, but in practical application, the delta is always a little bit bigger. I think the leaderboard is a little irrelevant to what’s actually happening.

Nataraj: We are almost at the end of our conversation. Where can our audience find you and learn more about Web AI?

David Stout: I’m on Twitter, @DavidStout. We’ve got a lot of new announcements coming out. We just released two new, really significant papers. We’ll be sharing more in our fall release, with several new products that will be available for users the day of the announcement. You can get more information on our website and on social media. I’m really thankful for the opportunity to come on and talk and learn from you.

David Stout’s insights offer a compelling vision for a future where AI is not a monolithic entity in the cloud, but a distributed, personalized, and private tool running on our own devices. This conversation highlights the practical and philosophical shift towards an accessible and secure AI ecosystem.

→ If you enjoyed this conversation with David Stout, listen to the full episode here on Spotify or Apple.
→ Subscribe to our Newsletter and never miss an update.

In an era where back-to-back meetings and fragmented schedules are the norm, how can teams reclaim focus time and achieve deep work? Matt Martin, co-founder and CEO of Clockwise, is tackling this problem head-on with an AI-powered calendar assistant designed to create smarter schedules. In this conversation with Nataraj, Matt delves into the complexities of modern work, from the “maker versus manager” schedule conflict to the surge in meetings post-pandemic. He offers his perspective on the evolving SaaS landscape, the real-world impact of AI agents, and why many new tools feel half-baked. Matt also provides a look inside Clockwise, explaining how they leverage AI to not only optimize individual calendars but to orchestrate entire organizational workflows, ultimately giving teams back their most valuable asset: time. This discussion is essential for anyone interested in the future of work, productivity, and the practical application of AI.

→ Enjoy this conversation with Matt Martin, on Spotify or Apple.

→ Subscribe to our newsletter and never miss an update.

Nataraj: To get started, can you describe to the audience what Clockwise is and how your customers use it?

Matt Martin: At its core, Clockwise is a very advanced scheduling brain. We connect to your calendar, whether that’s Google Calendar or Outlook, and you can use it as an individual. We start to analyze your calendar when you connect it, understanding the cadence of your meetings, when you tend to work, your working hours, and when you like to take breaks. We ask you a few questions to get to know you a little bit better. Based on that information, we start giving you suggestions on how to optimize your schedule for more time for high-impact work. Where Clockwise really hits its groove is when you start to use it among a larger group of people. Clockwise can look at the interconnection between you, other attendees, their preferences, and how to optimize calendars holistically. We do this at scale for some of the best companies in the world, like Netflix, Uber, and Atlassian, where we help optimize schedules for almost the whole company or complete engineering departments to give more time for high-impact work, meet with the right people, and have a sane work life.

Nataraj: You are living in this world of calendars and meetings. This reminds me of an instance a couple of years back when Shopify CEO Tobi sent out a memo saying you can cancel any meeting you want and we want to reduce the number of meetings happening in our organization. What is your general take on the frequency or number of meetings happening in a company? What trends are you seeing in how companies are optimizing their meetings?

Matt Martin: In a lot of ways, Clockwise goes all the way back to a famous article by Paul Graham called “Maker’s Schedule, Manager’s Schedule.” The reflection in his article was that, often inside software engineering organizations, the two modes of operation conflict. The managers control the schedules because they’re setting the cadence of meetings—syncs, standups, one-on-ones, team meetings—and they get a lot of their productivity done in meetings. Whereas for makers, people like software engineers and designers, they need large chunks of time to go heads-down on a project and get in flow to be able to tackle things. The first thing I would observe is that different people have different demands on their schedule, so there’s not really a one-size-fits-all here. I love Tobi’s memo because I think it’s always a good idea to clean out the cruft on a regular cadence and reset the baseline because things build up over time. But I would also caution that meetings aren’t inherently bad; it’s just another way of collaborating with peers and making sure you can get your work done. The question is, what are you trying to accomplish and who is the audience for it?

There are some almost gravitational forces when it comes to meetings. One is that we’ve seen in our data that the larger the company gets, the higher percentage of time people tend to spend in meetings. As you have more people in your orbit, the cost of collaboration and coordination goes up. Another thing that happened is when COVID hit, the quantity of meetings spiked way up because as people went remote and hybrid, they were trying to figure out how to replace a lot of the content of an in-office environment with meetings. That subdued a little bit, but it never came all the way back down. There’s an overhang from companies going remote, and even today, you do see some split between in-office companies and remote companies in terms of volume of meetings.

Nataraj: Is there any interesting trend? One of the things that happened after COVID, for me at least, is an increase in non-scheduled meetings. You just have a question and you all get on a call spontaneously, sort of replicating the hallway chat remotely. Do you have any statistics on a spike in those and how they’re doing right now?

Matt Martin: That tends to be one of the sources of the split between remote and in-office because when you’re in the office, those conversations still happen, they just don’t get recorded formally on the calendar. If you’re remote, you do have to reach out. There are informal ways to do that, like a quick Slack huddle, or you could move some of that to asynchronous conversation, which is a good pattern. But one of the phenomena is just that there’s a shift in the medium. Instead of bumping into someone in the hallway or going over to their desk, you have to find a Zoom meeting or schedule something on Google Meet. The frequency goes up. The amount of time spent in synchronous conversation, however, doesn’t actually vary as much with remote or in-office because it’s just a different type of synchronous conversation. It depends a lot on the culture. At a place like Apple, where it’s not uncommon for software engineers to have their own dedicated private offices, that sort of synchronous conversation in the office is much lower than a place that’s a wide-open office environment.

Nataraj: Clockwise started before ChatGPT and all the LLM mania started. It feels to me that there’s now this rethinking in organizations about what type of tools we are adopting. A typical thousand-person organization might have 100 to 200 SaaS products. We are seeing a shift in how many products you’re adopting, and there’s also an accelerated pace of launching new features. Do you see this happening in your perception of how sales are going for your product or other products when you’re talking to other founders or customers? Is this a change in narrative, or is it more of a narrative than it’s real?

Matt Martin: It’s interesting that you bring up Zoom in the context of AI tooling and acceleration of feature adoption because I think there’s a more significant undercurrent that’s not related to AI, which is the correction a couple of years ago from a zero-interest-rate environment to an environment where money isn’t free. That had a significant impact on SaaS buying, renewal, and adoption cycles, especially among more mature organizations. We saw a huge wave of consolidation, removal, and re-evaluation of tools that we hadn’t seen in the lifecycle of our business before. I think Zoom’s proliferation of product development is downstream of that consolidation effort, not AI. They saw that if you’re just video conferencing software, it’s easier to rip you out. Everybody pays for Microsoft 365 or Google for basic email and calendar, and both come with video conferencing. So Zoom is trying to replace that office suite. It remains to be seen if they can be successful, but I think that’s the more significant trend.

When it comes to AI tools and adoption, that has been a bit of a resurgence and a correction in that downturn in buying. There’s definitely been top-down appetite to find ways to add to the productivity and capacity of the organization with those tools. I will say, however, the trying and retention is way different. I’m quite proud of Clockwise’s retention; people use it and they like it. But as I’ve talked to IT leaders and CISOs, there’s a lot of experimentation, but there’s a lot of churn. A lot of these AI tools look interesting at the outset, but it’s hard to measure what they’re contributing to the bottom line. It’s an interesting mindset where you have this massive constriction in what people are willing to spend for software, but then a real increase in experimentation. Some of that conservatism in terms of what they’re actually buying is still there.

Nataraj: I ask because there’s also this hype around what an AI agent can do. Every new AI agent platform offers things like optimizing your calendar or increasing productivity. The problem I see is the form factor isn’t fitting the promise. When you get into things like revenue management, where a CIO wants to see the number, it’s not yet easily correlated, especially in these agentic, chat-based form factors. Could you talk a little bit about that disconnect between what AI agents are promising and why that disconnect is there?

Matt Martin: A lot of this is the basics of software selling that have been around for a while. Ultimately, the buyer needs to see the case for the return on investment. The reason there’s so much hype around AI is that people have seen the impact it can have in various facets of their job, so they’re clamoring to find other areas for that application. But to your point, if there’s revenue acceleration that the CRO isn’t actually seeing, they’re not going to buy the software, whether it’s an agent or a piece of SaaS. In many of these areas, the efficiency gains are notoriously difficult to measure. Clockwise undeniably helps people be more productive, but our ROI measurement problem has always been there. We’re productivity software. We can tell you about all the dedicated time we put back in schedules, which to some extent is a measurable hard ROI, but some buyers look at that and ask, “Okay, you made their schedule more flexible, but did they actually get more done?”

There are interesting new pricing models being experimented with. You see places like Sierra doing outcome-based pricing; for each ticket they take off a customer service person’s desk, that’s what you’re paying for. That’s much closer to hard ROI because you’re offsetting real employee time and salary in a concrete way. I think it’s difficult to find those measurables often, though. It’s difficult to find that hard translation of outcome and to have accountability all the way back. People are experimenting, and it’ll be interesting to see where it lands, but a lot of these problems echo through software sales since the 70s.

Nataraj: How are you leveraging AI in terms of creating new features and products? Can you give examples of how you’re using AI within Clockwise as a product?

Matt Martin: I’ll answer in two ways. First is operationally, how we are developing product. The second is how Clockwise as technology actually uses AI. On the first point, we have a truly AI-native product development cycle where people are utilizing tools at every stage to accelerate results. One of the clearest points of leverage for me is the collapsing of product research and prototyping. I have designers who are literally spinning up their own interactive prototypes, whether in Figma, v0, or Lovable, and putting them in front of somebody. Previously, that was quite costly. Now you can do it quickly without worrying about bugs. That accelerates development cycles. With all the tooling we have, you can spin up a lot of paths and experiment with the best one because you can get there faster. It still requires a lot of human review, or you’ll create a really hairy code base, but you can really accelerate your experimentation cycles.

On the Clockwise front, what are we actually doing with AI? There are multiple levels. One is we have a product in the field right now that allows AI-based scheduling. You can chat with Clockwise and say, “Hey, I want to schedule a time with Nikita, Aaron, and Joe next week.” We have our own fine-tuned model that we fine-tune to pay attention to time and time-based requests. It can parse the user’s intent and give it to our back-end systems to conduct the scheduling. We’re also about to launch our own MCP server that connects up our scheduling engine to frontier models or whatever MCP client you might be using. It’s been fascinating to see, especially with MCP, the combinatorial power of having different tools that can be called into from a pretty intelligent base model.

Nataraj: You mentioned becoming babysitters for half-baked tools in a LinkedIn post. What trend are you seeing? Why are a lot of these tools looking half-baked?

Matt Martin: I’m so energized by what’s happening in the industry right now because I love experimentation. When you have an explosion of new technology, it’s exciting. But with that explosion comes chaos. People are trying out new things and trying to connect them. When you look at LLMs, the ability to call into other tools is an obvious need. Anthropic developed MCP, and it’s an interesting and elegant first attempt, but it’s cumbersome. It is not for my mom. The more tools you add, the slower the LLM gets, the more complicated it gets. It’s clearly not a pattern that will extend into infinity, but it is a jumpstart on experimentation. So I think we’re in this early phase where getting a workflow completed in an AI-based way is often more cumbersome than just using a pre-existing piece of software. Some skeptics look at that and say this is all BS, just a more complicated way to do things we already know how to do. But the ability of the base model to intelligently reason and navigate these workflows is transformational. We just haven’t gotten there with the interface, with how we put those workflows together, or with the accessibility and usability for the average user.

Nataraj: My take has always been that it’s an evolution. First, we saw the base models, and then a bunch of engineers built V0 versions of everything. Now you really need product thinkers who understand the market and use cases to build the next generation of products. We are still early in terms of the apps leveraging AI. There’s an opportunity to rethink fundamental apps. Can you rewrite Outlook with AI being first? Notion rethought how a note-taking tool should be for the internet. Can you rethink even Notion with AI in place instead of added on top? There’s a lot more experimentation to come.

Matt Martin: I agree with that. We’re definitely in the phase where there’s a lot of bolt-on. There’s a lot of looking at current products and asking, now that I have this additional technology, what can I do on top of this product to augment it? The note-taking example is interesting. Notion has added on its own AI product. It’s one of the more interesting ones I’ve seen, but the frequency with which I use Notion’s AI features versus Notion as just a note-taking tool is maybe 100 to 1. In the future, note-taking probably looks more like something that is an omniscient collection of information that you can query and talk to about surfacing the right information at the right time. Most technology is additive. When we got smartphones, we didn’t get rid of laptops. There’s going to be an evolution where a completely new category and feel of software emerges from AI. Right now, outside of the frontier models like ChatGPT and Claude, I haven’t seen that many things that genuinely feel very new instead of augmentative.

Nataraj: I think we’re almost at the end of our time. What are the best ways for our audience to discover you and the work you are doing?

Matt Martin: The first place to go is clockwise.ai or getclockwise.com. You can start with Clockwise today; it takes about 30 seconds to get up and running. It’s amazing. You’ll get time back in your day, and it’s free to start. If you want to get into contact with me personally, I’m always happy to connect. LinkedIn is actually where I post the most. You can find me, Matt Martin, at Clockwise. On basically any social media, I’m /voxmatt, V-O-X-M-A-T-T. You can find me on Mastodon, which I tend to post to a little bit. I’m a little bit on Threads, a little bit on Blue Sky, a little bit on X. The fracturing social ecosystem has not done well for me in terms of one channel, but LinkedIn’s probably the most consistent.

Nataraj: This was a very fun conversation. Excited to see what Clockwise does next. Thanks for coming on the show.

Matt Martin: Thank you very much. This was a lot of fun.

Matt Martin’s insights reveal a clear vision for a future where AI doesn’t just assist but actively manages our schedules to enhance productivity and well-being. This conversation is a must-listen for anyone looking to reclaim their time and understand the practical applications of AI in the modern workplace.

→ If you enjoyed this conversation with Matt Martin, listen to the full episode here on Spotify or Apple.

→ Subscribe to our Newsletter and never miss an update.

Introduction

In the world of modern software development, managing the flow of data between services and applications is one of the biggest challenges. Matt DeBergalis, co-founder and CEO of Apollo GraphQL, has been at the forefront of solving this problem. His journey began with the Meteor framework, which revealed a critical need for a more principled way to handle data fetching. This led to the adoption of GraphQL, a query language that treats APIs not as a collection of disparate endpoints, but as a unified, connected graph.

In this discussion, Matt joins Nataraj to explore the evolution of Apollo GraphQL from an open-source project into an enterprise-grade platform. He breaks down the unique value of GraphQL for developers, the strategic decisions behind building a commercial product around it, and the complex trade-offs in today’s full-stack architecture. He also offers a compelling look at how AI is amplifying the need for robust API strategies, making technologies like GraphQL more relevant than ever.

→ Enjoy this conversation with Matt DeBergalis, on Spotify, Apple, or YouTube.
→ Subscribe to our newsletter and never miss an update.

---

Conversation Transcript

Nataraj: You’re now CEO of Apollo GraphQL. Can you give us a two-minute history of your journey until now?

Matt DeBergalis: We started the company with Meteor, which was a JavaScript development framework from the era of the first true browser-based apps. When you build software that way, you need a principled story for how you move data from the cloud into the application.

Matt DeBergalis: GraphQL and Apollo are at the heart of that story. While building Meteor, we found that the piece of the stack that brokers the flow of data from underlying databases, APIs, and all the systems that feed your software up to the app is where there’s a ton of complexity. It also accounts for a huge fraction of the handwritten code that makes building good software take so long. GraphQL is a wonderful, declarative language, so you can build infrastructure around it. We see this happening all over the stack—Kubernetes and React are examples. Apollo is that for your APIs. It’s about replacing all the single-purpose, bespoke code you might write with a piece of infrastructure and a principled programming model.

Matt DeBergalis: The name GraphQL hints at what makes it wonderful: we treat your systems, data, and services not as individual endpoints you call imperatively, but as a connected graph of objects. That completely changes the development experience. It makes it possible to express complex combinations of data in a simple, deterministic way. There’s a query planner in there, so you can do all kinds of transformations and other things necessary to build software in a repeatable, understandable way. We’ve found that this dramatically helps companies, especially larger ones with lots of APIs, accelerate how fast they can build good software.

Nataraj: GraphQL was initially open source while you were working on Meteor. At what point did you realize there was enough opportunity to make this a new company?

Matt DeBergalis: A couple of things were happening. First, the original version of Meteor was based on MongoDB, so we received many requests to support other databases, data sources, and REST APIs. The Meteor development experience was almost like black magic; you would write a MongoDB query directly in your client code. Meteor would run that same query on the Mongo server in the cloud and synchronize the results across the wire. This infrastructure efficiently kept them in sync in real time. The consequence was that Meteor apps were real-time. You’d write a query, connect it to a component on your screen, and as the database changed, the screen would automatically update. That was amazing, especially in those days, but it had to be in Mongo. So we needed a more general query language.

Matt DeBergalis: Just as we needed that, Facebook announced GraphQL. This brings me to the other part of the answer, and why I think GraphQL has flourished where similar ideas haven’t. In my view, GraphQL is the first API technology that really asks about the needs of the clients—the consumers of data—instead of the providers. REST APIs, or older technologies like ONC RPC or SOAP, are all defined by the server. The consumer gets what they get—the payload, the format, the protocol. This puts a huge burden on the application developer because it’s rare that what comes back from the API is exactly what you need. You might need to filter it, transform it, or join it with another API.

Matt DeBergalis: GraphQL has an incredibly good developer experience for the consumer. You write a strongly-typed query, which means great tooling support in your editor. Now there’s great tooling support in agentic editors because it’s semantic and self-documenting. A lot of what makes a technology win is the feeling a developer gets when they try it—how easy it is to use and how quickly you can get to something good. GraphQL had that delightful characteristic. It came from the same team at Facebook that created React, so it had a lot of energy as web development moved into the modern era. Those two things made it an easy choice for us.

Nataraj: It’s interesting that so many developer technologies came out of Meta that they didn’t monetize. Unlike Amazon or Microsoft, they seem to define themselves strictly as a social media company. Why hasn’t Meta become a fourth cloud provider? They have the technology, developer experience, and money to do it.

Matt DeBergalis: Here’s one quick point on that. A lot of the energy around React, for example, really came out of recruiting. Many companies do this. Open source was a tool for driving an engineering brand, especially in an era when it became very difficult to hire. There was a war for application development talent. So, one reason to open source something like React, even without a direct business case—it’s hard to monetize React, Vercel is probably the best example and it’s a tenuous connection—is that if it helps you recruit, you can justify a lot.

Nataraj: That’s a very important point. It likely explains Microsoft’s strategy shift to becoming one of the biggest open-source contributors. So, we have these open-source products that find developer love, and then a company forms around them, like Databricks with Apache Spark. What was the journey like for GraphQL, taking a great open-source product and turning it into a business with a product worth paying for?

Matt DeBergalis: One surprising thing is that open source on its own often doesn’t get a ton of adoption, especially when it’s designed for a larger company’s needs. Take Databricks and Spark. One way to look at it is that they built the company because people weren’t adopting Spark. Why not? Because it was hard. It’s a complicated piece of machinery. The company that needs that problem solved needs more than just Spark. The best vehicle for solving those kinds of problems is a business because it allows you to create a whole product, a solution. The enterprise sales process is really about helping the customer navigate the decision. The monetary cost is one thing, but the much bigger cost is the complex, multi-stakeholder architectural decision.

Matt DeBergalis: With GraphQL, we asked a simple question: How do you get something like this adopted? I can give you a compelling technical reason why having a graph and writing a query is better than writing a bunch of procedural code for every new application experience. But in practice, how does that get adopted? If you pull that thread, interesting things emerge. Who owns APIs in an enterprise? Who makes architectural decisions? How do you balance the executive who owns the roadmap with engineering needs? The VP of engineering job is maybe the hardest job today. You’re under enormous pressure to ship quickly. If you ship slower than your competitor, it could be the end of your company’s viability.

Matt DeBergalis: At the same time, you can’t mortgage the future. If you race to ship a product but create a big security vulnerability, you’ll get fired. If you build a product and then discover Amazon shipped Alexa and you need a voice app, or OpenAI shipped GPT and you need an agent, you’re in trouble if you’ve painted yourself into an architectural corner. You’re caught between a rock and a hard place. The consequence is you’re going to want help—more than just a raw piece of technology. You’ll want a plan, end-to-end integration, and all the ‘ilities’: observability, security, auditability. That, for infrastructure at least, is the heart of how you go from an exciting open-source project to something that makes business sense and can be adopted at scale.

Nataraj: When a business adopts an open-source technology, they’re not just adopting a product; they’re adopting a certain level of risk. That’s why you have legal agreements about things like data privacy issues.

Matt DeBergalis: That’s right. And the biggest risk by far is picking the wrong technology. Think about the cost of getting that wrong. If you adopt a database and five years later it has no users, the open-source project is on life support, and there’s no vendor to help you, you’re in real trouble. You’re facing a migration.

Nataraj: The problem with Meta open-sourcing Llama is that if I’m building on top of a model, I need someone to host it and guarantee 99.99% reliability. There are all these dynamics between open and closed source.

Matt DeBergalis: You see this across the stack. Maybe 10 or 20 years ago, a developer would start by asking what’s open versus closed to avoid vendor lock-in, especially after experiences with companies like Oracle. Now, it’s a little different. There’s so much to buy across the stack that you don’t have time for a deep analysis of everything. The biggest risk is getting it wrong. With AI moving so fast, you see a preference for what’s prevalent. You’re probably going to be in good shape if you go with the market leader. That means you can hire people who know the technology, and there’s a good chance it will mature quickly enough to meet your future needs. It’s a virtuous cycle. That’s the pitch I make for GraphQL: you have an API strategy to decide on, and you should start from the premise that picking the one developers like, with a vibrant user community, is a safe choice.

Nataraj: I have a view on the evolution of full-stack development and wanted your thoughts. Are we making it more or less complicated? I feel like we’re making things more complicated to stand up a scalable web application.

Matt DeBergalis: I grew up writing software on a Commodore 64. It’s definitely gotten more complicated, and it’s all across the stack. Microservices make sense for scaling engineering efforts, but they drive the need for things to manage those processes, like Kubernetes. You need a way to orchestrate API calls across them, which is our GraphQL story. Does Apollo add complexity? There’s an argument that it does. On the other hand, each of these layers, when done right, adds value and lets you go faster. A good architecture should have the property where the more you build, the more valuable the whole thing becomes. Some technologies feel like the opposite; you keep putting energy in, but it slows you down.

Nataraj: It feels like there’s a lot of distance before you see that geometric growth. The early investment is high, and you’re always thinking two or three years down the line. You can’t start something fast because you’re planning for the future, like choosing the right database.

Matt DeBergalis: It’s gnarly because many technology decisions boil down to: do I want a quick result today, creating debt for tomorrow, or do I want to set myself up for a bright future? It’s a hard call. Our job is to try to square that circle. Kubernetes was really complicated for a long time, but it has gotten easier to use. Now, we see all the benefits. That’s been a big priority for us at Apollo. The knock on GraphQL is there’s a lot of upfront setup work to build a schema—the catalog of all your APIs. Once you’ve done that, it’s wonderful, but getting there is a pain. Much of our roadmap over the last year has been about making it really easy and fast to get to that point of value. In 2025, most people will choose to solve today’s problem and worry about tomorrow later.

Nataraj: For a small company with just one or two APIs, at what point does adopting GraphQL make sense? What type of customers do you have today?

Matt DeBergalis: It makes sense from the client’s point of view. When you’re using GraphQL and React, you just write a query in your component, and that’s it. From the API side, with one or two REST APIs, it’s not a big deal. You can easily change them. But for a company with 10,000 REST APIs, it becomes very difficult to change them because you have no way of knowing what fields are being used. The thing that’s really interesting now is agents. Everybody wants to have some kind of agentic experience on top of their APIs, and GraphQL is a fantastic fit. GraphQL is an orchestration language. It’s about transforming, changing protocols, filtering. We’re excited about agents because they put those needs front and center.

Nataraj: Can you talk about the size and scale of Apollo today as a business?

Matt DeBergalis: GraphQL is used in about half of the enterprise world. We see this because we provide most of the standard open-source libraries. Commercially, we’ve focused on larger companies because graphs have a network effect; they are most valuable when they’re large. For example, we have a lot of retailers. Think about an online store. On a product page, you want to show the customer, ‘Arrives on Friday.’ To do that, you need to make a ton of API calls under the hood—inventory APIs, shipping partner APIs, loyalty APIs. It’s the kind of thing that seems trivial from a user experience perspective but explains why it often takes months to ship. Larger, established companies in retail or media, like The New York Times, find GraphQL incredibly valuable. Also, companies that have grown through M&A and have heterogeneous systems need to bring products together into a single user experience. That’s where GraphQL is historically adopted most. But again, agents are changing that, creating excitement around GraphQL at companies of all sizes.

Nataraj: How do you acquire customers and market to new developers to ensure you remain the go-to product?

Matt DeBergalis: For most open-source companies, including us, open source is an important part of the funnel. Development teams make the technical decisions. It starts with a developer who reaches for something they’ve heard of that makes sense and that they can try quickly. Open source is a great vehicle for that. It starts with a React developer reaching for Apollo Client or an MCP developer wanting to define an agent declaratively. You can build from there, but that open-source entry point and the content around it are by far the most important things.

Nataraj: You recently transitioned from CTO to CEO. How has your focus changed?

Matt DeBergalis: It changes a lot and changes nothing, depending on how you look at it. I’ve always felt our customers are where everything comes from. The first version of Apollo Client was really bad, but it had one killer feature: we took pull requests. People would adopt it, and that turned into wonderful partnerships, like with The New York Times. It was a formative technical partnership that became a customer partnership. For me, the heart of it has always been partnership. I don’t see that differently from the CEO seat. Startups that do well all say users and customers come first. I always spent a lot of time with our sales team and on marketing. That hasn’t changed. And I still do product demos every Friday. I don’t ever want to lose touch with that. If we don’t have a great product that developers love, the rest doesn’t matter.

Nataraj: What does the sales motion for Apollo look like? Who are you typically talking to?

Matt DeBergalis: It varies. You can look at Apollo from two different perspectives. One is the team trying to ship a piece of software. For them, Apollo helps them ship faster and with less risk. That’s who you want to sell to because that’s where the value is. They own roadmaps. The other lens is seeing Apollo as a platform. You have platform engineering teams that own developer productivity or operational excellence outcomes. Ideally, we initially bring Apollo to a team with a specific use case. If you’re selling to someone for whom the value isn’t immediate, it’s much harder. You start there, but you think about eventual expansion. When you think about expansion, a technology like this will naturally find a place in a platform organization’s portfolio, so you want to meet those people early on.

Nataraj: Let’s talk about AI. What are your thoughts on the current hype cycle, and what is the opportunity for Apollo in AI?

Matt DeBergalis: I’ve never seen anything like it. It’s so disruptive. The immediate thing for us is that AI will drive a lot more API consumption. Every company is scrambling to build some kind of agentic user experience. The line between an agent and an app will get blurry. For example, a bank has one mobile app for a wide range of customers, from retirees to college students. With agents, maybe that one app can serve both by learning what I’m into and adapting the user interface. That’s a really different kind of app, and every one of those efforts will drive a whole bunch of net new API calls. That’s good for Apollo and GraphQL.

Matt DeBergalis: Also, the nature of those API calls is different. You can’t trust a non-deterministic model, so the API layer needs more access control and policy enforcement. GraphQL is a nice fit here because it’s semantic. Token management becomes really important. The best way to keep a model on track is to not feed it tokens it doesn’t need, which also saves money. That sounds like GraphQL—only the fields I want. So, we’re seeing a lot of demand for GraphQL because of agents. The way we build software is also changing. Every part of our company is changing. If we’re going to be an essential part of the AI-first stack, we have to be an AI-first company.

Nataraj: Has AI changed the business metrics for your company? Has it helped save costs or optimized capital expenses?

Matt DeBergalis: AI definitely accelerates some things. Sometimes you use that to get more done, and sometimes to do it more cost-effectively. We’ve seen both. It’s also not magic; we’re still figuring out what it can and can’t do. Personally, AI helps me do a lot of things faster and better. I use it a lot for research, and I feel more informed than I was a year ago. I don’t have a research team at my disposal. I don’t think of it as changing how we hire as much as having more relevant information at my fingertips, which helps us make better, faster decisions.

Nataraj: It almost feels like AI is overestimated in the short term and underestimated in the long term.

Matt DeBergalis: So much is like that. I think that has to be true.

---

Conclusion

Matt DeBergalis provides a masterclass in identifying a core developer need and building a powerful platform to solve it. His insights into GraphQL’s client-first approach and its growing importance in an AI-driven world offer a clear vision for the future of API architecture.

→ If you enjoyed this conversation with Matt DeBergalis, listen to the full episode here on Spotify, Apple, or YouTube.
→ Subscribe to our Newsletter and never miss an update.

How are large enterprises navigating the seismic shift to artificial intelligence? For many, the journey begins with managing the 90% of their data that is unstructured—documents, images, videos, and contracts. In this conversation, Nataraj sits down with Ben Kus, Chief Technology Officer at Box, to explore the real-world challenges and opportunities of becoming an AI-first company. Ben shares critical insights from Box’s own transformation, detailing how they leverage generative AI to unlock value from an exabyte of customer data. They discuss the evolution from specialized machine learning models to powerful general-purpose AI, the practicalities of managing AI costs, and the essential steps to ensure data security and customer trust. This discussion moves beyond the hype to provide a clear-eyed view of enterprise AI adoption, from initial use cases like RAG and data extraction to the future of complex, agentic systems that can perform deep research and automate sophisticated workflows.

→ Enjoy this conversation with Ben Kus, on Spotify, Apple, or YouTube.

→ Subscribe to ournewsletter and never miss an update.

Nataraj: I was really excited because I work in unstructured data as well and I realize how important it is. But let’s set a little bit of context for the audience. In the storage industry, it’s a common phrase to use unstructured data. But it would be good to set the context of what is unstructured data and why Box is in the center of all things AI.

Ben Kus: It’s interesting. Oftentimes, if you say the word data to anyone, especially computer scientists or people who have come from programming backgrounds, you naturally think of structured data. We want to become more data-oriented; we need to use data. And it’s partially because there’s been a massive data revolution over the last 10 or 20 years. It used to be that my data was in a MySQL database somewhere. Then it became more tools available where you would use terms like data lake and data warehouse, more advanced analytics tools. You see companies like Databricks and Snowflake that become these very powerful platforms of structured data. That’s just naturally what you think of.

Now, the world of unstructured data, which I would define as data that’s not in a database and doesn’t have a schema to it—things like emails, messages, and webpages. In our world at Box, it’s the world of what we call content or files, the stuff that goes into documents, PowerPoints, markdown files, videos, or images. All of this is unstructured data. Interestingly, almost every company you talk to, in a business-to-business, enterprise-oriented thought process, 90% or more of their data is actually unstructured. At Box, we have 120,000 enterprise customers, we have over an exabyte of data, and this is what we’ve always lived by. You need to collaborate on it, you need to sync it to get it to different places.

But then generative AI comes around, and generative AI is born on unstructured data. So it naturally, immediately, every company I’ve ever talked to, if you ask why they’re interested in generative AI, one of their top three things they’ll say will be, ‘Well, I’ve got all this internal stuff in my company that is unstructured data, and I don’t think I’m taking advantage of it enough.’ It takes a million different forms, and it’s partly why it’s been hard to really automate or make specialized applications to deal with these types of data. But there’s this huge untapped potential in unstructured data. So for Box, with all of these new models coming out from all these great providers, it’s a gift to companies and to people who think the way that we do, which is how can you get more out of your unstructured data? Now AI can basically understand unstructured data. For the first time, you have this automated ability to have computers be able to understand, watch, read, and look at these things and then be able to not only generate new content for you but also to understand and help you with the content that you already have, which in many companies is massive—petabytes, hundreds of billions of these pieces of content that in some cases are the most critical stuff they have.

Nataraj: Unstructured data includes Box, Amazon S3 files, Azure has Blob, and any given enterprise has multiple places where they’re storing data. In terms of your strategy for building products, how much are you thinking about extending the Box ecosystem into all these surface areas versus building tools or products within the ecosystem? Talk a little bit about your strategic approach.

Ben Kus: If you go back to the analogy of where people store their structured data, it’s in many places for many different reasons. Similarly, there’s the very generically large term of unstructured data; you would store it and use it in many different ways. But for Box, one of our things we’re typically known for is to make it very easy to use, extend, secure, and be compliant for all of your data. For that, we typically would need to manage it. We have a million ways to sync data between repositories. We recently announced a big partnership with Snowflake where the structured data, the metadata about a file in Box, automatically syncs into Snowflake tables. That kind of thing is definitely part of what we think about.

But in general for Box, it’s key that we offer so much AI, in many cases for free on top of the data you have, even though it’s quite expensive, because we want people to bring their data and get all the benefits of security, collaboration, and AI. But we don’t believe we’re going to be the only people in this AI and agentic ecosystem, which is why we partner with basically everyone. We believe there will be these major enterprise platforms that every company will be looking at. Our job is to give the best option for them for unstructured data and then integrate with everybody else so that you can have our AI agents working with other companies in addition to custom AI agents that you build yourself. Because we’re unstructured data and a lot of people need to use it, we integrate with other platforms, non-AI in addition to AI integrations that let other companies call into our AI capabilities to ask about data, do deep research, do data extraction, and so on.

Nataraj: Was there a moment within the company where you guys realized that this is a big shift? Box has been around for almost 20 years, starting in 2005. Was there an internal moment where you said, ‘Okay, this is really big for us?’

Ben Kus: Sure. If you look back five or six years for the term ML and unstructured data, you’ll find we had a lot of big announcements around how Box uses ML to structure your data. So taking unstructured data and structuring it is a big thing we’ve done for many years. We’ve always been trying to be on the bleeding edge of what’s available. But there was this challenge. Imagine a company with forms people are filling out, or documents, contracts, leases, research proposals, images—anything a company does day-to-day. If you were to have AI or ML help you, it would be training a model. You’d get a data science team together or buy a company. We would see that getting an ML model to handle contracts and structure them was too complicated. You’d need a model not just for contracts or leases, but for commercial leases in the UK in the last three years. You’d have a model for that, and it didn’t really work that well. You’d have to train and customize it a lot.

That was the nature of how it used to be. When Generative AI came out, we were watching the early days of GPT-2 style models, and it was okay. But somewhere around the time ChatGPT came out, with GPT-3.5 style models, you suddenly saw this amazing moment where a general-purpose model could actually start to outperform the specialized models. It could do things you never even would have bothered to try, like, ‘What is the risk assessment of this contract?’ or ‘Can you describe whether you think this image is production-ready for a catalog?’ You couldn’t even imagine the feature set you would give a traditional ML model. But Generative AI could kind of do it. As it got better, GPT-4 was this big, ‘Oh wow,’ moment where some of the challenges of the older models were being fixed. GPT-3.5 was the moment where we said, ‘Let’s just go back and retrofit everything about Box to be able to apply AI models on top of it,’ so you could do things like chatting through documents and extracting data. It was amazing how fast you could get things working and get them working better than you ever had before, even after spending a ton of engineering resources on trying to get something working. An hour and a half of using one of the new models actually gave you better performance. That was a big aha moment. And then of course you realize you’ve got 90% of the problem, and the last 10% is going to take all your time going forward. But since then, all of our efforts have been around preparing Box to be an AI-first platform. We often talk internally, ‘What if we were building Box tomorrow?’ It clearly would be an AI-first experience. So why don’t we do that? That’s just part of our mentality.

Nataraj: What are some of the earliest use cases that you launched at Box, and how has the enterprise customer adoption been? In enterprises, we often see the cycle of adoption is a little bit slower.

Ben Kus: Some of the first features we launched were around the idea that if you’re looking at a document, you need to have an AI next to you to help you chat with it. I’ve got a long document, a long contract, this proposal—help me understand it. It’s almost like an advanced find. That was a simple feature, but it was this new paradigm. And then we added the concept of RAG, not just for a single document but across documents. You can implement chunking, vector databases, and the ability to find the answer to your question, not just a document like in a search. I’ve got 100,000 documents here in my portal of product documentation. As a salesperson, I need to find the answer to this question. I ask it, and the AI will ‘read’ through all of it using RAG and provide the answer.

For enterprises, they were scared, and some of them still are, about AI because it’s so different. Data security is critical. No matter the benefit of AI, if you’re going to leak data, no one’s going to use it. In many cases, for bigger organizations, the first AI they’re actually using on their production data is Box, partially because it’s very hard for them to trust AI companies. You need to trust the model, the person calling the model, and the person who has your data. Since Box is that whole stack for them, they were able to say, ‘I trust that your AI principles and approach will be secure.’ Then they’re able to start with some of the simple capabilities. One of the more exciting ones is data extraction, where you have contracts, project proposals, press releases. There’s an implicit structure to them. You want to see the fields, like who signed it, what time, what are the clauses. Then you can search and filter on that data. Enterprises look at that and say these are very practical benefits. They get through their AI governance committees, security screenings, and ensure nobody trains on their data. That’s the scariest thing to them. We have to go in and meet with the teams, explain every step, show them the architecture diagrams, and the audit reviews so they know their data is safe. That’s typically their number one concern.

Nataraj: I want to talk a little bit about the cost of leveraging AI. It has dramatically gone down. Are you seeing improvement in your margins by creating AI products? How is it directly impacting your profitability?

Ben Kus: This is a particularly hard problem. We’re a public company. We publish our gross margin, our expenses. It’s not practical for us to do something that would double our expenses. Nobody has $100 million laying around to apply to whatever cool ideas. At the same time, it’s very clear that if you’re too worried or stingy about your AI bills, you will lose to somebody who is just trying harder. There’s been a really nice byproduct of all the innovation in chips, models, and efficiency—they’re much cheaper than they used to be. Sam Altman said a few years ago that models would get dramatically cheaper, but you’re also going to find you’ll use them more and more, which will slightly offset that. That’s exactly what we found. We are doing way more tokens than we did previously, by orders of magnitude. However, we’re now utilizing the cheaper models, and they’re just offsetting.

When you get to agentic capabilities, like deep research on your data, that’s way different than RAG. RAG might use 20,000 tokens. But for deep research, you might go through many documents, 10,000 tokens at a time, maybe 50,000, 100,000, and then reprocess that. You might spend hundreds of thousands of tokens or more. That’s a massive exponential growth in your AI spend. But you get a great result. Deep research on your own data is revolutionary. The way we approach it is to give AI for free as much as possible because that’s what an AI-first platform would do. Sometimes, for very high-scale use on our platform, you can pay. But whenever possible, we’re going to eat the costs ourselves and handle that risk because that’s what you want out of your best products. Nobody wants to sit there and worry when they’re clicking on things that it’s going to cost them. So we try to protect ourselves with some resource-based pricing but also just say AI is part of the product. That’s our philosophy.

Nataraj: What do you think about pricing based on usage versus pricing based on outcomes? I’m assuming you’re following the regular per-seat, per-subscription model.

Ben Kus: Yep. We’ve been through every single possible flavor of this. I hope business schools are doing case studies on how everybody had to rethink technology pricing. At the end of the day, pricing a product isn’t just about the supply side cost; it’s about what people are willing to pay and how they’re willing to pay for it. When we originally launched our AI, we had seen some people who launched AI were charging too much and people weren’t ready for that. Then there was this massive trend of $20 a month for enterprise-style tools, and the adoption was terrible because nobody quite knew what to do with it. So we decided to offer it as free as part of our product, but we put a limit on it. If you did too much, it would stop.

But then enterprises would actually not turn it on because they were worried they would hit those limits and then everybody would be mad at them. The limit became an adoption barrier. So we got a lot of feedback from our customers and turned that off. There was no limit. Now, there’s the idea of abuse we could address. You can’t just buy a seat to Box and use the API to power another system. But for normal usage, we handle that risk. It’s incredibly expensive if you look at public cloud rates for transferring and storing data. We’re used to infrastructure expenses. So we decided we’re going to eat the cost of it as a way to deliver better services to our customers. That is our continuous philosophy.

Nataraj: Storage is a horizontal use case, but AI is also being used to build vertical-specific products, like Cursor for developers or Harvey for legal assistants. Have you evaluated creating specific products on top of Box for different verticals?

Ben Kus: This is a very fundamental question for any company: am I going to focus on a specific vertical and a problem, or am I going to focus generically across the board? At Box, one of our product principles is to focus on the horizontal IT use cases. Much of our value proposition is across the whole environment. Everybody in the company wants the security features, the compliance features, the sharing features. This is why we talk about it as content or files—everybody needs files. Some companies specialize and talk about contracts and clauses, or digital assets and marketing materials. This is a big question for any startup: go deep or go broad. If you go deep, you can make more targeted products. But your total market size is diminished. For us at Box, no one industry makes up more than 10% of our overall business. We have a giant market, but the more you specialize, the more you’re probably not going to solve a problem for somebody else.

The interesting part about AI is that it pulls you in two different directions at once. Some people will start to use AI to very specifically solve problems, like in life sciences or financial services. But at the same time, in some cases, a generic AI can actually solve what a historical specialized company used to do. In which case, people might go back to a generic solution so they don’t have a million point solutions. You always have to analyze how deep to go in an industry versus how much you can provide horizontally. AI reshuffles it.

Nataraj: You guys are one of the first companies to adopt being an AI-first company. What does that mean and how does it change how you operate?

Ben Kus: When we use the word ‘AI-first,’ we think about building a feature knowing the full abilities of AI. Search is an interesting example. The historic way you would build search is completely different from how you would build it in a world with an AI or agentic experience. Not just from a technology perspective with better vector embeddings, but also from the technique. People act differently when they go to a search box than when they are talking to an agent. Many people use ChatGPT or Gemini for internet searches, and what you type into Google versus your chat experience is different.

That’s an interesting moment for Box. If you think AI-first, you don’t just put an AI thing inside a search box. You rethink the search experience from the beginning. We announced our agentic search, or deep search, where you ask an AI, and it will not just go through a complicated search system, but it will look at the results and figure out whether those results match what you’re looking for. It goes well beyond RAG and into using intelligent agents to loop and figure out if they have the best answer or if they need to try again. Thinking that way, not just ‘I have a model, I want to use it,’ but ‘What can AI do for you?’, especially if you think agentically, becomes a different product process, a different engineering process, a different strategy process. You start to invest heavily in your AI platform layers and common AI interactions in your products, like an agentic experience or AX. If you’re going to be an AI-first company, you need to examine the fact that maybe AI will change the way you’ve done something traditional.

Nataraj: We went through RAGs, we went through copilots, and now we are seeing agents. How are you thinking about agents within Box? What is your definition of an agent?

Ben Kus: My definition of an AI agent, technically speaking—and Harrison from LangChain has a fun definition—is that an agent is something that decides when it’s done. Normally, you run code and it completes. But an AI agent needs to figure out when it’s done. That’s a good technical definition. I have a slightly more detailed engineering answer: an agent has an objective, instructions, an AI model (a brain), and tools it can decide to utilize with context to operate. I’m a fan of agents that can call on other agents, like a multi-agent system.

When I’m thinking about agents, I’m thinking about multiple agents cooperating. To me, the power of agents going forward is this idea that you can think about them as little state diagrams of intelligence that can loop and do more sophisticated things. This is a very different thought process for most engineers. You asked for an example. One is deep research. To do deep research in Box, you have to search, look at the results, get the files, make an outline, create the prose, and then critique it. That’s like 15 steps for these agents. We call that a deep research agent, but it has a multi-agent workflow to process that. I don’t know if you could have done deep research very well previously because there are too many paths to handle. It’s the kind of thing that works really well for an intelligent system like an agent to orchestrate.

Nataraj: Do you see any form factor for agents? In an enterprise product sense, how does that form factor play out?

Ben Kus: There’s the AI models concept, which is more of a developer concept. Then there’s the idea of an AI assistant, where you have something there to help you in context, but it’s typically one-shot. The term ‘agentic experience’ (AX) is very interesting in this form factor discussion. OpenAI, Anthropic, and Gemini do a great job of building valuable capabilities into their agentic experiences. You go to ChatGPT or your favorite tool, ask a question, and it just figures out, ‘I’m going to search the internet, I’m going to do deep research for you.’ This idea that you go in and ask a system to do something, and it can recognize your context, is critical. Context engineering is a critical aspect of agentic stuff going forward. This might be the new form factor.

At Box, when you’re on our main screen, what you want to do is very different than if you have a file open or if you’re looking at all your contracts or invoices. The hard engineering and product problem is to make agents that figure out what you might want at that point. We think about building an agent that handles a certain flow but first figures out what the user wants, and then does a search or queries the system or brings data together. That context engineering is critical. I believe context engineering is one of the more interesting areas developing, and it will be something that everybody will want to hire for soon.

Nataraj: Let’s touch upon productivity. How much productivity improvement are you seeing within your company? And there’s a group of people panicking that AI is going to destroy jobs, starting with developers.

Ben Kus: For productivity for our customers, we see people start to use AI a little bit skittishly, and then they use it more and more over time. Especially in enterprises, adoption starts slow, but then they start to add it in big chunks, and you see an acceleration of usage over time.

Internally, we have seen benefits from using assisted tools for our developers, like GitHub Copilot and Cursor. As the models and integrations have gotten better, they are helping us overall. We don’t think of it as, ‘We can save money and have fewer developers.’ Instead, we’re like, ‘If 25% of our code is written by AI, that’s 25% more we can do to deliver value to customers.’ We’re not constrained by a fixed amount of output we want from our developers; we want more. If tools help people become more productive, that’s wonderful.

Economically speaking, I’m not a believer in the lump of labor fallacy—that there’s only a fixed amount of things people want to do. I think it’s the opposite. If things get better and cheaper, you want more of it. We want more videos, content, marketing, and internal content because new avenues are now possible. Now, there’s an important aspect: if change happens too quickly, it can be very disruptive. I’m very sensitive to the plight of people in the middle of a disruption. But I see this as a tool to help companies do more. You need good people using AI to help them, as opposed to cutting whole areas.

Nataraj: Some CTOs have the opinion that they no longer need a lot of junior developers. I always thought this is actually much better for junior developers because if it was taking them three or four years to become senior, it will now take them one year. What’s your take?

Ben Kus: What you said is true. When you add a junior developer, you often expect a relatively small level of output compared to more senior people. But now, a person who’s really good at using the latest tools is actually quite productive, and that’s a big value. At Box, we have the most developers we’ve ever had, and we’re not only hiring senior people; we’re hiring across the whole spectrum. We just expect people to be able to use tools. Anecdotally, I see that people coming out of school now have always known AI-assisted coding, and they’re good at it compared to somebody who’s been around for a long time and might be resisting it. Also, in areas like context engineering, which is a slightly different form of coding, some of our most successful context engineers are relatively junior in terms of how long they’ve been out of school but really excel at that kind of thing.

Nataraj: An audience member asks: can you share a little bit about document parsing and how you’re extracting from those documents and what models or technologies you’re using behind the scenes?

Ben Kus: In this world of handling unstructured data, there’s a set of things you always need to do. You have all these different file types. The first thing is to get it to a usable format. Markdown is a great format. Sometimes you have scanned documents or different formats. There’s a big conversion as a first step. Many people talk about PDFs because of all the weird things that go into them. A PDF is not a good format for AI to figure out; it needs to be converted. So step one is to convert it to text with some limited style support like markdown. Then you typically go through and chunk it. You want to make a vector out of the most important section of data. You want it to contain a whole thought. You wouldn’t do it per sentence, but if you did it for giant pages, you’d end up with too many confused topics. So you want a vector to indicate what that area is about. Paragraphs work well at a high level, but then you need more advanced chunking strategies. Then you stick that into a vector database or put the text into your traditional search database.

Nataraj: Are you building your own proprietary tools for this, or are you using things like LangChain with Pinecone or other vector DBs?

Ben Kus: My philosophy and the philosophy of Box is that we love all the tools that everybody makes. If people are building the best tool out there—the best vector database, the best document chunker, the best agentic framework—we want to use it. I gave a speech recently at the LangChain conference about the benefits of something like LangGraph. When we started, we had built our own because this stuff wasn’t available at the time. But we are more than happy to go back and retrofit to some of the other systems. I’m very impressed at how good vector databases have gotten in the last few years. Why would we bother to rebuild the things that people are doing such a great job building, especially in the open-source community, or tools that we can buy? We’re big fans; we will replace stuff that we just built because something better is available. With AI, you kind of have to reevaluate every six months.

Nataraj: What about the models you’re using? In an enterprise, you want to adopt the latest and greatest, but you also want to be secure.

Ben Kus: We made a decision a long time ago not to build models, and I’m super happy we did that. Also, we are going to support all of the best models that are trustworthy. For us right now, we support OpenAI-based models, Anthropic’s Claude models, Llama-based models, and Gemini. We consider those to be some of the best models out there. Not only do we support them, but we support them on a trusted environment. This is critical for many enterprises. For example, AWS Bedrock is a very trustworthy environment to run the Claude or Llama models. IBM will support Llama models for you. These are trustworthy names from an enterprise perspective.

We utilize these trusted providers and trusted models, and then we pick which model works best for a given task. Gemini is great for data extraction. GPT-style models are great for chatting. They’re all pretty close these days, the leading models. But we let our customers switch as they want. If somebody says, ‘I really think this data extraction is best for Claude,’ we let them do it. We support all of the models, and one of our goals is to support them as they come out. This is very expensive and painful internally because how you properly prompt and context-engineer for Claude is different from Gemini, which is different from OpenAI models. But for enterprises, they often have preferences, and our job as an open platform is to handle those.

Nataraj: One final question. If you were building something now, are there any ideas that you would go and attack?

Ben Kus: It’s a very good question. There are a lot of startups out there doing really interesting things. One interesting idea is to look at areas where an old-school traditional software approach could be disrupted, but maybe it’s so old that people don’t really think it’s cool or interesting anymore. Finding something that is very valuable but not as in the news might be a good approach. Anything we’re talking about all the time will probably have so much competition that you might be behind.

But I will highlight one thing. If you see something like Cursor—nobody talked about Cursor a couple of years ago. They were up against Microsoft Copilot, one of the biggest companies in the world. An interesting thing is that with Cursor, you start to realize that even though people are using AI to solve a problem, there might be a better way. If you can make a really good product, even despite the VC advice that you’ll never make it in a ‘kill zone,’ you might have a chance. Often, that’s very good advice, but if you really believe you can do it better, it’s a dangerous path, but there are demonstrations of people who built a really good product. I believe those still have a chance in these crazy AI times to become large companies because they just solved the problem really well.

Nataraj: Because Cursor literally cloned VS Code. They thought the UI could be better on just that product and that’s the main differentiation.

Ben Kus: There are a lot of dynamics that go into any existing product. Sometimes a fresh look at it, even a problem that seems solved, can be helpful.

Nataraj: This was a great conversation, Ben. Thanks for coming on the show.

Ben Kus: Excellent. Well, thanks for having me on. It was a fun chat.

This conversation with Ben Kus highlights the practical, strategic thinking required for enterprises to successfully adopt AI. By focusing on security, embracing a multi-model approach, and rethinking core product experiences, companies can unlock the immense potential of their unstructured data.

→ If you enjoyed this conversation with Ben Kus, listen to the full episode here on Spotify, Apple, or YouTube.

→ Subscribe to ourNewsletter and never miss an update.