@yibie: Search as Code: The Next Paradigm Shift in Search Architecture Perplexity just released a new architecture called Search as Code (SaC). Sounds like another marketing term, but after reading their research paper, I think this might be one of the most important architectural decisions in the AI infrastructure space for 2026.

Search as Code: The Next Paradigm Shift in Search Architecture Perplexity just released a new architecture called Search as Code (SaC). Sounds like another marketing term, but after reading their research paper, I think this might be one of the most important architectural decisions in the AI infrastructure space for 2026. The core idea in one sentence: AI agents no longer call search APIs one by one via function calling; instead, they directly write Python code to orchestrate the entire search pipeline. ## 1. The Problem: Function Calling Is a "Serial Bottleneck" The traditional AI search architecture works like this: Model issues query → Search engine runs preset pipeline → Returns results → Model consumes results ↑_______________________________________________↓ Each search operation = one LLM inference round trip This architecture was sufficient in the era of "user asks a question, AI searches once". But when agents need to complete complex tasks involving hundreds of retrievals, the problems become exposed. In Perplexity's Computer product, a single task can trigger hundreds or even thousands of retrieval operations within minutes. Each operation requires an LLM round trip — that is the "serial bottleneck". More specifically, the traditional architecture has three fatal flaws: - **Coarse-grained context.** If the model needs only one highly precise piece of information but can only use a "high-recall" search endpoint, the result is a large amount of irrelevant data being stuffed into the context window, wasting tokens and diluting signal. - **Inability to leverage domain knowledge.** The model may know how to search in its training data, Agent Skills, and memory — for example, when to mix lexical and semantic signals, which sources to prioritize, and how to aggregate results. But traditional search APIs only expose query parameters, and the model cannot put that knowledge into action. - **Inefficient control flow + context pollution.** Many search workflows are not linear — they require fan-out, parallelism, and deduplication. Implementing these with serial function calls is not only slow, but also dumps a lot of intermediate state into the model context, causing performance degradation and necessitating frequent compaction. ## 2. SaC's Solution: Code Instead of Function Calls Perplexity's approach is to completely abandon function calling and MCP as the search interface. Instead of improving the existing approach, they switched to an entirely different paradigm: Model writes Python code → Sandbox executes → Code directly calls atomic primitives of Agentic Search SDK ↓ One LLM inference can orchestrate thousands of search operations **Three-layer architecture:** - **Model Layer (Control Plane):** Reasons about user requests, decomposes tasks, decides what retrieval strategy is needed, and generates Python code to implement those strategies. - **Compute Sandbox (Execution Layer):** Provides a secure code execution environment, handling deterministic operations like control flow, batch processing, retries, filtering, aggregation, etc. - **Agentic Search SDK (Primitive Layer):** Decomposes Perplexity's search stack into composable atomic primitives — retrieval, ranking, filtering, fan-out, rendering, etc. Not wrapping a search API into a library, but re-architecting the entire search system as modular components. **Key difference:** In SaC, the model does not call search. The model orchestrates search. ## 3. One Example Is Enough: CVE Vulnerability Analysis Perplexity gives a concrete example in the article. Task: Find over 200 high-risk CVEs from 2023-2025, each requiring a citation from the vendor's own security advisory, including affected products, fix versions, and evidence that the fix version relates to the specific CVE. **SaC results:** - 100% accuracy - Token consumption dropped from 288.7K to 42.9K — an 85.1% reduction - All other tested systems (OpenAI, Anthropic, Exa, etc.) scored below 25% accuracy Why such a big difference? Because SaC allows the model to do three things that traditional architectures cannot: - **Write rules into the query plan.** The generated code directly encodes the constraint "only look at vendor advisories" — NVD, MITRE, third-party aggregators are structurally excluded from searches. - **Use LLM for intermediate planning.** The code first summarizes which vendor-year combinations produce enough candidate pages, requests targeted query optimization, and then validates each query before execution. This is not a hardcoded crawler; it's an agent defining search strategies at runtime through code. - **Use code for result validation.** The search subroutines find seemingly relevant pages, but the task requires "the vendor's original text must bind a CVE, an affected product, and a fix version". The code explicitly defines this schema, automatically deduplicates, rejects aggregator URLs, discards weak version evidence, and continues until the record count is met. ## 4. Benchmarks: 2.5x Advantage Perplexity compared SaC (using GPT 5.5 high reasoning) against OpenAI Responses API, Anthropic Managed Agents, Exa Agent, and Parallel Tasks on 5 benchmarks. SaC won 4 out of 5 benchmarks. On the hardest WANDR benchmark (simulating "broad research" professional tasks), SaC's score was 2.5x that of the runner-up. The cost-performance frontier chart is more intuitive: SaC's low reasoning setting is cheaper than all non-SaC systems while matching their performance; its medium reasoning setting outperforms all competitors at under $1 per task. ## 5. Three Deeper Insights ### 1. "Code as Orchestrator + Capability Filler" SaC doesn't just use code to call existing capabilities. When the search stack or SDK lacks a native function for some capability, the model can dynamically implement it in the sandbox. For example, a complex regex — if no native support exists, the traditional approach is to send a similar query and filter noisy results in token space. SaC's approach is to call the SDK in parallel to collect a superset, deduplicate with code, then write additional Python for precise filtering. Code simultaneously plays the role of "orchestrating existing capabilities" and "creating missing capabilities". ### 2. SDK Self-evolution via Autoresearch Perplexity did not manually design the SDK. They built an autoresearch loop that ran continuously for weeks, automatically proposing and validating SDK improvements — measuring latency, code generation quality, and task completion rate. This loop has made significant modifications to the SDK's structure and aesthetics, achieving substantial gains across all dimensions. This is a key signal at the meta level: the tools for building AI primitives themselves need to be AI-native. ### 3. Lean Design of Agent Skills Teaching the model to use a custom SDK is a challenge — the SDK is not in the pre-training data. Perplexity's solution is carefully tuned Agent Skills, with a root file under 2000 tokens. The focus is not on listing all functions (the model can get them via runtime reflection), but on providing concise, generalizable guidelines and a few examples that teach the model how to compose these atomic primitives. ## 6. What This Means Search as Code is the concrete implementation of the larger paradigm "code as orchestrator" in the search domain. We discussed in a previous article how Claude Code dynamic workflows use JS to orchestrate sub-agents; today SaC demonstrates how the same principle applies to search infrastructure. **Common pattern:** | Old Paradigm | New Paradigm | |--------------|--------------| | Serial function calls | Parallel code orchestration | | Preset pipeline | Runtime assembly | | LLM calls API | LLM writes code to call primitives | | Context bloat | Intermediate state stays in sandbox | | Human-designed interfaces | Autoresearch evolves interfaces | Every dimension points to the same direction: The next step for AI agents is not better function calling, but eliminating function calling altogether. **Reference:** Perplexity Research, "Rethinking Search for Agents: Search as Code" (June 2026) Benchmark data: DSQA, BrowseComp, HLE, WideSearch, WANDR Word count: ~2800 words