When the LLM Is No Longer the First Step: Deterministic Routing for AI Agents

Published on August 31, 2026.

This is not the story of a system that removes LLMs. It is the story of a system that moves the LLM to the only place where it truly matters. A deterministic layer placed before the model resolves a known set of requests directly — and the measured proof reduces to two numbers: LLM_CALLS = 0 on the direct path, and a clean hand-off to reasoning when the request is unknown.

The problem: a decision left to the LLM

In a classic MCP server, the client calls tools/call with the name of the tool. But who picks that name? In the original Tour architecture (« tour_webmcp »), the choice belonged to an LLM: the model decided, among nine tools, which one answered the request. Yet several of those tools were already deterministic — read the map, report status, list projects or reminders, run a circuit.

The gap. The deterministic capabilities existed. The deterministic decision did not: it was handed to a model — reasoning, cost, latency, and randomness — for an action that has nothing speculative about it.

The result is an architecture where the LLM is the first reflex for everything, including what is perfectly known in advance. That is neither economy (every call costs), nor reliability (model randomness decides something that could be a rule), nor necessity.

The solution: a deterministic front-door

We placed a model-free routing layer between the incoming request and the tools: a front-door. It applies rules, in order, on a canonical form of the request (case and accents preserved), and produces an observable contract:

MATCH   -> {"decision": "MATCH",   "tool": "statut_tour",
          "llm_required": false, "matched": "statut tour"}
NO_MATCH-> {"decision": "NO_MATCH", "llm_required": true}

On a MATCH, the real tool is called and the built result is returned. On a NO_MATCH, nothing deterministic is forced and no answer is invented: the front-door hands control to the LLM — explicitly.

What we measured

These values come from a run on an isolated test database, tour_prod untouched.

ItemResult
Test suite18 — 0 failed, 0 error
WebMCP tests counted22
Real deterministic requeststatut tour
RoutingMATCH
Selected toolstatut_tour
LLM calls on this path0
Unknown requestNO_MATCH -> LLM hand-off
Authentication without keyHTTP 401
Transport proofcurl + HttpCase (real HTTP server)
Test databaseisolated (fresh) — production intact

Observability is itself measurable: each front-door pass writes a log line with request_id, decision, tool and llm_required. On the deterministic path, the log contains no model-call line — that is the LLM_CALLS = 0 proof.

The two paths, proven

Direct path. request -> front-door -> MATCH -> real tool -> real result. LLM_CALLS = 0.

Fallback path. request -> front-door -> NO_MATCH -> LLM. Reasoning is not removed: it is reserved for cases that actually need it.

The crucial distinction between idea (put determinism before the LLM), implementation (the front-door), and proof (both paths measured) is what separates an intuition from a result.

The LLM's role does not disappear. It changes position.

Before: request -> LLM -> decision -> tool. After: request -> deterministic -> known capability -> execution, -> unknown -> LLM.

With WebMCP, this is a control tower: the front-door is the switch, with "eyes and hands outward", letting the Tour reach capabilities exposed by other applications — without paying model reasoning for a known gesture.

Limits — and what remains to validate

What really changes

Presenting this as "we removed the LLMs" would be false — and, more importantly, it would be less interesting. The lesson is that an agentic architecture can make its first reflex deterministic and bend its cost accordingly, while keeping reasoning as a safety net. The model becomes a resource called on demand, not a wall in the middle of everything.

🔭