1 · State your intent
2 · Orchestration log
🧭Intent parsing
The first stage turns fuzzy language into structure. A classifier (often a small, fast LLM) maps “build me a website” to something like intent: create.web_app with extracted slots — audience, style, constraints. If confidence is low, good systems ask one clarifying question rather than guessing. This is the modern descendant of intent+slot NLU from voice assistants — just with LLMs doing the parsing.
🔀Model routing
Not every request deserves the biggest model. A router scores each request on difficulty, needed capabilities, latency and budget, then dispatches: translation → a fast cheap model; a research synthesis → a long-context model; data analysis → a reasoning model with code execution. Production routers can cut cost dramatically while keeping quality — you pay for the powerful model only when the request needs it.
🧰Capability & tool matching
Models alone can't ship results. The orchestrator matches the parsed intent to tools via function-calling schemas: a code generator and live preview for the website; a document parser and retrieval index for the research summary; a sandboxed Python runtime for the dataset. The model decides when to call each tool; the orchestration layer decides which tools exist and enforces permissions.
⚖️The honest tradeoffs
Intent UX trades control for simplicity. Experts lose precision (maybe you wanted that specific model or temperature); debugging is harder when routing is invisible; and cost-based routing has an incentive problem — the vendor profits when the router picks the cheap model. Good intent systems stay inspectable (show what was routed and why) and overridable (a power-user escape hatch) — exactly what the log panel here simulates.