How can a multi-agent system delegate work without losing control?

Do not begin by choosing a number of agents. Begin by asking whether the business process contains distinct tasks with different knowledge, tools or authority—and whether each task can be verified, constrained and recovered independently. A second agent is useful when it creates a real control boundary. Without that boundary, it usually adds context loss, duplicated work and another place for responsibility to disappear.

Who should use this framework

This guide is for business and product owners planning an AI service workflow, customer-support assistant, document review process, quotation aid or field-service application that spans internal knowledge, operational systems and human approval. An agent here is a software role that can interpret information, invoke tools, delegate work or advance a business state. Renaming the same model several times does not create a governed multi-agent product.

Google Cloud's August 2026 discussion of intelligent delegation recommends “contract-first decomposition”: break work into units that can be checked before assigning them, while matching authority, information and cost to the assignment. OpenAI's Agents SDK distinguishes a manager that invokes specialists from a handoff that transfers the active conversation to a specialist. Microsoft's multi-agent guidance recommends a separate agent when a task has its own tools, knowledge or governance boundary—and otherwise advises starting with one agent.

The practical lesson is straightforward: an agent boundary should behave like a service contract, not an org-chart label.

When one agent or conventional workflow is better

Start with deterministic software or one agent when:

• routing can be expressed through stable business rules;
• every step uses the same knowledge, permissions and acceptance criteria;
• the process is a predictable sequence with little variation;
• one agent already completes the representative tasks reliably;
• every result needs the same human review, so delegation does not remove or focus oversight.

Consider multiple agents when separate tasks genuinely require isolated sources or tools, different authority, parallel work with independently testable outputs, expertise that emerges only during execution, or a specialist capability reused by several products.

A request classifier followed by a single knowledge search rarely needs an autonomous network. Complexity should follow a demonstrated boundary, not a desire to make the architecture look sophisticated.

Six clauses in every delegation contract

1. Scope

Name the decision, allowed sources, exclusions and completion condition. “Handle this customer issue” is not testable. “Check whether the serial number and approved warranty terms make this request eligible for review; do not promise compensation or change the order” is much closer.

2. Minimum necessary context

Pass only the fields needed for the assignment. A formatting agent does not need a payroll table. A product-documentation agent does not need a customer's complete order history. Limiting context reduces both disclosure and distraction.

3. Structured result

Require a conclusion, evidence, uncertainty, source version and proposed next state. Use stable fields and enumerated statuses where software must continue the process. “No evidence found” and “confirmed ineligible” must remain different outcomes.

4. Acceptance method

Define the check before execution: required fields, approved sources, current policy version, matching system record or required human sign-off. Subjective work should be deliberately routed to an accountable reviewer, not silently passed to another model for an intuitive second opinion.

5. Authority and budget

Give every agent a distinct identity, tool list, data scope, time limit, step limit and cost ceiling. Reading a record, creating a draft, submitting a payment and deleting data are different permissions. A downstream agent must not inherit greater authority merely because an upstream agent says the request is approved.

6. Failure and escalation

Specify what happens after a timeout, empty result, source conflict, tool error, duplicate request or partial success. Cap delegation depth and total effort. When the limit is reached, stop with the evidence collected so far instead of spawning more agents indefinitely.

Choose the least dynamic orchestration that works

Pattern	Use it when	Essential control
Deterministic sequence	Stages and dependencies are known	Code owns order, schemas and stop conditions
Parallel fan-out and aggregation	Independent sources or disciplines can work concurrently	Preserve each result and check gaps or conflicts before synthesis
Manager with specialists	One component must own the final answer and common guardrails	Specialists return bounded findings; the manager remains accountable
Dynamic handoff	The required specialty becomes clear only during execution	Define routing criteria, filtered context, receipt and a return path

Known business transitions should not be left to unconstrained model planning. OpenAI's orchestration guide notes that code-driven flows are more deterministic in speed, cost and performance. Microsoft's architecture guidance similarly recommends a simpler dispatcher when the destination can be identified upfront. A sound design lets models handle uncertain interpretation while code retains payment, record mutation, authorization and state transitions.

Conflict needs evidence rules, not an agent vote

Classify disagreements before resolving them:

• Source conflict: apply the approved source hierarchy, effective date and jurisdiction.
• Data conflict: return to the system of record and compare query or version timestamps.
• Policy conflict: pause consequential action and ask the policy owner which version applies.
• Judgement conflict: preserve both rationales and use one declared acceptance standard.
• Action conflict: let one writer check current state, version and idempotency key before committing.

A referee agent cannot manufacture authority. It can compare evidence under a published rule; when the evidence is insufficient, the correct result is pending review—not a forced consensus.

Recovery is a product state, not another prompt

A production workflow should distinguish queued, running, awaiting approval, succeeded, failed, compensating and terminated states. Persist the task identifier, parent task, input version, actor, tool calls, result, error and timestamp. Resume from the last accepted checkpoint instead of replaying the entire chain.

Use idempotency keys for external effects. If a service call times out while creating a case, first query whether the case exists before retrying. When an early stage succeeds and a later stage fails, define which actions can be compensated, which reservations can be released and which cases require manual repair. Not every real-world action has a safe rollback.

Parallel agents should not update the same business record directly. Route proposed changes through a single write service that checks current version and authorization. This prevents one slow or repeated agent from creating duplicate orders, duplicate messages or overwritten status.

An illustrative service workflow

This example explains the method; it is not a customer case or measured result. Imagine an equipment company using AI to prepare after-sales requests:

1. A manager creates a stable task ID and coordinates the case.
2. A product agent reads only approved manuals and model information.
3. A warranty agent reads only the effective contract and warranty rules.
4. An order agent checks the relevant purchase record without exposing unrelated history.
5. When results agree and required fields are complete, a deterministic service creates a draft case.
6. Missing evidence, policy conflict, compensation or out-of-scope requests go to a person.
7. Only after approval does the write service change the official status and notify the customer.

The value comes from distinct sources, permissions, outputs and failure paths—not from having three specialist names. If all three checks use one database and fixed rules, a conventional service plus one agent may be the better product.

Acceptance checklist

• Each agent has a unique responsibility and does not duplicate another agent's knowledge search.
• Every delegation records task and parent IDs, input version, allowed tools and acceptance criteria.
• Sensitive or irrelevant history does not spread through the delegation chain.
• Read, draft and commit actions use separate identities and permissions.
• Empty, conflicting, refused and failed results remain distinct states.
• Parallel work has an explicit merge and conflict policy.
• External writes are idempotent, and unknown outcomes trigger reconciliation before retry.
• Time, cost, steps and delegation depth are bounded.
• Human approvals cover the exact content and action eventually submitted.
• A final result can be traced to each source, tool call and approval.
• Tests cover missing data, insufficient authority, conflicting rules, timeouts and duplicates—not only the happy path.
• Operations track completion, human takeover, conflict, duplicate effects, timeout and cost per accepted outcome.

Common mistakes and ongoing control

Mirroring departments as agents. A department name does not define software responsibility or authority.

Assuming more agents mean more confidence. Agents using the same model, source and premise can repeat the same error at additional cost.

Letting agents debate until they agree. Discussion without source priority or a stop rule spends more tokens without resolving evidence.

Replaying the entire process after failure. This can duplicate real-world actions and alter content that a person already approved.

Logging everything without classification. Traces may contain prompts, attachments and tool arguments. Apply minimisation, redaction, access control and retention limits to operational evidence.

Reassess data flow, authority, the delegation contract, conflict rules and recovery whenever a new agent, tool or knowledge source is added. Update policy versions and evaluation cases before changing orchestration. Maturity is measured by whether failures are visible, contained and recoverable—not by the number of agents on an architecture diagram.

If the project has not yet established a baseline, start with a practical value test for software and AI projects. For production acceptance, combine this guide with the business acceptance framework for an AI assistant to define failure classes and human review.

Sources

• Google Cloud: How agents can delegate better — verifiable decomposition, cost-aware delegation, minimum necessary information and deliberate challenge in delegation chains. Published 21 August 2026; accessed 17 September 2026.
• OpenAI Agents SDK: Agent orchestration — manager-and-specialist, handoff and code-driven orchestration patterns, including the predictability trade-off. Accessed 17 September 2026.
• Microsoft Learn: Multi-agent orchestration patterns and best practices — separation criteria, context transfer, authority, audit and parent-child session correlation. Accessed 17 September 2026.
• Microsoft Azure Architecture Center: AI Agent Orchestration Patterns — use and avoidance conditions for sequential, concurrent and handoff orchestration. Accessed 17 September 2026.

This is a product-scope and acceptance framework. Validate the final design against the target systems, actual permissions, representative business cases and current provider documentation.