MCP and orchestration
Agent Orchestration Pattern Decision Guide
Choose direct tools, deterministic workflows, manager-agent delegation, handoffs, parallel work, or human routing from control and evidence needs.
- Format
- Decision Path
- Level
- Intermediate
- Audience
- Practitioner, Developer, Operator, Leader
- Owner
- Project42 Editorial
- Review cadence
- Every 30 days
- Prerequisites
- A decomposed workflow with known decisions, tools, risks, and ownership
Choose the least complex sufficient pattern
Use one agent with direct tools when one instruction set and one owner can complete the work. Use deterministic code or sequential workflow steps when order, validation, or compliance must be guaranteed. Use parallel branches only for independent, read-only or isolated work with an explicit join and conflict policy.
Use specialists as tools when a manager must retain control, combine outputs, and own the final response. Use a handoff when a specialist should become the active owner and speak directly to the user. Use human routing when authorization, ambiguity, consequence, or accountability cannot safely be delegated. More agents increase handoff, context, latency, cost, and failure surface; they are not a default quality feature.
Record the orchestration decision
Define ownership of state, approvals, user communication, final output, and recovery. Decide what context crosses each boundary, how sensitive data is filtered, how duplicate actions are prevented, and how partial branches are reconciled.
Workflow outcome: [RESULT]
Steps and dependencies: [STEP -> PREDECESSOR]
Required determinism: [LOW | MEDIUM | HIGH WITH REASON]
Risk/approval points: [ACTION -> APPROVER]
Chosen pattern: [DIRECT TOOLS | SEQUENTIAL | PARALLEL | MANAGER+TOOLS | HANDOFF | HUMAN ROUTE]
Why simpler patterns fail: [EVIDENCE]
Control owner: [ROLE]
Final-output owner: [ROLE]
State owner and consistency model: [SYSTEM, RULE]
Context passed: [MINIMUM FIELDS]
Context withheld/redacted: [FIELDS]
Join/handoff contract: [INPUT, OUTPUT, DONE CONDITION]
Timeout/cancellation: [POLICY]
Duplicate/retry control: [IDEMPOTENCY OR RECONCILIATION]
Partial-failure policy: [FAIL CLOSED | COMPENSATE | DEGRADED]
Observability: [TRACE, METRICS, AUDIT]
Rollback: [RETURN TO PRIOR PATTERN/STATE]
Evaluation cases: [NORMAL, AMBIGUOUS, FAILURE, ADVERSARIAL]Expected evidence and verification
The expected evidence is a decision record plus evaluation traces showing that the selected pattern assigns one accountable owner, preserves required context, enforces approval, and handles timeout, duplicate, and partial-failure cases.
Compare the chosen pattern with a simpler baseline on task success, unsupported actions, handoff accuracy, latency, cost, and recovery. Inject a failed specialist and a conflicting parallel result. Confirm the owner can cancel, reconcile, or roll back without repeating external effects. Revisit the choice when tasks, tools, risks, or model behavior change.