20VC: Five Predictions for a World of Agents | The Ads Business Model Will Die | Biggest Lessons from Working with Elon Musk at Twitter with Parag Agrawal, Parallel

The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch

Former Twitter CEO Parag Agrawal discusses the infrastructure requirements for a world dominated by AI agents. He explains how Parallel is b

Key takeaways

• Agents are predicted to utilize web search 1,000 times more frequently than humans, necessitating a complete overhaul of search technology.
• The current advertising business model is incompatible with agents; new models must focus on compensating content owners for data/insight transactions.

Main topics

• Agentic Search Infrastructure
• The Death of the Ads Business Model

Notable quotes

Agents will use the web 1000x more than humans.

Conclusion

The episode highlights a fundamental shift in how information is retri

Transcript preview

Speaker 2 (0:00) We're going to see the biggest or the frontier models be bigger and bigger over time. It appears there is no end to the scaling law that we can perceive so far. I think today we don't know how to pay for unique, valuable insight or data. Ads don't work with agents in their current form. You need to find a replacement to the ads business model. I do think there should be some disparity in wealth, but I don't know what's too much. Speaker 1 (0:24) This is 20VC with me, Harry Stebbings. Now, what do Andrew Reid, Vinod Khosla, and Josh Koppenman all have in common? Well, they all believe in Parag Agrawal to change the future of agentic search. Parag is the founder of Parallel, as I said, changing the future of how agents do web search efficiently. This is an incredible discussion on the future of agentic search, the future of income and wealth inequality, and so much more. Parag rarely does shows, and so it was very special to sit down in person with him in London. But before we dive into the show today... MongoDB has always been the database developers love. Well, now is the data platform AI agents need. Agents need accurate context, fast. MongoDB stores, searches, and reasons over your data in real time. JSON native database, vector search, and voyage AI embeddings all in one place. One system instead of 10. No data pipelines to maintain. Oh, this sounds too good to be true. Build and scale from your first user to billions of vectors. run on any cloud, on-prem, or your laptop even. That's why 75 % of the Fortune 100 run their most critical apps on MongoDB, moving trillions of dollars every single day. And it's why AI-native companies like Eleven Labs run 40 million agents on MongoDB. So if you're building an AI, MongoDB for startups helps you move faster with Atlas and Voyage AI credits and dedicated support. Don't build agents that answer once and forget. Build agents that remember and learn. from your real-time data. Go to mongodb.com slash agents. That's m-o-n-g-o-d-b dot com slash agents. While MongoDB scales the product, Framer scales the story. When a new landing page turns into a pile of tickets and handoffs, Framer helps your team move faster. Framer is the AI website builder that helps creators, teams, and businesses ship production-ready sites faster than ever while getting every detail right. Prompt, inspect, edit, and publish in one place at a whole new pace. Agents and humans work in tandem. Agents bring speed and scale. You bring taste, judgment, and control. The work lands on the canvas and stays editable. Build custom code components, manage CMS content, optimize SEO, and audit for issues all in one place. Enterprise-grade hosting, security, and 99.99 % uptime SLAs trusted by leading brands like Perplexity and Miro. Learn how you can get more out of your site from a Framer specialist or get started building for free today at framer.com slash 20VC for 30 % off a Framer Pro annual plan. That's framer.com slash 20VC. Rules and restrictions may apply. You have now arrived at your destination. Parag, I'm so excited for this, dude. I spoke to Vinod. I spoke to Andrew Reid. I spoke to Todd Jackson. Dude, I stalked Speaker 2 (3:19) the Speaker 1 (3:19) shit out of you. So thank you for joining me. Thanks Speaker 2 (3:21) for having me. And thanks for making Speaker 1 (3:22) all the calls. Not at all. I would love to start with, for anyone that doesn't know, how would you describe Parallel in 60 seconds? Parallel Speaker 2 (3:32) 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. Parallel is about building the technology for agents to search the web and then the business models to Speaker 1 (4:00) make that sustainable. Was that the original insight that you had? Speaker 2 (4:03) Yeah, literally the first. Genesis of the company was the statement that agents will use the web 1000x more than humans. I wrote that down at some point. Hence, new tech is needed and new business models are needed. 1000x 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 Speaker 1 (4:26) then when you need new business models alongside new technology, a problem becomes really interesting. How does the world of agents change web search in terms of the technology required? Speaker 2 (4:36) 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 X more. If we spend the amount of compute we currently spend 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 X. for it to make sense. Yeah. Speaker 1 (5:01) If you're doing a thousand eggs, yeah. Speaker 2 (5:03) Exactly. The second thing is humans operate in a very narrow zone. So if Speaker 1 (5:08) you Speaker 2 (5:08) think about how we use web search, we type keyword queries, which are short and under-specified. 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 gonna... 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. And so. The variance of what you can do within WebSort changes completely. In fact, the one thing that is the least interesting is what we've built for humans. 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. So imagine someone running an agent built with a Luna model. And then imagine Speaker 1 (6:27) someone running an agent built with a Fable model. They're very different models. Speaker 2 (6:31) 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 what do you mean optimize signal for noise? 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, say a 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. 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 Luna 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 Luna'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. Speaker 1 (8:10) Can I ask, how do you deal with the ambiguity of what agents want? And what I mean by that is... For different things, an agent might want different things. And for different people, an agent might want different things. I may really care about accuracy and not at all about latency or cost. I may really care about latency, but not at all about accuracy, really. So Speaker 2 (8:30) 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? If you know the model, we can do things differently. Now, Speaker 1 (8:49) you don't Speaker 2 (8:49) have to tell us, but if you tell us, you might get better results. We ship, just like 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 productived 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. That's a silly experience for a voice agent, right? But you should just like magically immediately respond. And so you now need to do web search, which is like rapid. On Speaker 1 (9:35) the other hand, you can take a Speaker 2 (9:37) Fable model and the thing is going to think for 20 seconds and then generate for it. You can spend five 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. Speaker 1 (9:59) And so the primary use case today in terms of customer base is engineering and coding? Speaker 2 (10:04) It's pretty broad-based. I would say the primary use case is the common theme is knowledge work. Coding is a category of knowledge work. So are AI lawyers. So are productivity applications. So are AI insurance underwriters. Speaker 1 (10:17) So are AI scientists. I'm trying to understand how much of the mother load is engineering. Is it 80 %? Speaker 2 (10:24) 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. Whoa. Right? So it's not every prompt invoking web search when you're writing code because most of them, they lie on your internal context and your internal data and your code base. So the model is spending time reading your internal code and Speaker 1 (10:50) not on the web. Law is not going to be much more, is it? Law is very web search oriented. Really? I thought it'd be internal data driven. There is Speaker 2 (10:57) 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. Insurance underwriting has the same flavor. 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 Speaker 1 (11:25) of these others start popping too. We were talking before about muse and instinct. If there's anything that needs web search, it's personal assistants. Yeah, it's great. How does that change? Yeah, it's great. This is like, woohoo, this is the greatest thing for my business. How does that change your business? Speaker 2 (11:40) In our business, right, any time 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 Speaker 1 (12:07) for our business. If models get smarter, don't the agents beneath them do fewer searches and then it's worse for your business? I don't think so. Speaker 2 (12:17) If you think of models, there is the trend around models being smarter and then models having more memorized and parametric memory. Those are two slightly different dimensions. 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 can memorize. So it will 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 Speaker 1 (12:52) can, but it can't tell you for somebody who works at Parallel. Do you know a thing, sir? If I actually, I mean, if I were Speaker 2 (12:58) to... Speaker 1 (12:58) Even if it was Speaker 2 (12:58) in the Speaker 1 (12:58) pre-training data. Speaker 2 (12:59) Because it's lossy compression. So what are models 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 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 Speaker 1 (13:29) lose more of the parametric memory while you try to keep the reasoning. Do you think we will see models become smaller and smaller and every company have their own model with their own data and the fireworks theory of, you know, own your own intelligence being true? There are two questions in Speaker 2 (13:44) 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