Why orchestration is its own layer
In most AI products the model call is the easy part. The hard part is deciding what should run, in what order, with which permissions, and what to do when a step fails. We keep that decision-making in a dedicated orchestration layer rather than scattering it across UI components or individual agents.
The practical benefit is replaceability: a model, a tool or an agent can change without rewriting the product. The orchestration contract stays stable.
What the orchestrator is responsible for
Interpreting the request, selecting the agent or workflow, enforcing policy and permissions before any tool executes, deciding when a human approval step is required, and recording the trace of what happened.
It is deliberately not responsible for domain logic. Domain logic belongs to the agent or the service the agent calls.
Failure handling is part of the design
Every orchestrated step declares what happens on timeout, refusal or malformed output. A step with no defined fallback is treated as an incomplete design, not a runtime surprise.
Cost control lives at the same boundary: budgets and step limits are enforced by the orchestrator, so a runaway loop is bounded by design rather than by monitoring alerts.