AI Agent Delegation Contracts: Bound the Work Before You Spawn It

Spawning another agent is easy. Giving it a job that can be completed, verified, and safely merged is the hard part.

Most multi-agent failures are not dramatic model failures. They are management failures expressed in software: two workers edit the same file, a researcher assumes it can publish, a delegated task expands until it burns the budget, or a parent agent accepts “done” without evidence.

An AI agent delegation contract makes the handoff explicit. It defines what the child owns, what it may change, what it must return, and how the parent decides whether the result is usable.

Make the Objective Testable

“Research competitors” is not a task. It is a direction with no stop condition. A stronger objective names the artifact and acceptance test: “Compare the five listed products on price, authentication, export formats, and API limits; cite the vendor documentation for every claim.”

The contract should include:

• the concrete output;
• inputs and trusted sources;
• in-scope and out-of-scope work;
• required evidence;
• time, token, and tool budgets;
• the completion test;
• the escalation condition.

This is not prompt ceremony. It is how you prevent a capable model from making locally reasonable choices that break the larger workflow.

Keep the objective small enough that one worker can own it. If a task needs three different definitions of “done,” it probably needs three delegations.

Separate Scope From Authority

Scope says what the agent should work on. Authority says what it can do to the world. Those are different controls.

A support agent may be scoped to resolve a billing question but authorized only to read the account and draft a response. Issuing a refund is a separate capability. A coding agent may inspect an entire repository but write only to one package. A research agent may browse approved domains but must not send messages or create accounts.

Model instructions are not enough. Enforce authority in the tool layer with allowlists, path boundaries, transaction limits, and approval gates. If the agent can call an unrestricted payment tool, “do not spend more than $50” is a hope dressed as policy.

For side effects, include idempotency. Every operation should carry a stable task ID, target, and expected precondition. A retry after a timeout must not create a second ticket, charge, deployment, or calendar event.

Define the Handoff Payload

A child agent’s final answer should be data the parent can evaluate, not a victory speech. Use a compact schema such as:

{
  "status": "complete",
  "artifacts": ["path-or-record-id"],
  "evidence": ["check-result-or-source"],
  "assumptions": [],
  "risks": [],
  "next_action": null
}

The schema can vary, but evidence and assumptions should not be optional concepts. If a worker changed code, return the files and test results. If it researched a claim, return the sources and confidence. If it could not finish, return the exact blocker and the safe state left behind.

Do not let “needs review” become a garbage chute. State what must be reviewed and why. A useful handoff might say that all schema tests pass but one pricing claim relies on a cached vendor page. The parent can act on that. “Please double-check” is just anxiety forwarding.

Prevent Ownership Collisions

Parallel agents create speed only when their work is independent. Before spawning, assign exclusive ownership by file, component, record set, customer, or analytical question.

Shared work needs a merge strategy. For code, that may mean separate branches or non-overlapping paths. For data, use optimistic concurrency with record versions. For documents, designate one synthesizer and keep researchers read-only.

The parent remains accountable for integration. Child agents should not independently merge, deploy, or announce completion unless the contract explicitly grants that authority. The system needs one place where conflicting assumptions are reconciled.

Maintain a task ledger with states such as queued, running, waiting, complete, and failed. Store the owner, contract version, parent task, start time, budget consumed, and final artifact. This makes abandoned work and duplicate execution visible.

Verify at the Boundary

Never accept a delegated result because the worker sounds confident. Run deterministic checks where possible: schema validation, tests, file existence, HTTP status, row counts, policy checks, and diff review.

Use a risk-weighted review ladder. Read-only summaries may need citation sampling. Reversible internal edits need tests and a diff. External messages, money movement, access changes, and deployments need stronger preconditions and often human approval.

The parent should reject results that violate the contract even when the output looks impressive. A complete comparison with fabricated sources is failed work. A passing feature that edits forbidden files is failed work. Boundaries are part of quality.

Multi-agent architecture is not about creating a digital org chart. It is about partitioning work without partitioning accountability. Define the contract, constrain authority, demand evidence, and verify the handoff. Otherwise you did not delegate a task—you multiplied ambiguity.