A multi-agent design is useful when different branches need genuinely different instructions, tools, data access, or ownership. It is not a default upgrade from a single agent. Every handoff adds latency, cost, state transfer, and another place where intent can be lost. Begin with a deterministic workflow and one bounded agent, then split only the stages whose evaluations show a clear benefit from specialization.
Write the workflow contract before naming agents
Define the input event, terminal outcome, authorized side effects, evidence required at each transition, retryable failures, approval points, and escalation owner. Mark which steps are deterministic code, which require model judgement, and which require human authority. This prevents an architecture diagram from disguising an undefined business process.
Choose manager ownership or a true handoff
Use a manager pattern when one agent should retain responsibility for the final answer and call specialists as bounded tools. Use a handoff when the specialist should become the active owner of the next interaction. Keep each route description narrow and test ambiguous cases. Do not pass every specialist the full tool inventory or complete conversation history when a filtered task packet is sufficient.
Split an agent only when the new boundary improves instructions, authority, context, or evaluation—not because more agents look more capable.
Keep durable state outside model conversation
Store workflow ID, current state, input snapshot, specialist assignment, tool results, approvals, attempts, and terminal outcome in an execution ledger. The model can propose the next transition, but application code should validate and commit it. Resume from the last completed checkpoint after a timeout rather than replaying the entire conversation and repeating side effects.
Use typed handoff and tool contracts
Give every specialist a versioned input schema with required evidence and an output schema that distinguishes decision, confidence, citations, requested action, and unresolved fields. Validate types and business constraints at runtime. Return structured, repairable errors for missing fields, but cap correction loops and route persistent failures to an operator instead of letting agents negotiate indefinitely.
Enforce authority outside the model
An auditor agent can catch inconsistencies, but it is not an independent security boundary when it relies on the same data and similar model behavior. Enforce tenant access, allowed transitions, monetary limits, consent, record state, and approval tokens in deterministic middleware. Use a human approval for consequential exceptions. Give the approving party the proposed action, evidence, diff, and rollback consequence—not merely another agent's confidence score.
Make retries safe across agent boundaries
Assign an idempotency key to each business action and record tool-call outcome before advancing state. Retry only transient failures, with a maximum attempt or elapsed-time budget. A specialist timeout should not cause the manager to call a second specialist that performs the same write unknowingly. Compensating actions must be explicit workflow states with their own authority checks.
Evaluate routing and end-to-end outcomes
Test wrong-route, no-route, conflicting specialist results, stale context, malformed handoff payload, tool denial, partial completion, repeated event, approval rejection, and operator takeover. Track route accuracy, task success, unauthorized-action attempts, handoff count, correction loops, tool errors, latency, token cost, human intervention, and rollback rate. Compare the multi-agent version against the simpler baseline; keep the additional topology only where it measurably improves the target outcome.