Saahil Jain on Ship Happens: Building Search for AI Agents

Summary

Saahil Jain, CTO of You.com, joins Pier on Docker's Ship Happens podcast to talk about moving from AI adoption to AI operation. He explains how You.com went from a consumer search engine to AI search infrastructure for agents, why agents don't just point at Google, and what companies need as they put agents into production.

They cover the differences between AI-native and traditional companies, why cost and predictability matter more once AI is in production, and why evals need to go beyond a single benchmark number. Jain also shares how he thinks about building products as models improve, and where he expects durable advantages to come from.

Key highlights

• Search built for agents. You.com started as a consumer search engine in 2020 and now focuses on AI search infrastructure for agents, powering over 1 billion queries a month for enterprises.
• Why not just use Google? Jain says Google's index is its core asset and is bundled with Gemini, SERP APIs that crawl Google raise reliability and zero-data-retention concerns, and agents can read far more results than a human would.
• Knobs for agents. You.com's research APIs let an agent choose a research effort level to trade off cost, accuracy, and latency, and he expects more such controls as agents improve.
• AI-native vs. traditional companies. AI-native teams adopt models and subprocessors quickly, while banks and other regulated companies can take months or longer to build trust, though many are now building their own agents.
• Operationalizing AI. He says the conversation has shifted from "token maxing" to efficiency, with cost and accuracy on real-world query distributions becoming the priorities.
• Better evals. He describes research on agent consistency that received a best paper award at AAAI, separating variance caused by task difficulty from variance caused by agent inconsistency.
• Gates and drift. Teams need offline evals and A/B tests before launch, and ongoing measurement against new query distributions afterward.
• Build for better models. Jain advises putting minimal effort into scaffolding that stronger models will make unnecessary, and accepting some tech debt there while building foundations that last.
• Where moats come from. He points to private data, sticky partnerships, and customer love, and expects more small companies that look like service businesses.

Watch the interview

https://www.youtube.com/watch?v=4l1N7-K5xcc

Transcript

Lightly edited for readability: timestamps follow the source transcript, speaker labels are not included, and obvious transcription errors and name spellings are corrected. Section headings come from the video's chapters.

[0:00] We predict that in the coming year or two, the amount of agentic searches will continue to exponentially increase. I think there's already a statistic from Cloudflare that shows that more agents request HTML pages than humans, and we expect this to only further increase over time. Google is the search engine for humans. Why is it not the case that Google is the search engine for agents? AI natives, and companies that in some ways have less to lose, can move a lot faster than companies that have a lot of obligations, like banks, where they need to abide by regulation. They're more conservative.

Meet You.com's CTO

[0:43] Welcome to another episode of Ship Happens. My name is Pier, and in this podcast I get to sit down with really smart people and talk about what's interesting and exciting in the world of AI, but also what's challenging and what's really happening in the space of customers and companies and so on. So today I have the absolute pleasure to have Saahil Jain joining me. He is the CTO of You.com. We are going to talk about really going from AI adoption to operation, and we're also going to talk about what You.com does in a second, and I'll let Saahil do the talking about that so we get the full understanding of what you're doing. First of all, Saahil, welcome to the show. It's lovely to have you here. And I think for people in the industry, You.com has been known as this AI search engine. That's what most people's perception of You.com is. What are they missing? What else do you do? It's not the whole story.

[1:29] Yeah, first of all, thank you for having me on. Very excited to chat about various topics related to AI and search. And in terms of You.com, if we just zoom out for a second...

Building Search for AI Agents

[1:41] ...what we're focused on is building the AI search infrastructure for agents. And I think you're right that we've been known as many different things over time, but our current focus really is building out this AI search infrastructure that can help power the next generation of AI agents. And there are many reasons why we view this and why we focus on this. We actually started in 2020. And when we started in 2020, we launched as a consumer search engine. So we were a search engine for humans, because agents didn't yet exist in their current form. And then what we realized over time, as we iterated on our product, is that the most important aspect of what we built, our search engine, could be used to power agents, and that actually is an even more powerful user. We predict that in the coming year or two the amount of agentic searches will continue to exponentially increase. I think there's already a statistic from Cloudflare that shows that more agents request HTML pages than humans, and we expect this to only further increase over time. So we're building for that future, essentially: how do we build search that can make sure that agents are well grounded in the external world?

From Consumer Search to Enterprise AI

[2:47] So does that also mean that you went from being, you can say, a consumer-facing product where you had a classic B2C business, but now I guess you're engaging more with enterprises? So how's the difference in dynamic here in the way you're doing this?

[2:59] Exactly. Yeah. So we did make that transition. We started as more of a consumer-facing product and then we ended up transitioning towards an enterprise-focused business, and right now we essentially power over 1 billion queries per month for enterprises. And in order to do that we have to follow certain types of governance, regulation, etc., that is really important for enterprises that is a bit different when it comes to consumer. So we've definitely had to change our identity, the way we approach technology, as we've evolved our company. And I think what we realized is, by building search for AI, we're able to really align our incentives properly with the customers that we support, as opposed to, and we were also trying to do that with consumers, but obviously the consumer landscape when it comes to search is a very different beast than this new world in which agents are much more willing to try different types of search engines, use different types of search APIs, and we think it's a much more competitive market than consumer search was. But yeah, so we've had to evolve, and we can talk a little bit more about that as well if you have any questions.

Why AI Agents Can't Just Use Google

[4:01] I have a follow-up question which I'm guessing a lot of people have: why, if you can get an agent or anything, why are you just not pointing your agent at google.com instead of using You.com? Search has been a commodity for the last two decades, and now we're entering this era where we're having specialized services to do it.

[4:12] Yeah, that's a great question. So there are a couple of reasons, and this is something that comes up a lot: Google is the search engine for humans. Why is it not the case that Google is the search engine for agents? And there are a couple of reasons why. One of which is Google's search engine is highly optimized for the consumer experience, and right now they even bundle it very closely with Gemini. It's their crown asset. It's one of the things that allows Google to distinguish itself. Their search index is this proprietary piece of technology that they've built and they've created a moat around. And for them to expose that directly actually is at odds with their core business. So what this essentially means is other businesses, when they want to use Google, are forced to essentially use what's called SERP APIs, which are APIs that essentially crawl Google, and there are a couple of issues with this approach. One of which is reliability. When you're trying to use Google in this way, reliability can fluctuate, because it's a cat-and-mouse game where Google is trying to block some of these scrapers. There was actually an interesting court case that came out regarding SerpApi versus Google, in which SerpApi actually seemed to win the court case in terms of scraping, but regardless there are a lot of reliability questions over there. And the second one is zero data retention. When you're using a SERP API, your queries are going to Google, and for many enterprises they need to make sure that their queries and their customer data never leave the [unclear] that they're using, and if you're using Google you can't make that guarantee. And then the third piece is we're actually thinking about building search differently for agents. Humans have very specific quirks compared to agents, so you can optimize search differently for agents. One example of this is how we process information. We tend to look very closely at the first couple of results, and anything below the fifth result or on the second page of Google, you just don't look at. Agents, on the other hand, can process large amounts of information more efficiently, and with token prices decreasing, it's actually a very different form of ingesting information than humans. So we can rebuild search from the ground up for this new customer, or this new user. So those are a couple of reasons why we think that there's going to be this new ecosystem of search APIs and this renaissance in search for agents, compared to the consumer space, where I think humans became very used to using Google. And Google is a great product, by the way. It's an amazing product that works phenomenally well for humans.

[6:33] Yeah. And you bring up a really interesting point here in the sense that by first being a consumer business for humans and now going into this enterprise business focusing on agents, you've tried to have both of these customers and seen the difference in behavior. So what you're describing here is that, yeah, agents don't really care about the fold, whereas humans very quickly get impatient.

Rethinking Search for Enterprise AI

[6:57] Yeah. So, tool use. So I think what we think about is, search, what we're building essentially is a tool for agents, and there are going to be other tools as well. And the higher-level term that we use to describe this is what we call augmented intelligence. We believe there are two types of horizontal AI companies. There are what we call core intelligence companies. These are the companies building the foundation models, like OpenAI, Anthropic, Gemini. And there are companies that are building what we call the tools and services that these foundation models depend on. So you could think of these as the roads that these self-driving cars are using to go further. So we're building the roads, essentially, that allow these AI models to do more. And search is that core tool or road that we're focused on.

Giving Agents Control Over Search

[7:34] So, you say you're going to launch more things, which is very interesting, but also a question I had around the search is, are you seeing a need for adding additional parameters that a traditional human wouldn't care about, where you say, oh, this actually really matters to an agent to increase the performance of doing their job with search? Are there things that machines care about that people generally don't? I know people generally don't care about search settings, but are there things that you don't even see as a setting on Google, for instance?

[7:56] Yeah, absolutely. And I'll give you one example of this. So in our research APIs, one very basic parameter we expose is something called research effort. And what this essentially means is it allows the agent to pick the amount of effort that needs to be put into a query. And that basically changes the cost, accuracy, latency dynamics. And this is something that a human necessarily wouldn't do, because when you're using search, you're being monetized in different ways, by advertising, for example. But when agents are using search, they're actually in some ways becoming more and more capable of directing their own budgets. So we actually view this, and this is one of the innovations that we worked on, was providing budgets to our agents, which other agents use. You can also view some of our tools as sub-agents, like search sub-agents, like a research sub-agent, and in that case the main agent can configure the amount of effort that the sub-agent should spend, and that's a very interesting phenomenon that's happening. And I think the better the agents get, the more and more knobs that we're going to continue to expose to these agents so that they can really optimize what they're getting out of search and research.

Where Companies Are on the AI Adoption Curve

[9:08] Cool. That's super interesting. But I also want to pivot a little bit here on topic, because I also want to talk to you about AI adoption and also AI operations, really, which is a little bit further down the maturity curve for most companies. So where does You.com typically fit into, you can say, organizations' adoption of AI? So we've seen the past couple of years everyone is saying they're doing AI, which is often handing out a bunch of Claude and OpenAI licenses and then seeing what happens. But I guess companies who come to you and say, we need a search, AI, for our agents, they're a little bit further down the adoption curve. I'm assuming here that you are probably working with companies who are a little bit more mature in their approach to AI than what you've seen with just having some AI licenses and going to town.

[9:52] Yeah, that's a really good question. So we work with a range of companies, ranging from your traditional companies that are now innovating really fast to your AI natives. So we have a spectrum of companies across industries. And on the AI-native side, what you're seeing is these companies are building out AI experiences in which they're using a lot of these reasoning models, and one of the core limitations they face is that these reasoning models don't have access to the external world, and if they did they would be able to achieve and do so much more for their customers, and that's where we come in. We essentially play the role of this tool that allows them to do more, and in that sense we are essentially part of the critical tool stack for companies that are hitting a certain point and they want to go further. One example of a company that we work with is Factory. So Factory AI is building out these droids that allow developers to do more, and they're model-agnostic. So they're using a lot of different models behind the scenes, and because of that they need an independent search provider that can power a lot of those models, and that's where we partner. So that's an example of an AI-native company. And then on the other side, we partner with more traditional companies, like some banks, retail, etc., where they're actually now starting to build their own agents and they need search APIs as well. What we find is that when people are first developing, they'll often just use the generic off-the-shelf implementations from OpenAI, Anthropic, but then once they hit a certain point in which they need to further improve performance and reduce cost, they then start really examining each particular choice and start optimizing it. And that's usually where we come in. And we also help provide evaluations where we show that by using our search API with some of those models, whether it's a frontier model like Anthropic or OpenAI, we can improve performance. And we partner very deeply with the foundation labs as well as the open-source community to make sure that our tools work really well across models.

AI-Native vs. Traditional Companies

[11:44] Yeah. When you have the chance to, you can say, interact with both AI-native companies and these more traditional companies, how do you see the difference in their approach to adopting and, you can say, operationalizing AI? Do you see changes in behavior of, you can say, these more legacy companies, if you can call them that, versus AI-native companies? What's the biggest difference?

[11:57] Yeah, there are a couple of differences. I would say AI-native companies obviously can move a lot faster. So they're often using many more models. They're probably using every single one of the frontier models plus a variety of the open-source models, and they're very quick to add new subprocessors. On the other hand, when we talk to the traditional companies, they're often very tied to a core infrastructure provider, whether it's Google with Gemini or AWS or whatever they have, and adding new subprocessors takes a lot of time. So you really have to work and build faith and build trust in your product over the course of many months, if not sometimes even a year, with a lot of these traditional companies. So that's one of the main differences in terms of velocity. AI natives, and companies that in some ways have less to lose, can move a lot faster than companies that have a lot of obligations, like banks, where they need to abide by regulation. They're more conservative. But what we're seeing regardless is a lot of these more traditional companies are starting to innovate very fast. So they're building their own technology. Almost every one of these traditional companies now is not just using off-the-shelf solutions. They're building their own agents. And as they're building their own agents, we then work with them to see if we can embed some of our tools with their agents.

The Real Metrics Behind AI Operations

[13:16] Yeah. And so you've also seen this maturity go up over the last six months. And I know even a lot of the, you say, legacy or traditional companies are really talking about operationalizing, right? It's not about adoption. It's not about everyone, whatever, AI now. It's not a thing that you need to push adoption. But now it's about operationalizing. And how do you see that happening? When companies talk about operationalizing AI, how do you see that play out? Or do they care about moving from adoption to operationalizing?

[13:38] Yeah, so I would say when companies are operationalizing AI, there are two themes that become more important. One is cost and the other one is accuracy and predictability. So when you're in the prototyping stages, and this is what we generally saw with the AI industry, nobody was really optimizing cost at all. People were okay with just spending a ton. What we've now seen in the last couple of months is there's been a huge shift in the narrative from token maxing to being efficient in terms of your usage. So this is where we're seeing cost become a much bigger part of the conversation when it comes to AI adoption. And this is also why you see a lot of routing companies that have had tremendous growth. A lot of inference companies as well that are making a lot of money and growing extremely fast because of this desire to reduce cost. If you can use a cheaper model for some workloads, people are now doing that whereas they weren't before. And the second one is accuracy. When you start productionizing, it's not enough to just have okay accuracy on some benchmarks or some, what we call, [unclear] queries. You actually need your system to work predictably on a real-world distribution, and that requires a very different level of maturity compared to the prototyping stage.

Why AI Evals Need to Go Beyond Benchmarks

[14:46] Let's go into that a little bit, how you do that, around, you say, benchmarking, evals, and so on. How do you see it from your side? I guess you have experience in this area as well. How do you approach this, ensuring that you have this accuracy that you want to offer your customers?

[14:59] Yeah, it's a great question. So we think very deeply about AI evals. We even have an AI eval team whose main charter is to innovate and continue to benchmark our various tools and offerings and really understand how we can continue to support and improve for our customers. In terms of accuracy, we also do some research on evaluation, and we're in a really interesting state right now when it comes to evals. I'll give you an example of this. We actually worked on some research which was published and received the best paper award at the AAAI conference, and in that research what we looked at was understanding the consistency of how agents perform on some of these benchmarks. It's become common practice in benchmarks to basically provide just one number over a benchmark. So there are 100 questions on a benchmark, or a thousand, you provide some number, and then you report your number versus all the other numbers in the industry. And oftentimes, because people are moving fast, you're not really providing things like statistical significance and all these statistical tools that are more common in peer-reviewed science. And that's okay, because at the end of the day, publishing benchmarks is not a peer-reviewed article, and most people who are viewing benchmarks don't view them that way anyway. They just view them as more directional: are you in the consideration set, that type of stuff. But I think it's still interesting to think about how we can do better, and it is complicated. So one thing we found, for example, is it's not enough to just look at even something like variance. It's important to understand why you have variance on a benchmark. So even if you were to report variance, it can come in two ways: it can come from what we call agent inconsistency or task difficulty. What that means is if you have different tasks on your benchmark, some of which are more difficult than others, you expect there to be some variance, which is expected. But then there's also variance that comes from agent inconsistency, which is the agent, on the same question, having very different results. So in general you want your agents to have low agent inconsistency, and this is something you can measure with tools like intraclass correlation coefficients, and we propose using these types of statistical measures to better evaluate agents. So there's a lot of interesting research that can be done in terms of really understanding accuracy one level deeper than just that initial benchmark, and that's what we're also thinking very deeply about.

Building for a Multi-Model World

[17:15] So for someone who maybe wants to make that migration from, okay, they've been using Claude or OpenAI for everything, they've basically been token maxing, but now they want to move into the space where they start taking ownership of their usage, maybe say, okay, we want to have maybe a spectrum of models and we want to try to find the right use cases. How would they approach that? Is it just start doing things and then measuring, getting different evals of how the model would respond to a given task, or how would you approach it? Maybe you have a little bit more concrete and practical experience in the space than most companies. So just curious how a company that is basically starting from one model for everything and maybe wants to move into this more diversified setup would approach that.

[17:50] Yeah, I think the first piece is to just understand what the bottleneck is and the reason why. So is it cost? Is it accuracy? Is it a growth area? If using one model for some task is working fine and it's not a cost center and it's not necessarily something that's a bottleneck, that's okay. You don't always need to optimize every system. If something's working okay, that's fine. But let's say the system is now important, it's growing, cost is relevant, you want to improve margins, then you need to start optimizing your system. And maybe going multi-model, multi-tool is the best approach. And when you get to that point, a prerequisite usually is to have some set of benchmarks and eval sets. This is often the main blocker. I think evaluation is one of those almost trite terms now that everybody's talking about. But what we see is that most businesses still are struggling to properly evaluate their agents. And I think that's something where there's a need for lots of education across the industry. And over there, and this is why we have an AI evals team, that often helps companies evaluate their agents and understand whether they should split apart their one model into multiple models and then use our tool across those models. Those are the types of nuanced questions that we get into with customers. But it usually starts, step one is just having some eval set so you can understand what the quality and cost implications would be if you were to switch one model to many. And when you get to that point, then it becomes a question of understanding the query distribution, understanding what types of models may be good fits, and understanding also kind of the expectations of the user. Are they very sensitive? Is it a complicated task? That's the other piece, is what is the actual difficulty of the task. If it's a very simple one, you don't need to be using [Fable 5.1?]. You could get away with using a much cheaper distilled open-source model. So a lot of it comes down to just understanding the actual query distribution and having your evals simulate that.

Shipping AI: Gates, Drift, and Monitoring

[19:43] Yeah. So would you say, maybe from a sense of a mental model here of how people or companies would approach these metrics, would you say this is more a way of thinking about your measurement, like uptime, where you have a consistency graph over time of saying this is our overall performance here? Or is it more like a gate, like saying, you do this, okay, we deploy this thing because we know the evals are good for whatever task we give it here? Or is it really, this is a thing we need to care about over time, because things can be sliding, because maybe the model updates so they change the model, or the data set changes, or just the context gets bigger, or whatever? So it's more like how companies think about this going forward. Is this a gate or is this a progress over time?

[20:23] Yeah, that's a good question. I would say it's ideally both. So you need some gate in order to feel comfortable introducing a change, and over there there's a ton of practices from traditional software that we've mastered over the last 20 years regarding A/B testing, rollouts, that type of stuff, which are very useful. So that's kind of the gating stage. You have some offline set, you do well on it. You then roll it out to your population, and over there you can use common statistical measures, A/B tests, all that type of stuff, to make sure you roll it out. But that's not enough, because your users' behaviors are changing. The models may change behind the scenes if you're using a proprietary model. So you then also need to be measuring how you're doing on your new query distribution. So one approach here is, if you have queries that you can use for analysis, so the user has opted in or given permission, you can then use those queries to basically sample from them and then create new benchmarks and see how you're doing on your new query distribution. So I would say you need a gate, and you also need to actively measure to make sure that you're not drifting.

Rethinking Org Design for the AI Era

[21:20] Yeah. So, again from your company's point of view, in the sense that I think we've had 10 years of reasonable stability in the IT industry, cloud, Kubernetes, all that. It was a very predictable method of how you built products. The products were different, but it was very predictable how the SDLC ran across a company, and also how the roles were divided between the different divisions. It's been pretty static for 10 years, but now it's all changing. And so how do you see it from your side? Have you organized yourself in a different way than you would, say, a normal company? I know you have an eval team, which is clearly different, but when you think about this, maybe also the AI-native companies, are they organized in a fundamentally different way than a normal engineering org would be?

[21:55] Yeah, it's a good question. I would say right now I don't know if I've seen any systematic changes in how organizations are set up, but what I'll say is some trends are, I think, the sizes of the orgs. So I think what you'll see is engineers owning a lot more and teams becoming smaller. It's becoming clear that companies can do more with fewer people because of a lot of the leverage that AI gives to people. That's one change that I think is quite systematic across AI-native organizations as well as traditional organizations. Small nimble teams can often outperform larger, more complicated teams because of the fact that each engineer can go end to end much faster. We have some horizontal teams, like security, for example. Security is important across all the products, so that's a key horizontal. And then platform also is a horizontal, when you talk about stability, reliability, uptime across service areas, DevOps processes, CI/CD. Those are horizontal pieces.

What Actually Wins in AI Products

[23:00] What is the key differentiator, then, if people are really succeeding with AI? Is it leadership? Is it they have a vision or an idea? What's the difference between people who are really failing here and people who are really succeeding? And maybe it's too early to say, we're very early in the adoption space, but where do you see the main difference in what is failing and what is really succeeding?

[23:12] Yeah, this is a really good question. There are many different ways to answer this, and I think many ways in which people are succeeding, but one general note in this AI world is it's really important to be intentional about the product you're building and understand how it is going to play into a world in which models become more and more intelligent. So a lot of companies that built a lot of technology that in some ways relies on the core deficiencies of current models were heavily displaced as the models became better, and their value proposition became less clear. An example of this is there was a range of companies that existed that basically prompt-engineered these early Turbo models and were able to build experiences by building a lot of scaffolding on top of these. But then as the models got a lot better, the need for that scaffolding disappeared, and with that the value proposition of those companies also disappeared. So the key to me is really thinking strategically and ensuring that your product or your company will benefit as the models become a lot better. If your company will be threatened by the next iteration of a frontier model, then it's a very uncomfortable position to be in, because those models have continued to become better at an exponential rate, and I think we should assume that these models will continue to become more intelligent. And in many cases intelligence is no longer the bottleneck on many applications. And you have to understand which category you lie in and not get confused, because I've seen a lot of companies who are not foundation labs try to build technology that will eventually be solved by a foundation lab and iteration in the model. That is a little bit of a hard truth, but I think that it's better to accept that and then build products around that ecosystem and assume and make those models go even further. So that's why, in my head, the way I view it actually is the inverse of what we saw with self-driving. We actually had roads long before we had these self-driving cars, and the self-driving cars have now been operating on these roads, and you see them in Silicon Valley and Phoenix and whatnot. In the case of AI, we had these very intelligent models come around before there were many roads that allowed them to connect, and one of those roads is search, for example. And that's just one example, but that's a vertical focus. There are also other focuses too, like new product surface areas that I can't even imagine right now that are coming about, and new form factors and ways to interact with the world.

Avoiding AI's Biggest Engineering Trap

[25:39] So, talking a little bit back about, you can say, adoption among these companies that you interact with, in this whole phase of really adopting and maybe operationalizing AI, where do you see companies typically waste the most time? What is the hardest hurdle to get over? And then maybe an extension of that: what kind of problems naturally just disappear after six months of these growing pains? What typically stops being a problem after six months?

[25:56] Yeah, I would say, so in terms of wasting time, I can just speak from our own experience, and I wouldn't call this wasting time. I would call it learning and evolving with the industry. But I'll give you an example. So we spent a lot of time working on very complicated scaffolding around models and complicated orchestration. So our advanced research and insights agent, when we launched it, was actually better than open deep research on various benchmarks. We would calculate win rates, this type of stuff. So we launched something quite early that was very performant, and we put a lot of effort into coming up with this really interesting orchestration system that was able to parallelize a lot of the tests, had a lot of [unclear] model usage in very interesting ways. And then what we realized is over time, as the models got better, we were able to improve the system by removing more and more components from it. And what that basically meant is we saw that these models are becoming much better at long-horizon tasks, and that focusing on the right tools with those long-horizon models, or those models that are capable of doing long-horizon tasks, was a much better use of our energy than trying to constantly use manual heuristics to account for some of the existing gaps. Oftentimes companies need to do that because you are deploying something to production today, not tomorrow, so you need to come up with it. But what I would say is I think it's probably worth putting minimal effort into some of those pieces that we think are going to essentially be solved in six months by model improvements themselves. So I think that's kind of one area in which, at least I've personally, probably spent too much time, and that didn't really stand up to the test of time. So I think it's important to think about, okay, what are we working on that is going to be useful six months or a year from now? What are we working on that's probably going to be less valuable six months or a year from now? You still may need to do it right now, and that's okay, but it helps frame the investments there. So maybe it's okay to have a little bit more tech debt on something that you're working on if you think it's not going to exist in six months, whereas the piece that you're working on that's more foundational, you want to focus and make sure that it is much more stable and sustainable and foundational.

Where the Next AI Moats Will Come From

[27:58] Amazing. Just to wrap up here a little bit, I'll ask you to look a little bit into the future. The conversation has been a lot about models and optimizing for the right model. We have model routing as a very new concept that a lot of people are adopting. Now we are probably going to assume that the model is going to become a commodity in a lot of ways. Of course there's going to be model innovation going forward. There's going to continue to be capabilities, but anyone can get access to a lot of different models. It's not something that is blocked, right? So whenever everyone has access to the same technology, where do you think the proprietary value lives in five years? What is it that really sets things apart in the space? Is it the model? Is it the access to data? Or is it really how well you do evaluations? What do you think it is? And five years is a long time in this space, I know.

[28:41] So, yeah, five years, who knows what's going to happen in five years. I think it's very hard to predict the future right now. But what I will say is it depends on who you are. So if you're a foundation lab, I think the core IP over there is the actual model itself, in which case you want that model to be performing well on benchmarks, versatile, self-improving. I think that's another thing that's becoming more important, this idea of recursive self-improvement of models. So that's if you're a model company. If you're not a model company, it depends a bit on what type of company you are. There are many companies that I think are much more partnership-focused. So these are companies that have amassed lots of partnerships that are sticky over time. Maybe view Amazon even in this category, where they have all these partnerships with buyers and sellers and warehouses and distribution. That, I think, is still going to be quite important even five years from now, as it is today. But then there are other kinds of companies, like software companies or pure software companies, where I do think a lot of the advantage will probably be the data. Most of the data is actually not public in the world. There's a lot of data that's private, and I think that many companies that are able to properly collect, enrich, and use their private data will be in a very good state five years from now, and those foundation models will be able to properly leverage and accelerate those companies with their unique private data as a moat. So that's another, I guess, prediction: a lot of the companies that have unique data assets will continue to be relevant and important. And then another piece is, at the end of the day, it just comes down to making customers happy, whether it's consumers or whether it's other businesses. And I think if you're able to produce businesses that provide value to people, and customers love the product, love working with you, that's very useful, and that will always be valued in the market. And I think that what we may see is more companies, but smaller companies. So I think we'll see the rise of many more small companies run by a couple of people that maybe look more like service businesses, but it's okay, because they don't need to have crazy amounts of revenue on this venture scale. So I think we'll see more and more of that with AI. We'll see a lot of companies that look like service-based businesses, but their margins may not be as good, but that's okay because they're much smaller and potentially bootstrapped.

Closing Thoughts

[30:59] And I think that was my last question for this time. Thank you so much for your time here and thank you for answering all my questions and delivering your insights. And I need to do an outro, which is: this is the podcast Ship Happens, and it's sponsored by Docker. And again, thank you so much for your time, Saahil. It was a pleasure talking to you, and see everyone next time.