Workflow Topology
Pattern 05 of 9
Input Router
Classify the input once, then route it to the right specialized handler.
The input router pattern classifies an incoming request and dispatches it to one of several specialized handlers. The classifier runs first and produces a routing decision. That decision determines which downstream prompt, model, or pipeline handles the request. The classifier and the handlers are separate. No single model has to be good at everything. The router is making a binary or categorical decision; the handler is doing the actual work.
Why it matters
General-purpose prompts that try to handle every input type produce mediocre results across the board. Specialized prompts that handle one input type well produce much better results for that type. The router lets you get the benefits of specialization without requiring callers to know which handler to invoke. You can add handlers over time without changing the interface. It also makes cost optimization straightforward: route cheap inputs to cheaper models, expensive inputs to the more capable ones.
Deep Dive
The classifier is the critical component. If it misroutes an input, the wrong handler runs and the output will be wrong regardless of how good the handler is. Classifier design deserves at least as much attention as handler design. For simple categorical routing, a small fast model is usually good enough. For nuanced routing where the right handler depends on subtle signals in the input, you may need a larger model or a few-shot classifier with carefully curated examples. Testing your classifier in isolation, before you wire up the handlers, will save you debugging time later.
Routing logic does not have to be purely LLM-based. Hybrid routers that combine keyword matching, regex, or lightweight classifiers with an LLM fallback are often faster and cheaper than pure LLM routing. A support ticket router might route anything containing the word "refund" directly to the billing handler before involving a model at all. This kind of rule-based pre-filtering removes obvious cases cheaply and lets the LLM focus on the ambiguous ones. The rules are also more debuggable than model decisions, which matters when something goes wrong.
One thing to watch for is routing drift over time. As you add new handlers, the router's training data or few-shot examples may no longer cover the full input space well. A router that worked fine with three handlers can start making mistakes when you add a fourth. When you add a handler, re-evaluate the classifier against a representative sample of recent inputs. This is operational maintenance, not a one-time build step. Routers that are never re-evaluated tend to accumulate silent misrouting errors that show up as user complaints rather than as explicit errors.