Choosing Multi-Agent Patterns for Reliable Tool Use

Multi-agent architecture is useful when a workflow contains genuinely different responsibilities: planning, research, code execution, validation, or domain-specific decisions. It is not automatically better than one capable model with tools.

Every additional agent creates another boundary where context can be lost, work can be duplicated, and tool calls can produce unintended effects. The engineering task is therefore not to maximize agent autonomy. It is to choose an orchestration pattern that makes delegation and tool execution observable, bounded, and recoverable.

The right pattern depends less on the number of agents than on three questions: Who owns the next decision? Who may invoke which tool? How is the result verified before the workflow proceeds?

Start with the simplest execution model

Before introducing multiple agents, test whether a single agent can complete the workflow using a small, well-defined tool set. This baseline is easier to evaluate, cheaper to run, and simpler to secure.

Split the workflow only when there is evidence of a structural problem, such as:

• The model confuses instructions from unrelated domains.
• Different steps require distinct permissions or data access.
• One context window accumulates too much irrelevant history.
• Tasks can run independently and benefit from parallel execution.
• A specialist consistently outperforms a general-purpose agent.
• High-risk actions need independent review.

Do not create agents merely to mirror an organizational chart. A “product agent,” “engineering agent,” and “finance agent” may sound intuitive, but those labels do not define execution boundaries. Useful boundaries are operational: read-only versus write access, low-risk versus high-risk decisions, or deterministic processing versus model judgment.

Pattern 1: Router and specialists

A router classifies an incoming task and selects one specialist. The specialist then owns the work until completion or escalation.

This pattern works well for support triage, document processing, internal knowledge assistants, and workflows with clear domain boundaries. It also limits tool exposure: a billing specialist can access invoice systems while a technical specialist can access logs, without giving either agent every credential.

The router should produce a structured decision rather than prose. A practical routing result might contain destination, confidence, reason_code, and required_context. If confidence falls below a threshold, route to a general fallback or human review instead of guessing.

Avoid allowing specialists to call one another freely. That turns a predictable routing tree into an opaque network. If a specialist discovers that the task belongs elsewhere, it should return a typed escalation to the router.

The main failure mode is misrouting. Measure it directly with a labeled test set and production samples. End-to-end task success alone may hide systematic routing errors because downstream agents occasionally compensate.

Pattern 2: Planner and workers

A planner decomposes a goal into tasks, while workers execute those tasks with constrained tools. This is appropriate for research, migration analysis, test generation, and other work where the required steps cannot be fully specified in advance.

Treat the plan as data. Each task should include an identifier, objective, dependencies, allowed tools, expected output schema, and stopping condition. Workers should not silently rewrite the plan. They can report blocked tasks or propose changes, but the orchestrator decides whether to update the execution graph.

Planning and execution should also use separate budgets. Otherwise, a planner can create an unbounded list of tasks that multiplies model calls and external API costs. Useful limits include:

• Maximum tasks per plan
• Maximum plan revisions
• Per-worker token and time budgets
• Global tool-call and monetary budgets
• Maximum dependency depth

Parallelize only independent tasks. If two workers update the same record, repository branch, or document, concurrency introduces conflicts that model reasoning will not reliably resolve. Serialize writes or use an explicit merge step.

The common mistake is accepting a plausible plan as a correct plan. Validate task dependencies, permissions, and schemas before execution begins.

Pattern 3: Supervisor with review loops

A supervisor assigns work, evaluates outputs, and requests revisions. This pattern fits deliverables where quality is partly subjective but can still be assessed against explicit criteria, such as technical reports, code changes, or incident summaries.

Review loops need hard limits. “Revise until good” is not a production policy. Define a maximum number of iterations and require the reviewer to return structured findings: severity, evidence, violated criterion, and requested correction.

Use independent validation wherever possible. Code should pass tests and static analysis. Extracted data should satisfy schema and reconciliation checks. Citations should resolve to retrieved sources. The supervisor can interpret those signals, but it should not replace them.

Be cautious when the same model configuration generates and reviews an artifact. Shared blind spots can produce false agreement. For high-impact workflows, vary the review prompt or model, add deterministic checks, and route unresolved critical findings to a person.

Pattern 4: Event-driven handoffs

In long-running workflows, agents should not remain active while waiting for external events. Instead, persist state and resume execution when an event arrives: a user approves a request, a build finishes, a payment clears, or another service publishes a result.

This pattern is well suited to onboarding, procurement, release management, and operational remediation. It requires durable workflow state rather than a long conversation transcript.

A handoff event should identify the workflow, current state, triggering event, completed artifacts, pending obligations, and permitted next actions. Use idempotency keys because queues and webhooks can deliver duplicates. Version the workflow schema so in-flight executions survive deployments.

The primary risk is stale context. Before resuming, revalidate assumptions that may have changed, including permissions, resource status, prices, and approval validity.

Design tools as narrow contracts

Tool calling is where model output becomes a real-world effect. Tool design therefore matters more than elaborate agent personas.

Expose narrow operations such as create_draft_invoice or get_deployment_status, not generic endpoints like run_sql or call_api. A narrow tool communicates intent, simplifies authorization, and makes audit logs understandable.

Every tool should have:

• A strict input schema with bounded values
• A typed success response and defined error taxonomy
• Authentication based on the calling workflow or user
• Timeouts, retries, and idempotency where applicable
• Logs connecting the call to agent, task, and workflow IDs
• Clear classification as read-only, reversible, or irreversible

Validate arguments outside the model. Do not trust the model to respect date ranges, tenant boundaries, spending limits, or resource identifiers simply because the prompt mentions them.

Keep business policy out of tool descriptions. A description can explain what a tool does, but authorization rules belong in executable policy. For consequential actions, use a two-step design: prepare or preview the change, then commit it after validation or approval.

Tool results should be compact and structured. Returning an entire API payload wastes context and can expose irrelevant sensitive data. Normalize responses into the fields the agent needs, while storing the raw response separately for diagnostics.

Make failures explicit and recoverable

Agents should not receive every failure as an undifferentiated text message. Distinguish invalid arguments, permission denial, transient dependency failure, rate limiting, conflicting state, and permanent business rejection.

The orchestrator can then apply specific policies. Retry transient failures with backoff. Ask the agent to repair invalid arguments. Stop immediately on permission failures. Re-fetch state after conflicts. Escalate ambiguous business rejections.

Checkpoint after meaningful steps rather than replaying the entire workflow. Record the plan version, task status, tool inputs and outputs, model configuration, approvals, and resulting artifacts. This supports recovery and makes incident analysis possible.

Retries must be bounded at both tool and workflow levels. Nested retries are a frequent source of cost spikes: the HTTP client retries, the agent retries the tool, and the supervisor restarts the task. Assign retry ownership to one layer for each failure class.

Evaluate the orchestration, not just the answer

A polished final response can conceal inefficient or unsafe behavior. Evaluation should inspect the path taken through the system.

Track routing accuracy, unnecessary delegation, tool-selection accuracy, argument validity, repeated calls, unauthorized attempts, task completion time, cost, and human escalation rate. For write operations, measure prevented and executed side effects separately.

Build scenario tests that include unavailable tools, malformed results, delayed events, duplicate delivery, revoked permissions, conflicting updates, and adversarial content in retrieved data. Run them against the complete workflow, not isolated prompts.

Trace data should make each decision reconstructable without storing more sensitive content than necessary. Correlate agent turns, tool calls, state transitions, and approvals under one workflow identifier.

Short takeaway

Choose the smallest orchestration pattern that matches the workflow. Give each agent limited authority, make plans and handoffs structured, and treat tools as secure APIs rather than model conveniences. Multi-agent systems become useful when their boundaries reduce risk and complexity—not when they merely add more conversations.