Agent Delegation Protocol Design: Sub-Agent Input/Output and Responsibility Boundaries

Splitting a complex task across multiple agents sounds natural: a research agent finds materials, an execution agent calls tools, and a review agent checks results. But if delegation just forwards a chat history to "another model", the system quickly develops circular delegation, lost context, scope creep, and conclusions that can't be held accountable. The core of multi-agent isn't increasing the number of roles, but designing the interfaces between roles to be as explicit as a reliable service.

A delegation contract needs to define at least five categories of content: the task goal, allowed inputs, expected outputs, resource boundaries, and completion criteria. The goal shouldn't be "research this issue"; it should be written as "compare three candidate solutions, output a risk matrix with sources, and perform no external write operations". Allowed inputs clarify which context will be passed, avoiding indiscriminate propagation of user privacy or admin tokens; the expected output should be a schema, not a free-form piece of text.

Let outputs pass through a schema before reaching the next layer

A sub-agent's return result should pass deterministic validation before being consumed by the scheduler. Each result can be required to have status, summary, evidence, openQuestions, artifacts, and handoff fields. status only allows completed, needs_input, blocked, or failed; evidence must provide a source or tool call ID; handoff clarifies the next-step recommendation rather than directly triggering execution.

{
  "status": "completed",
  "summary": "Among the three solutions, A has the lowest latency, but lacks evidence of tenant isolation.",
  "evidence": [{"source": "tool:metrics-query", "artifactId": "art_123"}],
  "openQuestions": ["Does A support per-project cache isolation?"],
  "handoff": {"recommendedRole": "security-review", "reason": "Isolation model needs verification"}
}

If schema validation fails, the scheduler should mark the result invalid and request a retry or human handling, instead of passing incomplete text on to the next agent. This prevents a hallucinated field from becoming the basis for a downstream write operation.

Permissions and budgets shrink along the delegation chain

A parent agent shouldn't copy all its permissions to a sub-agent. On delegation, generate a narrower, shorter-lived capability token—for example, only allowing it to read a given project's docs, call the search tool at most twice, and not create or delete resources. Capabilities should shrink rather than expand down the chain. When a sub-agent needs to call a new tool, it must return to the scheduler to apply, and cannot change its scope on its own.

Budgets must also be propagated: maximum model call count, total tokens, longest run time, maximum external cost, and maximum concurrency. Delegation without a budget easily turns into recursive expansion, especially under prompts like "find another expert to confirm". The scheduler should record the delegation tree and budget consumption, and once a threshold is reached, enter summary or human-approval mode instead of continuing to spawn roles.

Responsibility must be recoverable, not just forwarded

Each task should have a single owner. Even if it delegates to ten sub-agents, the owner ultimately integrates, validates, and decides whether to commit the result. Sub-agents can produce evidence, but they cannot quietly transfer responsibility to another unknown role. Delegation records need to save parent-child run IDs, input summary hashes, allocation time, timeouts, capability scope, and final result status.

A useful validation scenario is to deliberately have the sub-agent return a conclusion lacking evidence, or request a tool beyond scope. A correct system should reject that result or capability request, and associate the failure with the original delegation, rather than letting the task silently disappear. Then simulate a parent agent timeout to confirm that unfinished subtasks are canceled or reclaimed, avoiding continued unattributed costs in the background.

When to use a single agent

Multi-agent isn't the default answer. If the task goal is singular, tools are few, and context must be shared in full, a single agent with clear tool boundaries is usually more reliable and cheaper. Delegation contracts are only worth introducing when roles genuinely need different context, permissions, concurrency, or validation responsibilities. Writing out the interfaces first, then adding roles, avoids importing organizational-structure hallucinations into the system architecture.

Further reading

• Multi-Agent Communication
• Agent Loop Design
• Reliable Tool Calling