The model gets the attention. The router decides which model gets the request.
Before an answer appears, the system has already chosen a context source, a model shape, a tool set, a permission boundary, and sometimes a fallback path. Those decisions are quiet. They also shape most of what the user experiences.
The first route is usually context. Which source of truth is allowed here: public docs, private account data, source code, terminal output, incident notes, an index, or some combination? A support assistant should not search the codebase because the question contains a noun. A coding agent should not pull incident notes into a build-failure task. Sometimes missing context is safer than guessed context.
The prototype path is familiar:
take prompt
retrieve a few chunks
send everything to the strongest model
stream the answer
That is fine for learning. It is a poor permanent architecture. Traffic includes extraction, classification, search, synthesis, tool planning, private work, low-latency work, and requests that should stop instead of generating an answer.
Model choice should follow task shape. A small model may be right for classification. A local model may be required for private notes. A large model may earn its cost on messy synthesis. A specialized retrieval model may matter more than the generator if the real failure is source selection.
Tools belong in the route too. The same model can handle a read-only file inspection and a reviewed write, but those requests should not inherit the same permissions.
request: summarize failing test output
context: terminal log and related source files
model: low-latency coding model
tools: read-only filesystem
blocked: shell execution, network, external tracker
When routing is invisible, every failure gets blamed on model quality. A trace should show chosen context, model, tools, policy decision, fallback, and the request shape the router inferred.
The AI systems I trust know when a hard problem needs a stronger route and when an easy problem only needs the right room.
Related posts

About Jeremy London
Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.