Multi-Agent Systems in Production: Contracts, Gates, and Human Escalation

Multi-agent architecture is useful when a workflow has genuinely different responsibilities, contracts, or review criteria. It is unnecessary when one deterministic pipeline or one well-scoped model call does the job. More agents add coordination, context, latency, cost, and failure modes; the design must earn that complexity.

Start with role contracts

Define each role by input schema, allowed tools, output schema, stopping condition, and escalation rule. A researcher may return sourced candidates; a planner may produce a bounded plan; an executor may call only an allowlisted tool. Roles should not share an undifferentiated conversation when a typed hand-off is enough.

The orchestrator owns state transitions, not the agents. It records which role ran, which contract version was used, what evidence was returned, and why the next step was selected. A failed contract is a state the workflow can handle, not a reason to silently ask another agent to improvise.

Context engineering and tools

Context should be assembled for the role, not copied from the entire history. Keep stable instructions, task state, retrieved evidence, and prior decisions separate. Include provenance and freshness where they affect the decision. Summarise only when the summary itself can be checked against the underlying state.

Tools are capability boundaries. Use narrow schemas, least-privilege credentials, explicit validation, idempotency where possible, and confirmation for consequential actions. Tool results must be treated as untrusted input; prompt injection can arrive through documents, web content, or an API response. The security service describes the relevant controls.

Evaluation, retries, and trade-offs

Evaluate the complete workflow as well as each critical role. Cases should include normal paths, missing evidence, contradictory sources, tool errors, repeated retries, and human escalation. Deterministic gates can check schemas, permissions, citations, and state transitions; human review can score judgement and usefulness.

Retries need a budget and a reason. A schema repair may be safe to retry; a failed business action may require review. Set limits for turns, tokens, wall-clock time, and spend. Measure whether an additional agent improves the agreed baseline enough to justify its latency and complexity. A fallback to a simpler pipeline is often more reliable than another autonomous branch.

Observability and handover

Trace the workflow across role calls, retrieval, tools, validations, and reviewer actions. Record prompt and contract versions, model choice, latency, token use, cost, and failure category while applying redaction and retention rules. Dashboards should show where work stops, not only how many requests succeed.

Production readiness includes a runbook for stuck state, provider failure, unsafe proposal, and partial completion. Human escalation needs a queue, context, decision vocabulary, and a way to resume or close the state. The this-site case documents the same general discipline of separated roles, explicit gates, and a final editorial decision without claiming a universal method.

A bounded reference pattern

Use an orchestrator with explicit state, a small number of role contracts, typed artefacts between steps, allowlisted tools, evaluation gates, retry budgets, and human escalation for consequential or ambiguous outcomes. Keep a single-agent or deterministic fallback available. Add roles only when a measured workflow gap requires them.

The result is not “autonomy” as a product claim. It is a system whose capabilities and limits can be inspected, tested, operated, and changed deliberately. The Engineering service is a sensible first step for scoping the boundary.

Keep the architecture explainable

The simplest useful diagram should show state, role boundaries, tools, gates, and human exits. If a team cannot explain why a role ran, what evidence it used, or where a failed state is held, the architecture is too implicit for production. Start with a small number of contracts and earn additional autonomy through observed behaviour rather than adding branches in anticipation of scale.