Search as Code

Over the past couple of years, nearly every company in search has announced some version of the same story: Agentic search, Deep Research, MCP servers, research agents.

On the surface, they look like competing products with different interfaces, benchmarks, and marketing. The naming hides something fundamental: this is not merely a product race but an architectural transition. This essay argues that as search becomes programmable, whoever controls the orchestration loop will capture the most value.

Beneath the announcements, the architecture of search is quietly changing. Search is no longer evolving as a destination that humans visit. It is becoming a capability that software composes.

It changes how search is built, where value accumulates, and who controls the flow of information. More importantly, it explains why companies that appear to be competing are, in many cases, converging toward the same underlying design.

Like many technologies before it, search appears to be evolving from an application into infrastructure. This may shape the next decade of AI systems.

The Oscillation

Search has repeatedly shifted between two poles: a destination for humans and a primitive developers leverage. Google popularized the destination model where users get a search box. Lucene made search embeddable, and managed platforms (Elasticsearch, hosted services) reduced operational burden while preserving developer flexibility.

Each shift did not displace the previous model. In fact it added a new class of consumer. The current shift is the same: software is becoming a consumer of search for the first time.

The obvious question is: what kind of primitive is search becoming?

Unix / Grep: a useful but limited analogy

Unix tools (grep, sort, awk) are programs that do one thing well. Their power comes from being simple, composable primitives that can be chained together to solve increasingly complex problems. Search is seeing a similar transition. Whether it succeeds may hinge on whether search primitives can be chained together, just like Unix and grep.

Look at some of the primitives:

• search(query, limit) -> List[Document]
• rerank(query, docs) -> List[Document]
• extract(text, schema) -> Object
• fetch_url(url) -> string

Agents compose these functions in code. State lives in the runtime; primitives remain conceptually stateless.

For most of the web's history, search was treated as a complete interaction. A user asked a question, a search engine returned results, and the interaction ended. The search box owned the loop.

Agents are breaking that assumption. An agent rarely performs a single search. It searches, reformulates the query, retrieves documentation, extracts specific passages, verifies facts, follows citations, compares sources, and searches again. Retrieval is no longer a destination; it is one step in a much larger program.

That changes what search needs to be. Instead of exposing a single interface, search increasingly exposes small, composable capabilities: retrieve documents, rerank results, extract entities, follow links, fetch structured data, summarize evidence. Together, these form the building blocks of an entirely different way of using search.

This is why so many AI-native systems look surprisingly similar beneath the surface. Whether you are watching a coding assistant trace a codebase, a research agent synthesize information, or an enterprise agent answer questions across internal documents, they are all composing the same retrieval primitives into different workflows.

The shift is from interaction to composition.

Where does the loop live

As search becomes programmable, the question shifts: who owns the program that composes it?

Every agent plans, searches, evaluates the results, decides what to do next, and repeats until it has enough information to act. This is the loop that is becoming the new unit of competition.

Three broad architectures are emerging here.

The first places the loop inside the agent. Search providers expose retrieval primitives, but orchestration lives with the application. The agent decides when to search, how to refine queries, which sources to trust, and when to stop. Search becomes an interchangeable component inside a larger reasoning system.

The second moves the loop into the search platform itself. The platform offers higher-level workflows: deep research, multi-step retrieval, citation management, planning, and synthesis. Developers outsource not just search, but the orchestration around it.

The third is beginning to emerge as a hybrid. The search platform owns parts of the retrieval loop, while the application retains control over planning, memory, and user experience. Rather than replacing each other, the agent and the search platform negotiate responsibility.

A good example is Perplexity's POV below:

agent LLM context
        |
        | writes Python / TypeScript
        v
sandboxed runtime  <-- state lives here
        |
        | primitives as functions
        v
search | extract | rerank | filter

This changes where control lives and everything that follows: latency, cost, observability, trust. Past experience tells us the service that wins is the one that co-ordinates many capabilities together.

Market follows architecture

Markets often recognize and reward architectural shifts before the rest of us do.

In search we can see companies such as Parallel and Exa building programmable retrieval infrastructure. Their products are not measured by clicks or queries, but by how well they fit into larger software systems. Pricing shifts from searches to workflows. Integration matters as much as relevance.

Perhaps the strongest signal is capital allocation and developer attention. Investment is happening around companies building retrieval infrastructure, agent runtimes, and developer platforms rather than standalone search experiences.

The market is behaving as though search has already crossed the boundary from application to infrastructure. The decisive advantage then will not be the best retrieval model but the control plane that composes, governs, and scales it.

Winning Pattern

Search is today's example. It will not be the last. We keep seeing this pattern: a capability becomes programmable. Programmable capabilities become infrastructure. Infrastructure creates new control planes.

Competition shifts from delivering the capability to orchestrating it. Whoever controls the orchestration loop will capture the most value.

References

• Perplexity Research — "Search as Code" (Jun 1, 2026): research.perplexity.ai
• Cloudflare — "Code Mode for MCP" (Feb 20, 2026): blog.cloudflare.com
• Anthropic — "Code Execution with MCP" (Nov 4, 2025): anthropic.com
• Hornet — "Code mode for agentic retrieval" (Jun 2026): hornet.dev
• Parallel — Pricing and product (2026): parallel.ai
• Exa — Pricing and product (2026): exa.ai