Rethinking Search as Code Generation

Search is a core primitive for AI systems. Frontier models grow more capable by the month, but they still need access to fresh, accurate, and well-curated knowledge from the wider world. Search is the primary way that AI systems tap into that knowledge, and thus a foundational component of any product that needs to draw conclusions, take actions, and perform real-world work.We believe that traditional search pipelines are increasingly outdated in the era of agents. Traditional search answers queries, but today’s agents complete tasks that can take on countless shapes. These tasks require agents to define task-specific retrieval strategies directly within their harnesses. Within Perplexity Computer, we’ve seen single tasks invoke hundreds or even thousands of retrieval operations within a few minutes: a workflow that is impossible for humans but absolutely natural for agents.In this world, search itself must become agentic, with its building blocks accessible directly as SDKs within the agent harness. We are introducing Search as Code (SaC) as Perplexity’s new reference search architecture.IntroductionPerplexity's search stack serves thousands of queries each second across our applications and API Platform. In September 2025, we published the first architectural overview of our search systems. Constant innovation within these systems has supported the launch of new offerings such as Search API, Agent API, and Computer, with self-improvement loops optimizing the search stack to better serve users with each passing day. Traditionally, AI systems have treated search as a monolith: an AI model issues a query, the search engine runs its predefined pipeline, and the model consumes the results as context. For the most part, this worked fine to address the needs of early AI users. Given the relative simplicity of their requests, there was no reason to worry about exactly how the search pipeline was designed, or whether the pipeline's architecture was optimal for the task at hand. The defaults were presumed to be good enough, as were the default interfaces (function calling and MCPs).Figure 1 | Traditional search architectures expose a single fixed system that models call serially, while Search as Code exposes atomized search primitives that agents compose through generated code.Yet today this approach grows more outdated with each passing month. Users demand much more than single-shot analysis from AI. They expect agents to complete tasks end-to-end over hours or even days.

These tasks can be complex, open-ended, and highly variable in their information needs, and monolithic architectures are buckling under the weight of these demands. The key bottleneck is ultimately one of control. Frontier models are already quite good at reasoning over fixed context. However, the most powerful AI systems will require the ability to steer how that context is retrieved, processed, aggregated, and rendered to the model. Traditional search systems were not designed with this degree of controllability in mind. After all, human users cannot be expected to exercise fine-grained control over search pipeline internals even if it were offered. Early AI models can control search only through a linear trajectory of function calls and MCPs. But today's frontier models, driven by code-capable agent harnesses, can exert fine-grained control over any computational primitives imaginable through computer code. Our task becomes to provide the right primitives.To meet this need, we are introducing a new search architecture across our products: Search as Code (SaC). This new architecture empowers models to reach into the search stack itself rather than merely consume its final outputs. The core idea is straightforward: we expose the components of the search stack as primitives within an SDK. For any request that needs search, a model assembles these primitives on-demand into a retrieval pipeline tailored to that specific request.Assembling this pipeline is done through code generation and execution within a secure sandbox. Unlike other codegen-driven approaches to search, we do not simply stick a traditional search API within a shell or language runtime. Instead, we've carefully engineered an Agentic Search SDK that exposes the individual building blocks of search at the most atomic level possible.Figure 2 | Search as Code (SaC) advances the performance frontier of agentic search across a diverse suite of benchmarks.Armed with these building blocks, SaC gives models direct control over each individual search step: retrieval, ranking, filtering, fanouts, rendering, and more. It also gives the model efficient access to intermediate state such as candidate lists and ranking signals. Together, these twin levers of control and legibility allow agents to design bespoke search pipelines spanning thousands of retrieval operations, optimize those pipelines in-flight, and consume only the most useful information as model context.This article describes SaC's motivation, design, and implementation, alongside empirical results on both existing and new benchmarks.

SaC establishes a new cost-performance frontier for agentic search, and we're excited to share it with our users and the broader AI community.The Rigidity of Traditional SearchThe world's first search engines were built for human users. These users came to expect a predictable experience, typically consisting of a fixed number of relevance-ranked documents. Users did not want to micromanage the search process; they wanted to enter a query and find a useful result.As a result, human-facing search engines converged on a common monolithic architecture, geared toward producing human-friendly search engine results pages (SERPs) containing the top n hits for an input query. This pattern has powered decades of progress in consumer search. It is fast, familiar, and highly effective for human browsing.Then came LLMs, and AI systems also became consumers of search. Perplexity pioneered this shift with the launch of our answer engine in 2022. Since then, our search engineering efforts have focused on how to optimize the value of search results for AI models. To build the world's most accurate and reliable AI, we had to engineer a search system focused on making each token as information-dense as possible. The resulting innovations in sub-document retrieval, context efficiency, semantic understanding, and other key areas led to dramatic improvements in AI systems' ability to retrieve and act on information.However, even AI-optimized systems have largely inherited the same fundamental contract as traditional search engines: accept a query, run a predefined search pipeline, return a fully processed resultset. For simple requests, this approach works fine. But for more complex requests, this becomes an increasingly limiting bottleneck that degrades performance, latency, and cost.Figure 3 | Traditional search systems force agentic workflows to sequence search through model-visible turns. Models must repeatedly call the same search pipelines across different query parameters and introduce all results into model context.Failure Modes from RigidityTraditional search pipelines are designed around a single point of control: the query parameters. The search engine owns the rest of the pipeline according to its predefined logic, and the model must adapt to it. To the model, anything downstream of the query parameters is rigid—the shape of the actual computation is outside the model's control. This is a sensible boundary when the consumer is a human scanning links. It is a poor boundary when the consumer is an AI model trying to solve knowledge-intensive tasks in a closed loop.

In our experience, this rigidity creates three recurring failure modes:Coarse context. AI models are sensitive to the quality and compactness of context. Both quality and compactness are highly query-dependent, and monolithic search pipelines are not designed to perform optimally across all queries. For instance, if a model needs a single, highly surgical piece of information but only has access to an end-to-end search endpoint that prioritizes recall, using that endpoint will introduce a large amount of irrelevant information into the model context. On the other hand, if a model needs many pieces of information that each require different search strategies, it may be forced to serially invoke the same suboptimal pipeline for all of them, resulting in ballooning costs and noisy context.Failure to leverage domain knowledge. In many cases, the model may have domain knowledge (from its training, an Agent Skill, memory, or earlier tokens in the LLM trajectory) that should guide the search strategy. However, a rigid search interface prevents the model from leveraging that knowledge. For instance, the model may realize for a specific request that it should blend lexical and semantic signals in a particular way, prioritize certain sources, or aggregate results by a specific key. Unless those insights happen to be implementable through query parameters, the model cannot actually act on them.Inefficient control flow and context pollution. Many search workflows are not naturally serial. They might need fan-out over query variants, parallel fetching, deduplication, and other operations that require nonlinear and asynchronous control flow. Forcing these steps through repeated model turns adds latency and makes the workflow harder to optimize. It also pollutes model context with noisy intermediate state that may not be useful for the model's reasoning, resulting in poorer performance and more frequent compactions.Not much could be done about these challenges during the function calling & MCP eras of AI. When each search operation requires its own roundtrip to LLM inference, developers naturally prefer to get as much done in that roundtrip. This means end-to-end search pipelines that return fully processed resultsets for direct consumption by a model.As a result, most AI-facing search systems today still operate under this monolithic contract. However, with continued growth in model intelligence and user demands, the shortcomings of that contract become more pronounced. Today's most advanced AI systems, built atop code-first harnesses, can compose task-specific workflows that execute thousands of actions each minute. Search systems have yet to fully realize this potential.