Enterprise teams often treat multi-agent design as a performance trick.
One agent plans. Another researches. A third writes code. A fourth checks policy. It sounds tidy, and sometimes it is.
But the operational change is bigger than architecture style.
Once an AI system can delegate work to subagents, the organization is no longer governing one model response. It is governing a chain of transferred authority across prompts, context windows, tool scopes, and result handoffs.
That is why enterprise AI needs a delegation contract.
A delegation contract is the written operating rule for which agent may hand work to which other agent, with what context, under what permissions, toward which outcome, with what evidence returned at the end.
Without that contract, subagents can make a system feel more capable while making accountability harder to reconstruct.
Why this matters now
The primary-source product direction is clear. Delegation is becoming normal infrastructure.
The OpenAI Agents SDK handoffs guide says handoffs allow an agent to delegate tasks to another agent and describes them as especially useful when different agents specialize in distinct areas. The same doc says handoffs are represented as tools to the model, with tool names such as transfer_to_refund_agent.
That is an important design clue. Delegation is not abstract orchestration. It becomes an explicit callable path inside the workflow.
Anthropic’s current Claude Code subagents docs make the same point from another angle. The docs describe subagents as specialized AI assistants for task-specific workflows and improved context management. They say each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions, and that Claude delegates when a task matches the subagent’s description.
That means a single top-level request can trigger separate workers that do not share identical instructions or authority.
Google’s ADK workflows docs point to the same operational shape at the application level. The current documentation says collaborative workflows allow a single agent to act in a dynamic coordinator role with specified sub-agents, while template workflows provide fixed execution logic for sequences, loops, and parallel execution.
That is not just “more agents.” It is a broader execution graph.
Put those sources together and the governance issue becomes obvious. The unit of control is no longer just the model route. It is the delegation graph around the route.
What a delegation contract is
A delegation contract is not the same thing as a prompt, a tool registry, or a sandbox.
A prompt shapes behavior. A tool registry names possible actions. A sandbox limits where an agent runs.
A delegation contract answers different questions:
- Which agent is allowed to hand work to which subagent?
- What exact task classes justify that transfer?
- How much source context is allowed to cross the boundary?
- What tools and permissions does the receiving agent inherit, if any?
- What format must come back before downstream work can continue?
- When does the workflow have to stop for human review instead of delegating again?
In other words, it turns “the coordinator called a helper” into an inspectable operating record.
Why subagents change accountability
1. Specialization fragments authority
OpenAI’s handoff model and Anthropic’s subagent model both encourage specialization. That is useful. It also means different workers may now hold different task definitions, different tools, and different permissions inside one user-visible workflow.
If the organization cannot name those boundaries clearly, it may think it deployed one assistant when it actually deployed a small workforce with unequal authority.
2. Context transfer becomes a governance choice
Anthropic’s subagents docs explicitly frame subagents as a way to keep side-task material out of the main conversation by letting a subagent work in its own context window and return only the summary.
That creates a real control question: What should the parent pass through, and what should stay behind?
Too little context and the subagent works blindly. Too much context and the organization leaks unnecessary files, logs, or sensitive business detail into a worker that did not need them.
3. Parallel paths make provenance harder
Google ADK’s workflow patterns include parallel execution. That is powerful for throughput, but it also means one request can produce several concurrent sub-results before a coordinator recombines them.
If the workflow does not preserve per-agent provenance, reviewers may only see the final synthesis and not which worker supplied which claim, tool result, or recommendation.
4. Tool scope can drift across the delegation graph
Delegation often looks harmless in diagrams because the boxes are small. In real systems, each delegated worker may have different tools, different filesystem access, different network reach, or different approval rules.
That means the question is not just whether the parent agent was safe. It is whether the receiving agent was appropriate for the exact slice of work it inherited.
5. Human review can disappear between layers
A system may have a visible approval step at the front door, then continue delegating internally after approval without preserving where human review was supposed to apply.
When that happens, “approved the workflow” can quietly become “approved an unknown number of downstream transfers.”
What breaks when no delegation contract exists
1. The system can over-delegate without anyone noticing
Engineers add new specialists because the framework makes it easy. The product surface still looks like one assistant. Operators lose sight of how many internal workers now touch the request.
2. Sensitive context spreads farther than the task required
Logs, design files, customer notes, or internal documents can get forwarded to specialized workers simply because the parent had them, not because the subagent needed them.
3. Reviewers cannot reconstruct the real path
If a workflow fails or produces a risky output, the team may be able to inspect the final answer but not the chain of delegated steps that produced it.
4. Parallel workers can create conflicting results
Two subagents may research the same issue with different instructions or freshness windows. Without an explicit merge rule, the coordinator can treat disagreement as just more text instead of a signal that the workflow should stop.
5. Delegation becomes invisible product behavior
Once delegation is treated as an implementation detail, buyers, reviewers, and operators lose the ability to reason about who actually did the work inside the route.
What a delegation contract should include
1. Allowed delegation graph
Document which parent agents can call which child agents. Do not leave the graph implied by code comments or prompt text.
2. Task-class boundaries
Name the job each subagent is actually for: research, file triage, schema validation, browser collection, routing, synthesis, or approval preparation. If a task falls outside that class, the route should stop or escalate.
3. Context-transfer policy
Define what the parent may pass down: raw files, excerpts, metadata only, citations only, or summary plus links. Context should be minimized on purpose, not by accident.
4. Tool and permission scope per agent
Record which tools, filesystems, network lanes, credentials, and write paths are available to each delegated worker. The parent’s authority should not silently become the child’s authority.
5. Result contract
Require each subagent to return a defined artifact: structured fields, citations, uncertainty markers, stop reasons, or recommended next actions. Free-form text alone makes downstream review harder.
6. Parallel and recursion limits
Set limits on fan-out, depth, and repeated delegation. If a workflow can keep spawning helpers, it needs clear ceilings before cost and complexity outrun control.
7. Human review and stop rules
Define which delegated results can flow forward automatically and which must pause for human review. Approval at the parent level does not automatically cover every child action.
8. Evidence and trace retention
Keep a durable record of the parent request, delegated task, context passed, tools available, result returned, and terminal disposition. If the team cannot replay the responsibility chain, it does not fully understand the workflow it launched.
Questions operators should ask before enabling subagents
- Which agent is allowed to delegate this task, and to whom?
- What exact context is allowed to cross that boundary?
- What tools and permissions does the receiving worker have?
- What result shape must come back before the parent can continue?
- Can delegated results trigger more delegation, or is the graph bounded?
- Where does human review happen if delegated workers disagree or produce uncertain output?
- What trace will remain if we need to explain who did what inside the workflow?
If those answers are vague, the system may still be clever, but it is not yet well-governed.
The commercial takeaway
Multi-agent systems are becoming easier to build because the underlying products now expose delegation directly. OpenAI normalizes handoffs between specialized agents. Anthropic exposes task-specific subagents with their own prompts, tools, and permissions. Google ADK formalizes coordinator-plus-subagent workflows and parallel execution patterns.
That is useful progress. It also means enterprise buyers should stop evaluating “agentic AI” as if the meaningful unit is only the top-level assistant.
The more useful question is: What delegation contract does this workflow actually enforce?
Teams that answer that question well will be in a much better position to inspect context flow, scope authority, review disagreements, and explain downstream actions. Teams that skip it may still ship a smart demo, but they will struggle to prove how work moved across the system once it mattered.
Related reads
- Enterprise AI Needs a Sandbox Contract: Why Tool-Using Models Change the Trust Boundary
- AI Agents Need Approval Receipts: The Governance Record Between Suggestion and Action
- AI Agents Need Run Manifests: The Change-Control Layer for Replayable Workflows
- AI Workflow Services