The Ads Business Model Will Die & Lessons from Working with Elon at Twitter | Parag Agrawal

Ads don't work with agents in their current form. Some people actually want to do bad things and the model's alignment is not adversary-proof, and I think those are the things we must worry about more. I think it's the responsibility of people building models to ensure that you really do the work to minimize that harm that comes from what you've built. And I think so far, I think some of these should be considered embarrassments because I think they demonstrate two things.

Thanks for having me and thanks for making all the calls.

Parallel is the Google for agents. So agents need to search the web to do anything they do for you, whether it's a personal agent or an agent built for work. Just like humans need to go on a browser, search Google oftentimes during work or for whatever you're doing in life, your agent needs to do the same. Turns out agents are different from humans, and the way you build web search for agents is different. And so Parallel is about building the technology for agents to search the web, and then the business models to make that sustainable.

Yeah, literally the first genesis of the company was us, like the statement that agents will use the web a thousand times more than humans. Like I wrote that down at some point. Hence, new tech is needed and new business models are needed. A thousand times gives you a sense of scale. It changes how you think about building the tech underneath because, like, no tech built for a certain scale survives three orders of magnitude. And then when you need new business models alongside new technology, a problem becomes really interesting.

There are many, many layers to the answer, but let's start at the first thing we mentioned, which is scale. Right? Now, if you think about, let's say agents actually do end up searching the web a thousand times more. If we spend the amount of compute we currently spend as per web search, that's too much compute for web search. So you now need to make it way more efficient by perhaps, I think, 10 to 100 times for it to make sense.

If you're doing a thousand times.

Exactly. Like, the second thing is agents expand. Like, humans operate in a very narrow zone. So if you think about how we use web search, we type keyword queries which are short and underspecified. We wait for about half to one second. If web search takes more than that, we're impatient. And then we get 10 blue links and then we random walk across them and a collection of searches to get what we're doing. Agents are not like that. Agents are going to perhaps tell you exactly what they're looking for, not like three keywords, but like a full sentence, like this is what I'm trying to do. Agents will either be super impatient, like imagine a voice agent. The agent will be like, I need an answer like now, 100 milliseconds. I can't wait 500 milliseconds because the human is waiting on me and they're going to wait 500 milliseconds. So I need web search to do it in 100, or they're going to be a background agent who's like, I don't care, just give me the best answer possible. Right? And so the variance of what you can do within web changes completely. In fact, the one thing that is the least interesting is what we've built for humans. Right? You either have too much time or too little time. Almost never the same amount. The output is not the same. So the input is different. The time you have is different. The output is different. The output is in blue links. The output is tokens or files on a file system depending on the type of agent. And so now all of a sudden you say, okay, now the problems, inputs are different, outputs are different, and constraints are different, and you get to spend very different amounts of compute on it. Right? So imagine someone running an agent built with a Llama model, and then imagine someone running an agent built with a Fable model. They're very different models. How you want to optimize signal to noise and tokens for each of them is so different in terms of what you do in the web search stack.

So think of it this way. Let's say you took web search, which was cheap and fast and low compute. One way of conceptualizing the web search problem is you start with like a trillion documents that are on the web, some few trillion. Given any search, I now need to narrow it down to a thousand tokens that your model's context window should see. So the problem is going from a trillion URLs with, let's call it, a few thousand tokens each down to a thousand total tokens. So how do we do it in web search? We first say, okay, we're going to do retrieval. So for most documents, I'm going to spend zero compute. For a small number of documents, I'm going to spend minuscule amounts of compute to figure out which 10,000 to look at. Once I get these 10,000, I'm going to spend a little bit more compute for each of these 10,000 documents to narrow it down to 1,000 documents. And I'm going to keep doing this with bigger and bigger models and rankers with more and more features until I can narrow it down to a thousand tokens for your model. Right? So you're essentially allocating compute to web search in order to save compute on the model. That's roughly what's going on here. So if you want to save compute for the model, the question is how much compute should you allocate? So if your Llama model is really cheap, you don't want to do too much compute in web search because it's okay to leak a little bit more information into Llama's context because it's cheap. Into Fable, you want to do the work before you waste Fable's time because that's going to be expensive in time and money for you if web search gives you worse answers because you cheaped out on web search.

You allow the agent to specify that in the API signature. So our product is an API which either the programmer can configure based on their application or can leave it to the agent. Our API even has a parameter which is like, what's the model calling me? And if you know the model, we can do things differently. Now, you don't have to tell us, but if you tell us, you might get better results. You can, we ship just like, you know, you can use like a model, you can use a small model or a big model, and you can use it with like low thinking or medium thinking or high thinking. We have productized our search system into a few different modes, each optimized for a certain class of use case. For example, we have a really, really fast API, the fastest in the market. It's fast and cheap because with low latency budget, there's only so much compute you can do. And it's built for voice agents. So your voice agent must be all-knowing without telling you guys, I'm searching the web. Hold on while I come back with the answer. Like that's a silly experience for a voice agent, right? But it should just like magically immediately respond. And so you now need to do web search which is like rapid. Right? On the other hand, you can take a Fable model and the thing is going to think for 20 seconds and then generate. For it, you can spend 5 seconds on web search to make sure it does instead of five web searches, only two. So you end-to-end in the agent, you save time and cost. And so that's a different processor on our system. It's called Advanced. So you use Turbo if you're building a voice agent. You use Advanced if you're like really expensive background agent.

It's pretty broad. I would say the primary use case, the common theme is knowledge work. So coding is a category of knowledge work. So are AI lawyers. So are productivity applications. So are AI insurance underwriters. So are scientists.

No. The thing about engineering is coding is a large chunk of inference in the market right now. Coding invokes, I would say, web search in 5% of prompts.

Right. So it's not every prompt invoking web search when you're writing code because most of them rely on your internal context and your internal data and your codebase. So the model is spending time reading your internal code and not on the web.

Law is very web search oriented.

There is internal data, but there is case law. There is facts. There's facts about companies, facts about people. And you have to go exclude information. So you have to be very comprehensive in law to say, I want to be confident that despite a lot of effort, you can't find this. Right? Insurance underwriting has the same flavor, right? So there's sales is very web search heavy. AI science is very web search heavy. So on a relative basis, inference goes more in compute, but when you think of web search, all of these others start popping too.

You know, I think in our business, right, anytime agents start becoming more useful for more use cases because models either get better or cheaper, it's great for us, right? Because we bet that agents will be the consumers for the web and we've been building tech for agents. So when agents do more, it's great for our business. So we want models to keep getting better and cheaper so that agents do more and more and more. And if that happens, it's great for our business.

I don't think so. If you think of models, there is the trend around models being smarter and then models having more memorized and parametric memory. Like those are two slightly different dimensions. And if you think of the today, by and large, I would say models have good recall from parametric memory on, let's call them, head facts. It's like for somebody famous, everything about them, Wikipedia, it can memorize. So it'll tell you who the president was in a certain year, right? Because a model can memorize those things. The model couldn't tell you what year I graduated from college.

Maybe for me it can, but it can't tell you for somebody who works at Parallel.

Even if it was in the pre-training data, because it's lossy compression. So what a model's parametric memory is doing, it's lossily compressing to understand patterns in the world. And so it can't memorize every fact in pre-training data. So one, not every fact is in pre-training data. Two, it can't for even stuff that's in pre-training data. The model's actually trying to find patterns rather than memorize them. And so, and then further, as you make models efficient, which is you make them smaller and smaller while keeping the performance by distilling them or whatever, you lose more of the parametric memory while you try to keep the reasoning.

So there are two questions in there. So one, I think we're going to see two things. We're going to see the biggest or the frontier models be bigger and bigger over time. We are also going to see smaller and smaller models being able to reach any fixed level of performance. So if you say, okay, I want Opus 4.8 level of performance. Okay, and that's good enough for my use case. Every six months, a much smaller model will be able to deliver that to you. So you're going to see this, the useful range of sizes of models will be way, way, way different.

They are better. So all of the ramifications you imagine. So the reason the frontier will get bigger and bigger is ultimately the gap between what the value for certain use cases, incremental quality can provide you, can be so high in certain use cases which can be so valuable that it's worth paying for. So if you can build it, there will be use cases for it. As long as by making it bigger, you can make it better. It appears there is no end to the scaling law that we can perceive so far. And again, I'm conflating bigger with like models are getting bigger, but they're also able to think longer. So you're just able to throw more compute at the same problem. And that will keep happening. I think we'll be able to throw more and more compute at the same problem and make the answer be marginally better over time. And so we're going to just spend a lot of money on extremely large models solving really hard problems.

I don't know enough to have a view there. I don't have a view on that. I do think, I don't think it'll be 90% on either of those two, actually.

Yeah.

So if you believe my claim that a useful model and the frontier model will be 100x, 1,000x off in price from each other. So if the small model is still useful, it is hard to know which use cases over time will get optimized to which scale of model in between. And I think there is a real path dependency in terms of where open models end up. I do think if we had strong confidence that an American-built open model was going to be state-of-the-art as far as open models went, I would have more confidence in saying that they'll be pretty good.

I want them to exist. So far, it's not clear what's going to happen, but like I'm hoping that there will be a great series of American open models and perhaps even competition to have the best American open model. So I think what you need is actually not just one person motivated to build an American open model. You need two people competing against each other to build the best American open model.

Again, there's path dependency. So today there is real value. Today there's real value because, so when we say routing, we talk about two different dimensions: which model and which GPU running that model via which vendor. When you're in a world where the demand supply is very weird and people are like hunting for GPUs and people need capacity to serve their customers and people, all of these are like us, like relatively early stage startups growing really rapidly, sometimes beyond what your forecasts or predictions say, and then all of a sudden you're looking for capacity. And so you want to be able to get it where you can. And so that creates real value in having some of these routers as login. They can solve these two problems, saying, give me flexibility. If I need to get a different source of tokens and push comes to shove, if there's no tokens on this model in the SLA I want, I'll switch models as well. So in this moment, it's really valuable. Now I don't know what happens to overall demand supply on GPUs and tokens, but if it remains this way, the routing layer is really valuable.

When I say data, I think it is, I think today we don't know how to pay for unique valuable insight or data. Because we live in a, as intelligence is cheaper, you're going to want to build upon either data or insight that comes from somewhere else with your unique data. Right? So what, like if you think of like an abstract notion that, okay, I have intelligence here, I own some data, you own some data, and there's some data in the public domain. If we can pull together your insights and my insights and all of this data in the public domain and intelligence on top, we can create something bigger than what you could have done by yourself, what I could have done by myself.

And so that transaction feels like a data transaction to me or an insight transaction to me. And so we don't yet know how to transact that way. So we fall down to, okay, all I can do is use my data and use open data and let's see what I can do with. But if we figured out better ways of pricing data, good things will happen, but it's not something that's yet a market. But what I'm talking about is data transactions at inference time. So it's not necessarily training time. We are building knowledge. And let's take an example of today's world, for example. Let's say in your job, since I'm sitting with a VC, you probably have access to a PitchBook or like a product like that to collect data. And so you get grounded in knowledge of what's happening and you get to use that data to figure out how to make decisions in addition to all the notes you have and deal memos you've written perhaps over the years or insights you've had about like how to choose founders. And you're essentially composing insights from your personal lived experience, your notes, public data to make decisions. Now you pay PitchBook by the seat, but now you're running a bunch of agents and your agents can perhaps not access everything you can on PitchBook or you're doing like sort of this to get a browser perhaps against terms of service to send an agent via browser to PitchBook using your own credentials and it's inefficient. It's clunky, right? But clearly their data is valuable and clearly your agent should have convenient access to it. So if we figure out how valuable PitchBook data is for your agents to make your decisions, because clearly you're investing a large hundreds of millions of dollars. So clearly you presume that you make a great return on that. So this data is truly valuable if you depend on it today. So you should be able to figure out how to compensate PitchBook for the data even when agents use it, which is not by the seat. If we figure that out, it'll be a huge market and agents will be better off. If we don't figure it out, you're going to be in this weird cat and mouse game of PitchBook being like, no, I want to sell you a seat. I'm going to shut it off. And your agent is stuck without the data and then like you're involved in like pulling data.

I think eventually everyone will have to let them in. The question is on what terms. So how do you align incentives for everyone? And people are going to have to play their strategy games on how they win in this new world. Literally the customer is changing in front of our eyes, right? Like the customer used to be a human. You're building products for humans. Now you're building products for agents or you're building agents. And so now you have to figure out what your place in this new reality will be. And I don't know if there's a right or wrong answer here. It also depends on sort of how much market power you have. Right? So let's say you are an individual.

I don't know, depends on what they do next with it. Right? Like so it's like if it turns out that they have sufficient market power to have Muse or other agents connect to them differently perhaps over time or ship their own agent and drive crazy adoption, let's say they have that capability, then I guess they were right, right? On the other hand, once they've made this, we're not now anyone else's agent and they cannot ship an agent that consumers use and they won't allow anyone else's agent to use them. And a lot of the transaction economy starts moving off to agents, which are all big ifs by the way, then it would be a bad move. Now I am betting on agents. I have mixed feelings around agents and what fraction of e-commerce transactions they do. Like it's unclear, right? Like is...

So me too, but I also know a lot of people who like to buy things themselves. And like, listen, we want to delegate to agents things which we see as chores and uninteresting and not delegate to agents things that give us joy or pleasure or make us have fun doing those things. And I don't like, I know people who don't want to delegate shopping. They want to delegate a lot of things in their life. They don't want to delegate shopping. And so I don't know, that's why I don't know the distribution of these people and how behavior changes, but it might be people give away a lot of other chores and then spend a lot of time shopping.

And this is not just, you're talking about this in the e-commerce land, right? But if this is the problem with everyone, if you think about like, so this is what I meant early on when I said like the business models have to change. Ads don't work with agents in their current form. So forgetting e-commerce for a second. If you think of you're in the content business, let's say you have a page which is ad supported. It's public information on the web. Ad supported page. People show up, you show them ads, you make money, great content. Agents show up, no one sees ads, you make no money. Which is why we like to pay people. So we're effectively building an AdSense for agents showing up to read your content. So we like to pay content owners a variable amount of money every time an agent derives benefit from reading their information, which is a variable amount of money is what a visitor to your website will pay you based on a click probability or a value probability on ads.

To incentive align content owners. Otherwise, what's going to happen? Everyone's going to block agents. So you need to find a replacement to the ads business model.

No, but I think they're going to block them and not my... They're going to give me a data feed if I... What does incentive alignment mean? It means the New York Times believes that I pay them a competitive market price or the right price or an attractive price or a fair price. If I do that, they should give me their content. And if somebody else doesn't give them that and if they have the technical levers or legal levers, they shouldn't give it to them.

I don't know, but I don't think so. I think there's one fundamental thing that is different here. I think agents using the web a thousand times more, like that, a thousand times is really different. Now all of a sudden, the amount of utility added goes up if these agents are presumed to be doing something useful. And so this is not just a change in the share of value that people transact over. This is a large growing pie. And when that happens, it is actually possible to transition business models. Of course, don't get me wrong, there are going to be winners and losers, right? Like some pieces of content will become very valuable. Some pieces of content will get more commoditized and people are going to have to adapt to a new customer, to a new market dynamic, to a new kind of monetization engine. But the overall market size, I think, has the potential to increase, unlike in music where it took a while for it to grow back. I think my understanding is now the industry's grown back up and exceeded its previous peaks in a material way. But there was a moment where it was smaller. In this case, that might be a very compressed period given how fast these things are growing.