Orchestration

Orchestration is the control layer that coordinates deterministic steps, adaptive agent plans, tools, state, and terminal outcomes. A plan may change as evidence arrives, but orchestration must not let that plan expand its identities, permissions, budgets, or approved action boundary.

What it controls

The exact controls depend on the work and its risk. Common examples include retry and cost budgets, deadlines, idempotency, risk-based expert review, fallbacks, pause or shutdown paths, and the evidence an operator needs to understand a run. These controls belong in inspectable system logic rather than being left to a model to infer.

Internal coordination and external interoperability

Orchestration does not require one transport. A single process may use direct calls; a distributed workflow may use a durable event log or task queue to make replay, backlog, and ordering observable. That internal layer is not A2A. An A2A adapter belongs at the boundary where this system exchanges tasks and artifacts with an independently operated agent system.

What it is not

Orchestration should keep workflow state, deadlines, approval rules, retry budgets, and terminal outcomes outside model reasoning. Whether model calls or data adapters run in the same process is an implementation choice; their permissions and evidence still remain explicit.