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.

Core conceptAnthropicOpenAIGoogle
CurrentNext review due 2026-08-24Content version 0.30.0
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
01

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.

02

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.

Orchestration decision record
text
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]
03

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.