orchestration-control

Select the simplest topology that preserves needed control: sequential for dependent stages, parallel fan-out only for independent work with explicit join artifacts, supervisor for centralized assignment, and coordinator-specialist when both central control and local specialization matter.

Use orchestration only when it provides material gains in quality, latency, fault isolation, reuse, or controllability. If a single coherent agent path is sufficient, collapse back to the simpler route to avoid coordination overhead.

Preserve explicit states such as created, accepted, running, blocked, partial, complete, and failed. Choose sync, polling, streaming, or push modes, bound polling frequency and duration, and never present dispatched work as completed.

An agent card or capability manifest describes a candidate agent's identity, capabilities, version compatibility, trust boundary, and supported interaction modes. Evaluate task fitness and trust boundaries directly rather than selecting agents by label alone.

Integration fails when outputs are merged before lifecycle or trust checks, join conditions are undefined, or partial states are hidden. Define join artifacts and validation owners upfront, and keep unresolved disagreements visible in the final synthesis.

Avoid decorative orchestration, dispatch-and-forget delegation, role inflation without distinct responsibility, polling without stop conditions, and integrating outputs before lifecycle verification. Reduce topology when coordination cost exceeds decision value.