AI agents · Multi-agent systems · Reliability

Prevent Runaway Agent Delegation

Control delegation depth, fan-out, duplicate work, cycles, authority propagation, and result synthesis in multi-agent systems.

Published: Jul 18, 2026
Updated: Jul 18, 2026
Code examples: Illustrative
Reading time: 6 minutes

Prevent runaway delegation by making delegation a privileged orchestrator operation with a depth limit, fan-out limit, child budget, stable task identity, and acyclic parent chain. Workers may propose child work; only deterministic policy should authorize and create it.

This guide focuses on recursive delegation. For deciding whether several agents help at all, start with Agent Swarms: When Multiple AI Agents Help. For worker-pool concurrency, use bounded parallelism.

Understand the failure shape

Runaway delegation is not just “too many agents.” It includes:

recursive expansion: children create more children until cost or rate limits fail;
duplicate work: several agents independently create the same investigation;
cycles: agent A delegates to B, which delegates the equivalent task back to A;
scope drift: each handoff broadens the original objective;
authority amplification: a child receives permissions the parent did not have;
orphaned work: a parent finishes or cancels while children continue;
synthesis collapse: more artifacts are created than the coordinator can validate.

A prompt such as “delegate only when useful” does not define a measurable boundary. The control plane must reject invalid delegations before a child process or model call starts.

OWASP's multi-agent security guidance recommends authenticated communication, authorization boundaries, limits on agent-to-agent trust, and tests for recursive tool abuse and multi-agent chaining. Its abuse-case matrix explicitly calls for chain-depth, retry, token, and cost limits. OWASP AI Agent Security Cheat Sheet

Require a typed delegation proposal

interface DelegationProposal {
  readonly parentTaskId: string;
  readonly objective: string;
  readonly inputArtifactIds: readonly string[];
  readonly expectedArtifactType: string;
  readonly acceptanceCriteria: readonly string[];
  readonly requestedCapabilityIds: readonly string[];
  readonly requestedBudget: {
    readonly modelCalls: number;
    readonly toolCalls: number;
    readonly totalTokens: number;
    readonly deadlineAtMs: number;
  };
}

interface DelegatedTask {
  readonly id: string;
  readonly rootTaskId: string;
  readonly parentTaskId: string;
  readonly depth: number;
  readonly objectiveDigest: string;
  readonly grantId: string;
  readonly status:
    | "queued"
    | "running"
    | "input_required"
    | "completed"
    | "failed"
    | "cancelled";
}

The proposal contains no raw credential and no arbitrary endpoint. requestedCapabilityIds references capabilities already registered with the orchestrator. The policy intersects requested capabilities with the parent's grant; it never takes the union.

An acceptance criterion must be observable. “Think deeply” is not one. “Return the applicable specification section, its revision, and a source link” is closer.

Enforce five gates atomically

Before creating a child:

Depth: parent.depth + 1 is within the root policy.
Fan-out: the parent and root have capacity for another active child.
Budget: the child grant can be reserved from the parent's remaining grant.
Authority: every child capability is a subset of the parent's authority.
Novelty: no active or completed equivalent task already satisfies the need.

The checks and child creation must be atomic. Otherwise, concurrent proposals can each see one remaining slot and all succeed.

type DelegationDecision =
  | {
      readonly allowed: true;
      readonly childTaskId: string;
      readonly grantId: string;
    }
  | {
      readonly allowed: false;
      readonly reason:
        | "depth"
        | "fan_out"
        | "budget"
        | "capability"
        | "duplicate"
        | "parent_terminal";
      readonly existingTaskId?: string;
    };

async function authorizeDelegation(
  proposal: DelegationProposal,
): Promise<DelegationDecision> {
  // Transaction: lock or compare-and-swap parent/root counters, verify
  // capability subset, reserve budget, deduplicate, then create child.
  return delegationStore.authorizeAtomically(proposal);
}

The budget-controller guide covers hierarchical reservation in detail.

Detect duplicates by intent, not prose alone

Exact string matching misses paraphrases; unconstrained embedding similarity can merge tasks that differ in tenant, target, date, or acceptance criteria.

Construct a normalized identity from trusted fields:

identity = hash(
  root_task_id,
  tenant_id,
  normalized_task_class,
  target_resource_ids,
  input_artifact_digests,
  acceptance_criteria_version,
  relevant_time_boundary
)

Use that identity for exact deduplication. A semantic model may suggest possible duplicates, but deterministic code or the coordinator should confirm equivalence. Never share a result across tenants merely because two objectives look similar.

When a completed task already satisfies the same contract and its inputs are unchanged, reference its artifact instead of starting a child. When an equivalent task is running, subscribe to its terminal result rather than launching another copy.

Prevent cycles with ancestry and scope

Every task carries immutable rootTaskId, parentTaskId, and depth. Reject a proposal that:

names any ancestor as the intended child;
reproduces an ancestor's normalized identity;
depends on an artifact the proposed child itself must create;
broadens the root's target resources or authority;
has a deadline later than its parent.

Semantic cycles can occur even when task IDs are new. Example: “ask the compliance agent whether the research is sufficient” followed by “ask the research agent what compliance still needs.” Detect repeated pairs of task class and unresolved criterion, then stop with a structured blocker.

Keep task state and artifacts distinct

The published A2A specification models a task as stateful work with a lifecycle and artifacts as its outputs. It says messages should not be treated as reliable delivery for critical information and recommends outputs through artifacts. That separation helps prevent a persuasive status update from being mistaken for completed work. A2A protocol specification

Require each child to reach a terminal state and produce an artifact matching its contract. The parent should receive:

status and terminal reason;
artifact ID, type, schema version, and digest;
evidence and limitations;
budget usage;
any incomplete acceptance criteria.

Do not copy an entire child transcript into the parent context. The typed-artifacts guide shows runtime validation and semantic checks for handoffs.

Propagate cancellation and deadlines

Cancelling a root closes admission for every descendant and signals running children. Child deadlines must be no later than the parent deadline, leaving time for validation and synthesis.

Cancellation is not proof that external work stopped. Track acknowledgments and reconcile side effects. A child that finishes after cancellation may produce a quarantined artifact for audit, but it must not silently resume the root.

MCP's 2025-11-25 Tasks utility is an example of a protocol-level durable task state machine with capability negotiation, polling, result retrieval, and optional cancellation. The specification labels Tasks experimental, so do not treat its current shapes as a permanent cross-version contract. MCP Tasks specification, 2025-11-25

Limit synthesis load

Even valid independent children can overwhelm the parent. Before delegation, account for:

the number of artifacts the coordinator can inspect;
the context required to compare them;
deterministic merge opportunities;
independent verification capacity;
time reserved for synthesis.

A useful rule is to reserve parent capacity for validation and synthesis before granting worker budgets. If ten branches fit but only two can be reviewed, start two.

Do not treat majority agreement as verification. Several children may share the same model, source, prompt, or poisoned context. Require source-level evidence, deterministic tests, or an independent human decision where consequences demand it.

Observe the delegation tree

Record a traceable tree with:

root, parent, and child IDs;
normalized task identity;
proposal and decision reason;
capability and budget grant IDs;
start, terminal, and cancellation times;
artifact and evidence IDs;
duplicate reuse links;
terminal reason and resource usage.

Alert on high depth, high breadth, repeated equivalent proposals, oscillation between task classes, children outliving parents, and artifacts never consumed by synthesis. OpenTelemetry can correlate agent and tool spans, but its GenAI content attributes may hold sensitive information; use stable IDs by default and apply explicit redaction policy. OpenTelemetry GenAI attribute registry

Test adversarial delegation

Include cases where:

a retrieved page tells the worker to spawn more agents;
a child requests a capability absent from the parent;
two workers concurrently propose the same task;
A delegates to B and B paraphrases the task back to A;
the parent is cancelled during child execution;
a child claims completion without the required artifact;
budget reporting arrives twice or after closure;
a malicious artifact tries to redefine the root goal.

The expected result is a policy decision and audit record, not merely a model refusal.