Summary: Exa introduced Canon, a search pipeline orchestrator that represents retrieval steps as a directed acyclic graph. The structure provides automatic parallelism, durable execution, tracing, caching, and cancellation while keeping nodes simple and observable. The article says DAGs fit explicit, ordered workflows but are not suitable for reactive loops, consensus protocols, or feedback systems.
The Shift: Search Moves from Human Queries to Agent Workloads
Not long ago, a search engine’s design was a settled matter: stand up an inverted index, take in queries, rank the results, send them back. The job changed once customers stopped being people at a keyboard and became thousands of AI agents, each carrying its own language preferences, freshness requirements, and demands about where data may come from.
Exa builds a search engine aimed squarely at AI agents, and it has now written up its answer to this complexity: Canon, a search pipeline orchestrator. The central idea is to lay the pipeline out as a directed acyclic graph (DAG), so that parallelism, observability, and reliability stop being bolted on and instead fall out of the structure itself.
In their blog post, Exa explains that an ordinary-looking search query today unfolds into a graph carrying 20+ node types. One user needs Japanese results, another wants the freshest news, a third needs encyclopedic references. A query may reach the knowledge graph, the product index, the web index — or several of them at once — before passing through classification, localization, and re-ranking. On top of that, most of the pipeline code is now written by AI agents, which are correct in the small but poor at honoring constraints and dependencies that span the whole system. Across billions of requests, imperative code stitched together with manual parallelism turns debugging into a nightmare.
Modeling the Pipeline as a DAG
Exa’s fix is to declare the whole search process as one DAG. A node is an independent unit of work — dense retrieval, sparse retrieval, fusion, content fetching — and edges spell out the data dependencies between them. The runtime finds nodes with nothing left to wait for and runs those in parallel.
By Exa’s account, the design pays off in four concrete ways:
- Automatic Parallelism: Dependencies live in the graph itself, so the runtime already knows which nodes may run together. There is no
Promise.allto write and no thread pool to manage. - Durable Execution: When a node fails, that node alone can be retried; the upstream steps don’t have to run again.
- Introspectability: The DAG is data. It can be visualized, validated, and analyzed without ever opening the source code.
- Decoupled Definition and Execution: One graph definition can run synchronously in tests, spread across machines in production, or serve as a dry-run preview. Caching, retries, and tracing all sit inside the executor, out of the nodes’ sight.
Exa includes a concrete example: a simple pipeline with dense and sparse retrieval, fusion, and content fetching:
{
"nodes": {
"dense": { "type": "retrieve", "index": "web", "numResults": 50 },
"sparse": { "type": "retrieve", "index": "inverted", "numResults": 30 },
"fuse": { "type": "fuse", "method": "rrf", "sources": ["dense", "sparse"], "k": 60 },
"fetch": { "type": "fetch_content", "source": "dense" }
},
"root": { "node": "fetch", "output": "docs", "query": "...", "numResults": 10 }
}Written this way, the dependencies are on the table, and the runtime can parallelize the two retrieval nodes without any extra hints.
Tracing Every Path Through the Pipeline
Before Canon arrived, Exa’s pipeline read as one long run of sequential function calls, if/else branches, and hand-rolled error handling. Bringing in a new reranker meant auditing every conditional that could ever call it. Answering “why did this query return bad results” required manually walking logs backward from the new reranker, checking along the way whether any fallback had fired.
Exa picks a concrete case to show the pain: why, at a given moment, did a given query fail to return a URL that was obviously relevant? In a traditional pipeline, that URL might be filtered out during classification, skipped during localization, demoted during ranking, or clobbered inside a concurrent branch. Chasing down the true cause meant hunting a needle through billions of requests.
Canon’s answer is to compile the search pipeline into a serializable graph. When something breaks, the graph lets you follow each node’s decisions step by step: which subsystem dropped the URL, and why. And because the graph’s structure is spelled out, you can guarantee it matches the actual search path even when customers bring special configurations.
A figure from Exa’s blog shows how many places a URL can fall out along the way: filtering, deduplication, freshness cutoff, domain blocking, content extraction failure, and more. Under Canon, every one of those decisions lands in the graph trace.
How the Runtime Is Designed: Nodes Stay Simple
Canon’s runtime is pull-based: a node executes only when a downstream node asks for its value. The abstraction sounds dry, but the consequences are tangible:
- Lazy Evaluation & Cancellation: The moment a client disconnects or a request times out, the runtime cancels every node still in flight, so compute isn’t wasted.
- Memoization: When two downstream nodes depend on the same upstream node — a diamond dependency — that upstream node runs once, and its output is cached.
- Full Tracing: The runtime stands at every invocation boundary, logging timing, inputs, outputs, and decisions automatically. An error thrown by any node arrives enriched with context: which node failed, and what upstream was doing.
What matters most is that nodes stay oblivious to all of it. A retrieval node only knows how to query its index; a reranker only knows how to score documents. Concurrency, cancellation, caching, tracing — none of it is their job.
Exa stresses the principle behind this: if a node opens its own network call (say, hitting a ranking service directly), the runtime can no longer cancel it, cache it, or trace it. That node has become a black box. Canon therefore requires every node to talk to the runtime through one uniform interface.
Built for Code That Agents Write
Exa names a fact of engineering life in 2026: coding agents now produce most code. What those agents need is structure — enough to be right on the first attempt instead of looping through debug cycles.
In conventional imperative code, correctness hides inside branch structure, execution order, and house conventions, and the implicit invariants pile up:
- Were the contents already fetched?
- Do we have content to rerank?
- Did we handle moderation?
These are exactly the details agents tend to miss.
Canon instead treats the retrieval pipeline as a typed execution graph, turning those hidden assumptions into explicit types and structure. The agent never has to guess when a function should run; it only checks that the graph it emitted is valid against the schema and the type system. The burden of correctness moves out of the agent’s context window and into the type system, the graph schema, and the runtime.
Canon also enforces totality: every node has to account for every outcome it can produce, and the type checker throws out any graph that leaves a branch unhandled. Strict, yes — but it clears out an entire category of runtime surprises.
Where DAGs Don’t Fit
A DAG is not a universal solvent. Exa is explicit that DAG-style orchestration suits these systems poorly:
- Reactive event loops: no scheduled work at all, just state and callbacks.
- Consensus protocols: strict sequential ordering is the whole point.
- Feedback loops: compiler passes that iterate until convergence, for example — a DAG has no way to express cycles.
If your system’s work doesn’t naturally take the shape of a DAG, forcing it in only manufactures accidental complexity. Before adopting the pattern, check that your pipeline really has clear dependencies and a partial ordering.
The Takeaway
Exa’s search will keep getting more complicated: more search types, more customers, more agents. Canon is not a general-purpose framework; it targets systems whose dependencies are explicit, which need parallel execution, and which treat observability as a first-order requirement.
For product builders and AI tool learners, the lasting lesson in Exa’s approach is an attitude toward complexity management: don’t try to make the system simple, because it isn’t — build structures that make complexity visible, traceable, and controllable. Once agents and colleagues can stop guessing how the pipeline behaves, debugging time drops from hours to minutes.
If you’re designing a system that pulls from many data sources to serve many kinds of customers, put one question to yourself: is your pipeline a graph you can draw, or a run of if/else statements whose order lives only in your head?
This piece rewrites Exa’s public blog post “Composing a Search Engine” (April 17, 2026) into fresh prose. Claims and examples tied to the source are attributed above; the practical recommendations are editorial guidance.