Agent Orchestration
Agent orchestration is execution control over state, authority, failure, and human intervention—not model chaining.
Design task decomposition, tool contracts, state, approvals, retries, and compensating transactions as an observable graph.
§ 01
The operating conditions that justify Agent Orchestration
More autonomy can hide intermediate state and responsibility, propagating small errors across tools.
Retries and duplicate execution can repeat irreversible changes in external systems.
- Long-running work crosses tools and systems and needs intermediate validation
- Human and agent approval, handoff, and recovery responsibilities must be explicit
- A deterministic workflow is simpler and safer
- Tool idempotency, authority, and error contracts are undefined
Agent Orchestration: system plate
System 1
Decompose work into minimal execution units with state transitions and acceptance conditions.
System 2
Fix input, output, authority, idempotency, and compensation per tool as an execution contract.
System 3
Place autonomous, human-review, and stop boundaries according to risk and uncertainty.
System 4
Link state, decisions, and tool results with correlation IDs to validate replay and recovery.
- N1 N2context
- N2 N3decision
- N3 N4evidence
- The workflow begins with Decompose work into minimal execution units with state transitions and acceptance conditions..
- It reaches an acceptance decision through Per-stage success and stop correctness.
§ 03
Fix the boundary and acceptance criteria before implementation.
Agent orchestration is execution control over state, authority, failure, and human intervention—not model chaining.
- 01
Stage 1
Decompose work into minimal execution units with state transitions and acceptance conditions.
Review artifact 1 - 02
Stage 2
Fix input, output, authority, idempotency, and compensation per tool as an execution contract.
Review artifact 2 - 03
Stage 3
Place autonomous, human-review, and stop boundaries according to risk and uncertainty.
Review artifact 3 - 04
Stage 4
Link state, decisions, and tool results with correlation IDs to validate replay and recovery.
Review artifact 4
§ 04
Hypothetical workloads make the applicability boundary concrete.
Long-running work crosses tools and systems and needs intermediate validation
More autonomy can hide intermediate state and responsibility, propagating small errors across tools.
- APPROACH
- Decompose work into minimal execution units with state transitions and acceptance conditions.
- BOUNDARY
- Agent count is not presented as workflow maturity.
Human and agent approval, handoff, and recovery responsibilities must be explicit
Retries and duplicate execution can repeat irreversible changes in external systems.
- APPROACH
- Fix input, output, authority, idempotency, and compensation per tool as an execution contract.
- BOUNDARY
- Actions without compensating recovery are not executed unsupervised.
§ 05
Review gains and costs in the same table.
| Decision | Gain | Cost | Watch |
|---|---|---|---|
| Long-running work crosses tools and systems and needs intermediate validation | Decompose work into minimal execution units with state transitions and acceptance conditions. | Agent count is not presented as workflow maturity. | Per-stage success and stop correctness |
| Human and agent approval, handoff, and recovery responsibilities must be explicit | Fix input, output, authority, idempotency, and compensation per tool as an execution contract. | Actions without compensating recovery are not executed unsupervised. | Authority and duplicate-execution violations |
Agent Orchestration: system plate
- A deterministic workflow is simpler and safer
Agent count is not presented as workflow maturity.
- SIGNAL
- Per-stage success and stop correctness
- MITIGATION
- Fix input, output, authority, idempotency, and compensation per tool as an execution contract.
- Tool idempotency, authority, and error contracts are undefined
Actions without compensating recovery are not executed unsupervised.
- SIGNAL
- Authority and duplicate-execution violations
- MITIGATION
- Place autonomous, human-review, and stop boundaries according to risk and uncertainty.
- The workflow begins with Decompose work into minimal execution units with state transitions and acceptance conditions..
- It reaches an acceptance decision through Per-stage success and stop correctness.
§ 07
Agree on measurement conditions before publishing a result.
| Measure | Method | Pass condition | Caveat |
|---|---|---|---|
| Per-stage success and stop correctness | Decompose work into minimal execution units with state transitions and acceptance conditions. | Repeated runs satisfy the acceptance threshold agreed during discovery | Agent count is not presented as workflow maturity. |
| Authority and duplicate-execution violations | Fix input, output, authority, idempotency, and compensation per tool as an execution contract. | Repeated runs satisfy the acceptance threshold agreed during discovery | — |
| Human intervention load and recovery time | Place autonomous, human-review, and stop boundaries according to risk and uncertainty. | Repeated runs satisfy the acceptance threshold agreed during discovery | — |
§ 08
Conditions for not applying the capability are part of the design.
A deterministic workflow is simpler and safer
Agent count is not presented as workflow maturity.
Tool idempotency, authority, and error contracts are undefined
Actions without compensating recovery are not executed unsupervised.
§ 09
Proceed through diagnosis, design, and validation gates.
- 01
Diagnosis
PattyAnalyze the current system and its failure signals.
ClientProvide representative work, data boundaries, and operating constraints.
Per-stage success and stop correctness - 02
Design
PattyFix input, output, authority, idempotency, and compensation per tool as an execution contract.
ClientConfirm owners and acceptance criteria.
Authority and duplicate-execution violations - 03
Validation
PattyPlace autonomous, human-review, and stop boundaries according to risk and uncertainty.
ClientMake the production-transition or stop decision.
Human intervention load and recovery time
§ 10
Artifacts remain with the operating organization after the engagement.
- Agent Orchestration decision record
- Agent orchestration is execution control over state, authority, failure, and human intervention—not model chaining.Client-owned · Patty-reviewed
- Validation harness and acceptance criteria
- Per-stage success and stop correctness · Authority and duplicate-execution violations · Human intervention load and recovery timeJointly maintained
- Operations and recovery runbook
- Agent count is not presented as workflow maturity. · Actions without compensating recovery are not executed unsupervised.Operating-team owned
§ 11
Use shared terms with explicit operating meaning.
- Agent Orchestration
- Design task decomposition, tool contracts, state, approvals, retries, and compensating transactions as an observable graph.
- Acceptance criterion
- Per-stage success and stop correctness
- Operating boundary
- Agent count is not presented as workflow maturity.
REFERENCES
References and primary material
- OpenTelemetry Traces
Primary material for the method and terminology.
- NIST AI RMF: Govern
Primary material for the method and terminology.
Begin by determining whether Agent Orchestration is the justified next step.
We define scope and validation against representative work, data and infrastructure boundaries, and explicit failure conditions.