Routes, Not Retrieval

In Short

Most enterprise agents are built on retrieval: search an index of documents, tickets and threads, and pull the closest matches into the prompt. This pattern is called retrieval-augmented generation, or RAG.
Retrieval is tuned for recall, the share of all the relevant records a search actually finds. To avoid missing anything, systems pull in more. Precision, the share of what they pull in that actually matters, drops.
Memory, letting an agent keep facts and past conversations across sessions, is a useful addition. But retrieval and memory both hand the agent facts.
Work inside a company is rarely a question about what’s written down. It’s about what happens next.
Routing gives an agent the next step and the context behind it, learned from how work has actually moved through the company.
The payoff is fewer tool calls, smaller prompts, agents placed where they help, and agents that improve with a person approving each change.

Two Agents, One Access Request

An employee asks for access to a sensitive Snowflake dataset. Two agents pick up the request. Same model. Same tools. The numbers here are an example, not a measurement.

The first agent runs on retrieval. It searches its index and comes back with twenty old access tickets, a wiki page last edited in 2023, and a Slack thread where someone once wrote “just add them to the group.” It makes six tool calls to check group membership, ticket history and the wiki. Then it grants access.

The reasoning looks fine. The outcome is wrong. This dataset needs the data owner’s sign-off first.

The second agent runs on routing. It asks one question: given this request, what happens next? One call, one short answer. Ask the data owner for sign-off. In this example that usually takes about four hours. Grant read-only access once it’s approved. Requests that skip the approval are the ones most often reversed later. And the answer says how confident it is.

The first agent had every fact it needed. It didn’t have the route.

More Retrieval Is Not the Fix

When an agent gets it wrong, the reflex is to retrieve more. Search teams judge that with two numbers. Recall asks: of everything relevant, how much did we find? Precision asks: of everything we returned, how much was relevant? Missing a record feels worse than reading an extra one, so teams push for recall. They return more results per search (the “top-k”, where k is how many come back), widen the query and pack the prompt. Recall goes up. Precision usually goes down.

Fig. 1Retrieval. Each dot is a document, ticket or thread, placed by similarity. Widening the search finds more of the relevant records (higher recall), but most of what it pulls in is noise (lower precision), and one record is still missed.

At work, that trade breaks in three ways.

The pile is noisy. Old tickets reflect old rules. Wikis drift. Slack threads preserve shortcuts no one would approve today. Lower precision means more ways to be confidently wrong.

The pile is expensive. Every extra result, document and check is another tool call and a longer prompt. Across thousands of requests a day, that becomes a budget line.

The pile has no order. A process is a sequence: request, approval, grant, review. Search ranks results by how similar they look to the request, whether it matches keywords or embeddings (numeric fingerprints of meaning that place similar text close together). Neither knows what comes next. So the agent rebuilds the process on every request, and sometimes rebuilds it wrong.

Memory Helps. It Isn’t a Route.

The usual next fix is memory: let the agent keep facts and past conversations from one session to the next, so it doesn’t search cold every time. That is a real improvement. It cuts repeat lookups and keeps an agent consistent. But memory stores facts and past interactions, not the order work moves in, or what goes wrong when a step is skipped.

An Atlas Versus Directions

Drivers used to plan trips with a road atlas. Getting anywhere still meant studying pages and guessing at turns. Turn-by-turn directions didn’t add more roads. They told you the next turn, and they rerouted when traffic changed.

Retrieval hands agents the atlas. Memory lets them remember trips they’ve taken. Routing gives them directions.

Fig. 2Routing. The same records, but the agent gets one ordered path learned from how past requests moved: sign-off, then a read-only grant, then review. The shortcut that skips sign-off is the one that tends to get reversed. Illustrative, not measured.

To do that, we build a model of how work actually flows in a company, learned from the record its people and agents leave as they work: who handled each request, in what order, what was approved and what was later reversed. Knowing what usually happens next, and what goes wrong when a step is skipped, is what lets an agent act.

Fig. 3How routes are learned. Each trail of dots is one past request. Over months they wear into a few well-used paths, and the detours stand out. Illustrative, not measured.

That changes the objective. Retrieval is judged on coverage: did it find everything that might matter? Routing is judged on the decision: was the next step right?

Three Things Routing Changes

1. Cheaper, sharper agents. When the next step and its context arrive together, agents stop exploring. Fewer tool calls, fewer paid calls to outside services and smaller prompts. At scale, that is real money back to the organization, and agents that act instead of guessing.

2. Agents where the work actually piles up. Today, where an agent goes is decided by a hunch or the org chart. The same model that routes a request also shows where work waits, loops and gets handed back. You place agents around the process, service or handoff where the evidence says they’ll help, not where someone guessed.

3. Agents that improve themselves. Every routed decision produces an outcome, and every outcome flows back into the model. Routes that work get stronger. Routes that fail get flagged. Agents get better without someone rewriting their instructions every quarter, and a person still approves each change before it ships.

How We Measure It

A claim like this should be tested, not asserted. We’re adapting EnterpriseBench, a public research benchmark that simulates a company with synthetic HR, IT, engineering and sales data, role-based access rules and realistic tasks. For every request, we plan to report:

Recall and precision of the people, services and records the agent finds, against what the request actually needs.
Next-step accuracy: whether the agent picks the right next step.
Tool calls: how many it makes to get there.

We run routing and retrieval side by side, on the same requests, with the same model and the same tools. This work is in progress, and these are the measures we plan to use, not results. When we publish, the numbers will come with their data and their failures, including the cases where retrieval wins.

Three Questions Before Your Next Agent Ships

Before an agent touches a real workflow, ask three questions:

Does it know what comes next? Ask what the agent would do on a request that needs an approval it has never seen in a document.
How much does it pull in to get there? Count the tool calls on a routine request, and how much of what it retrieved was actually relevant. Then count again when your data doubles.
Who signs off when it changes? An agent that improves itself should still have a person approving what ships.

The Self-Driving Enterprise

Retrieval chases recall. Routing chases the right next step.

Follow that far enough and you get the self-driving enterprise: a company that understands how it runs, sends each decision down the right path and keeps getting better, with people supervising the route instead of taking every turn by hand.

We’re not there yet. But nobody went back to the atlas once directions worked. Stop handing agents every road. Start handing them the next turn.

The longer argument for a working model of your organization is in the memo. Read the memo