The way AI agents interact with search has not fundamentally changed in years. A model fires a query, a search engine runs its fixed pipeline, the model reads the results. Repeat until done. It's serial, slow, and increasingly mismatched with what modern agents actually need.
Search is the primary way AI systems tap into real-world knowledge, but traditional search pipelines are increasingly outdated in the era of agents. Traditional search answers queries; today's agents complete tasks that can take on countless shapes. Perplexity is now taking a direct swing at that problem.
Perplexity is introducing Search as Code (SaC) as its new reference search architecture. It writes Python that calls the search stack directly, instead of looping through function calls one at a time. It's available in the Perplexity Agent API and is now default in Computer.
The Problem with Monolithic Search
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.
But agent workloads are different in kind, not just in scale. Within Perplexity Computer, single tasks have been seen invoking hundreds or even thousands of retrieval operations within a few minutes, a workflow that is impossible for humans but absolutely natural for agents. Forcing that volume through a sequential tool-calling loop creates latency, inflates token usage, and caps what agents can realistically accomplish.
These tasks require agents to define task-specific retrieval strategies directly within their harnesses. A fixed pipeline cannot do that. Code can.
How Search as Code Works
The core idea is to 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.
The three-layer architecture behind SaC breaks down like this:
- Models as the control plane. Models reason about the user's directive, decompose it into tasks, decide which retrieval and processing pipelines are needed for each task, and generate code to implement those pipelines.
- Compute sandboxes as deterministic runtime. Compute sandboxes provide deterministic compute through a secure code execution runtime, giving models a canvas to implement control flow, batching, retries, filtering, joining, aggregation, and other deterministic operations.
- The Agentic Search SDK as the I/O layer. The Agentic Search SDK exposes Perplexity's search stack as composable primitives. Importantly, this SDK is not a preexisting search API packaged as a library. Over the past few months, the engineering team has rearchitected the search stack into modular, composable primitives.
All operations are 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.
Key Technical Highlights
Denis Yarats from Perplexity described the design intent clearly: "codegen is the most natural way for an LLM to drive search: the research tasks our users need require complex pipelines, customized per task. So we're exposing the search stack as composable low-level primitives in an SDK. For example, from model-generated Python you can build custom ranking pipelines, run large-scale wide/grid search, and do map-reduce directly over the search index."
A few things stand out technically:
- Single-turn execution. Codegen pipelines things together and collapses many agent steps into a single program, resulting in far fewer round trips.
- Code as a capability filler. Agents benefit from parsimony, and it would be inefficient for the SDK to cover every potential operation with a dedicated function. Instead, the SDK provides the most fundamental primitives, and the model can build any additional components on the fly with code.
- Parallel execution over the index. With SaC, the model can generate a program that makes parallel SDK calls to collect a superset of a desired resultset, rather than approximating through serial queries.
- Python as the runtime. Perplexity considered Python, Rust, TypeScript, and Bash as the SDK runtime, and suspected that Python would be the most natural fit given its ubiquity and ecosystem of data processing libraries.
Why This Architecture Holds Together
Without intelligent models, the system cannot reason over search strategy. Without sandboxes, models are forced into serial I/O and inefficient token-space processing. Without an atomized search stack, the model has nothing to orchestrate. SaC works because reasoning, deterministic compute, and I/O are jointly designed to accentuate each layer's strengths.
There's also a forward-looking angle here. This codesign can be taken further through continual improvement loops. The Agentic Search SDK and SaC Agent Skills could be jointly optimized in a common autoresearch loop, and more ambitiously, models can be trained to take advantage of low-level search primitives exposed as an SDK.
High-level pipelines aren't removed either. High-level, end-to-end search pipelines are still available within the SDK, but they are no longer the only option. Rather, they serve as a form of shorthand for common search patterns. The model is free to use or bypass them as the task demands.
Where SaC Is Available Now
SaC writes Python that calls the search stack directly instead of looping through function calls one at a time, and is available in the Perplexity Agent API and now default in Computer.
The Agent API itself is a broader platform. It's a multi-provider, interoperable API specification for building LLM applications, offering access to models from multiple providers with integrated real-time web search, tool configuration, reasoning control, and token budgets through one unified interface. It provides access to OpenAI, Anthropic, Google, xAI, and more through one unified API, without the need to manage multiple API keys.
The underlying search infrastructure behind SaC is not lightweight. The Search API indexes 200 billion URLs with tens of thousands of index updates per second. Returning the right content in the right amount directly determines downstream answer accuracy and token efficiency.
For Perplexity Computer, SaC is now the default. Computer bundles Search, Research, and Labs into something closer to an AI-powered operating system than a search box. Give it a task and it breaks that task into subtasks, spawns sub-agents to handle each one, and coordinates everything automatically. SaC is what powers the retrieval layer underneath all of that.
The broader Perplexity team has been direct about the goal. "We want to relieve developers of the plumbing that is required to build agents," says James Liounis, member of technical staff at Perplexity. "We want them to be able to access the best search possible; the same search that powers our core. We want them to be able to essentially build an agent while focusing on what really matters — the capabilities of the agent."
Final Thoughts
What Perplexity is doing with Search as Code is architecturally interesting because it inverts the usual assumption. Most search integrations treat the search engine as an external black box the agent calls into. SaC treats the search stack as a programmable substrate the agent codes against. That's a meaningfully different mental model, and it opens up patterns like parallel grid search and map-reduce over a live index that simply don't fit the tool-call loop paradigm.
The piece I'd watch most closely is the training angle. Models can be trained to take advantage of low-level search primitives exposed as an SDK, which implies Perplexity could eventually ship models that are natively fluent in their own search SDK, the way code models are fluent in Python standard library calls. That feedback loop, if it closes properly, could produce a compounding advantage that's hard to replicate from the outside.
For now, SaC is available in the Agent API and live as the default in Computer. If you're building agents that do serious retrieval work, it's worth reading the full research post to understand what the SDK actually exposes. What do you think of this approach? Drop your thoughts in the comments.
Frequently Asked Questions
5 questions
1What is Search as Code (SaC)?
Search as Code is Perplexity's new search architecture for AI agents. Instead of calling search through sequential function calls, a model generates Python code that calls Perplexity's search stack directly, enabling parallel, conditional, and complex retrieval pipelines in a single turn.
