Rethinking Search as Code Generation
Published: June 1, 2026
Evolving search from monolithic services to programmable primitives for the era of agent harnesses.
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.
Introduction
Perplexity’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).
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.
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.
Architecture
SaC involves three tightly coupled layers:
- Models serve as the control plane. They reason about the user’s (or parent agent’s) directive, decompose the directive into tasks, decide which retrieval and processing pipelines are needed for each task, and generate code to implement those pipelines.
- Compute sandboxes provide deterministic compute through a secure code execution runtime. They provide a canvas for models to implement control flow, batching, retries, filtering, joining, aggregation, and other deterministic operations.
- Agentic Search SDK exposes Perplexity’s search stack as composable primitives. It provides building blocks from low-level retrieval operations to high-level semantic parsing. The SDK is embedded within the sandboxes’ execution runtimes, allowing models to orchestrate up to thousands of operations within a single inference turn.
In SaC, not a single retrieval operation is dispatched through a function calling or MCP interface. All operations are instead orchestrated via model-generated Python code. For the simplest search needs, this code may consist of a handful of requests to a high-level search endpoint. But for complex tasks, the code can be as intricate as needed, involving conditional execution, asynchrony, parallelism, and calls to a wide range of low-level primitives.
Case study: CVE vendor advisories
On a 200-CVE research task, SaC scored 100% accuracy with total token usage dropping 85.1% relative to the non-SaC baseline (from 288.7K tokens to 42.9K tokens). The tested non-Perplexity systems all scored lower than 25%.
Evaluation results
SaC outperforms all other systems on four of the five benchmarks evaluated (DeepSearchQA, BrowseComp, Humanity’s Last Exam, WideSearch, and WANDR). On DeepSearchQA, SaC scored 0.871 vs. 0.815 for Anthropic managed agents and 0.733 for OpenAI Responses API. On WANDR, SaC leads the next-best system by a factor of 2.5×.
We’re excited to bring SaC’s capabilities to our users, starting today with Perplexity Computer and Agent API. We will continue to optimize the SaC architecture across all layers of the stack to ensure our users (and the agents serving them) have the most powerful and efficient search capabilities possible.