Define and measure
Name the outcome, inputs, stakeholder, failure impact, representative examples, and success metrics before architecture.
Start with the problem, not the architecture. Answer a few questions to find the lowest-complexity system that can do the work reliably.
Explore the complete decision tree and design guideFor the same input, could code follow the same rules and produce the correct output every time?
The recommendation chooses an implementation family. Reliability comes from the design loop around it.
Name the outcome, inputs, stakeholder, failure impact, representative examples, and success metrics before architecture.
Give each part an input, output, trigger, required context, failure mode, and verification method.
Connect parts as a chain, DAG, parallel fan-out, or runtime loop. Define schemas, retries, timeouts, and ownership.
Measure quality, cost, latency, safety, and recovery. Improve the weakest step at the lowest useful complexity.
If you already know the available categories and what each one should trigger, return a constrained label or schema from the model and handle the next step in code.
This keeps agent descriptions out of the prompt, reduces ambiguity and token cost, and makes routing easier to test. Reserve an orchestrator for the genuinely unknown or exceptional path.