AI Agent Delegation: Define Contracts and Handoffs

Business and technology leaders should not let an AI agent delegate production work merely because an orchestration platform can route a message to another agent. Delegation transfers a bounded assignment, some authority, and an obligation to return verifiable work. Before autonomous delegation begins, the business needs a written contract for every task class, a controlled handoff package, an accountable acceptance decision, and a tested response when the chain fails.

The production gate is simple: if the delegating agent cannot state the goal, choose a currently qualified delegate, limit its authority and data, predict the cost and deadline, specify observable acceptance criteria, and preserve evidence through every handoff, it may not subdelegate autonomously. A human or a deterministic workflow should decompose, assign, or approve the work instead.

What Google’s August 21 guidance changes

Google Cloud's August 21, 2026 guidance on agent delegation describes four practical principles: decompose work until it can be verified, choose a delegate with the right capability and cost profile, share only the permissions and context required for the assignment, and introduce deliberate friction when an apparently acceptable request may carry ambiguous or harmful intent. Google calls the first principle contract-first decomposition.

That framing moves multi-agent design beyond a diagram of specialists connected to an orchestrator. An orchestrator that forwards a vague goal, its entire context window, and a broad credential has not delegated intelligently. It has distributed uncertainty and privilege. Every additional handoff can widen the gap between the business owner's intent and the action eventually taken.

Google's guidance is based on the Google DeepMind Intelligent AI Delegation paper, submitted in February 2026. The paper proposes an adaptive conceptual framework covering task allocation, authority, responsibility, accountability, role boundaries, intent, trust, monitoring, and verification. It is research—not a binding standard, product certification, or proof that current agents can manage every delegation safely. Leaders should use it to ask better design questions, then validate their own controls against the actual models, agents, tools, data, and business consequences in production.

A related Google DeepMind agent-security paper reinforces an important limitation: multi-agent systems remain an active research area, and adding agents does not automatically increase capability or safety. More participants mean more identities, interfaces, failure modes, context loss, and opportunities for an accountability gap. The right starting question is not how many agents can collaborate. It is whether one carefully bounded delegation is safer and more dependable than the current process.

Delegation is more than routing, calling, or parallelizing

A model call asks a system to generate an output. A tool call invokes a defined function. Parallelization runs known tasks at the same time. Delegation is different because a delegator decides what work another party should perform and may transfer limited discretion over how to complete it. If the delegate can choose tools, request data, create subtasks, spend money, communicate externally, or act on a system, the handoff carries authority and responsibility—not just text.

This distinction matters for human handoffs too. An AI agent can draft a recommendation for an employee without transferring decision authority. A human can assign a calculation to an agent while remaining responsible for verifying the result. Another agent can perform a read-only lookup but may not inherit the orchestrator's ability to change a customer record. State the relationship explicitly: advise, propose, execute, approve, or communicate. Do not let the implementation infer it from a prompt.

The eleven-clause delegation contract

Use this matrix as an acceptance contract for each repeatable delegation type. Replace role labels with named owners or on-call groups, attach machine-enforceable limits where possible, and version the contract with the workflow. A prose prompt does not pass the gate unless the runtime can enforce its authority, data, budget, deadline, and stopping boundaries and the verifier can evaluate the returned evidence.

1. Decompose work into bounded, verifiable tasks

Start with the business outcome and separate it into units that have an observable finish. A useful task can be assigned independently, has identified inputs, produces a defined artifact or action proposal, and can be accepted without reconstructing the delegate's hidden reasoning. If success depends on taste, context-sensitive judgment, or an unmeasurable instruction such as “handle this appropriately,” decompose again or reserve that node for a person.

Decomposition should follow risk as well as workflow structure. Separate research from recommendation, recommendation from approval, approval from execution, and execution from external communication when their consequences differ. A single agent should not gather evidence, decide whether its own conclusion is correct, approve the exception, update the system of record, and notify the customer unless the business has deliberately accepted that concentration of authority.

Set limits on task duration, delegation depth, number of children, and allowed sequence. A task that remains open indefinitely or can spawn an unbounded tree is not bounded. For work that legitimately runs for hours or days, apply the owner, checkpoint, maximum-runtime, spend, state, recovery, and approval controls in the ITECS guide to long-running AI agents.

2. Match each task to a verified capability

Assign work using evidence from the exact task class, not a model's reputation or an agent's self-description. Record which input types, tools, output schemas, languages, risk levels, and volume the delegate has passed; the model, prompt, tool, and evaluation versions; when the evaluation ran; current service availability; expected latency; and cost per accepted task. A capability can expire when any of those elements changes.

The current Agent2Agent Protocol specification defines Agent Cards for declaring skills and optional capabilities, plus tasks, messages, states, and artifacts for interoperable work. Those declarations help discovery and protocol compatibility. They do not replace business evaluation. Verify that the claimed delegate can complete representative and adversarial examples under the permissions, latency, and load it will receive in production.

Use the smallest capable delegate, not reflexively the largest model. A deterministic service may be better for arithmetic or policy lookup; a fast model may be sufficient for classification; a frontier model may be justified for ambiguous synthesis; a person may be the only acceptable owner of a judgment or irreversible decision. Match capability, consequence, latency, availability, and total cost to the assignment.

3. Specify the complete assignment before execution

Give every delegation an immutable task ID and parent ID, the contract version, goal, expected output, allowed inputs, named delegate, authority boundary, data limits, resource budget, deadline, checkpoints, acceptance criteria, verifier, and failure policy. State exclusions and prohibited actions. Specify whether the delegate may ask questions, call tools, create subtasks, retain state, or communicate with another party.

Acceptance criteria must be observable. “Produce a good answer” is not a contract. “Return a JSON object that matches schema version 4, includes a source reference for every eligibility factor, contains no restricted fields, calculates the amount within the approved tolerance, and receives approval from the refund owner” is testable. For probabilistic work, define an evaluated threshold, allowed uncertainty, review requirement, and behavior below the threshold rather than pretending every result is objectively correct.

Declare the budget in the same unit the owner manages: token and tool spend, elapsed time, API calls, records processed, transactions proposed, human-review minutes, or a combination. A deadline without a checkpoint can hide stalled work; a budget without a hard cap can fund repeated failure. Name who may extend either boundary and require that decision to enter the task record.

4. Issue least privilege only for the assignment

Give each agent a dedicated workload identity where the platform supports it, then issue short-lived, task-scoped access to the smallest set of records, fields, tools, actions, and destinations required. Do not pass the orchestrator's general credential, full conversation history, customer portfolio, shared mailbox, or administrative token because a subtask needs one record. Retrieve approved context at the boundary and return references rather than duplicating sensitive data across every agent's memory.

Subdelegation must attenuate privilege: a delegate cannot grant a child more authority than it received, and should usually grant less. If a research agent may read approved product records, its summarization subagent does not inherit the ability to update them. High-impact actions should use just-in-time authorization and an independent approval token tied to the exact task, action, target, amount, and expiration.

Treat data rules as contract fields, not a general policy link. Specify allowed sources, classifications, recipients, processing region, retention, redaction, logging, and prohibited use. The ITECS Data & AI Readiness Audit maps the systems, identities, owners, and data boundaries needed to make those limits enforceable before production access is issued.

5. Require evidence with every handoff

A handoff should return a result and the evidence needed to judge it. At minimum, retain the task and parent IDs, contract version, output artifact or action proposal, source references and versions, material tool calls and results, assumptions, exceptions, approvals, resource use, timestamps, delegate identity, model and prompt version, and known uncertainty. The receiving party should explicitly accept, reject, request correction, or escalate it.

Evidence is not a transcript dump. Copying every prompt and sensitive payload into a broadly accessible log creates another exposure while still failing to prove which record drove a decision. Store protected payloads in their approved systems, use stable references and integrity checks where appropriate, restrict evidence access by role, and retain only what the business, security, legal, privacy, and operational owners require.

Do not assume the coordination protocol is the audit system. The current A2A specification warns that a reconnecting streaming client may miss status updates and that critical information should not rely on messages alone; message persistence must be separately negotiated. Persist the business contract, authorization, artifacts, approvals, and final disposition in a durable system of record even when a protocol supplies task history.

6. Preserve responsibility and accountability across the chain

Name one business owner accountable for the workflow and one operator responsible for its technical control. Delegation can distribute work, but it should not erase responsibility. The immediate delegator remains responsible for choosing an eligible delegate, issuing the correct contract and permissions, monitoring the task, verifying the handoff, and taking the assigned failure response. A delegate that creates a child task assumes the same responsibility for that handoff.

The final record should answer who requested the work, who decomposed it, who delegated each task, which identity performed it, who verified each artifact, who approved each high-impact action, and who accepted the business outcome. “The agent decided” is not an owner. Agents cannot accept corporate risk, bear legal responsibility, or resolve an accountability dispute; authorized people and operating functions must retain those duties.

Keep humans actively engaged in the decisions they own. If automation removes every routine review, employees may lose the context and skill needed to detect an abnormal output when escalation finally occurs. Use sampled review, exception analysis, calibration exercises, and periodic manual operation so oversight remains a capable control rather than a ceremonial click.

7. Predefine retry, reassignment, escalation, and stop

Classify failures before the workflow runs. Retry only when the failure is transient, the operation is idempotent or its side effects can be proven absent, and the retry count and spend remain inside the contract. Reassign when the chosen delegate lacks current capability, capacity, availability, or the required tool. Escalate when the task is ambiguous, evidence conflicts, acceptance fails repeatedly, a human judgment is required, or the consequence exceeds the automation threshold.

Stop and contain the chain when an agent attempts an unauthorized action or subdelegation, accesses prohibited data, loses its evidence link, reaches the maximum runtime or budget, encounters a security signal, cannot prove the state of a potentially irreversible action, or receives a cancellation. Stop signals must propagate to children, revoke task credentials, freeze new side effects, preserve evidence, and hand control to the named owner.

Set a maximum retry count, delegation depth, child count, and recovery window. Prevent two agents from bouncing rejected work between them indefinitely. If an incident or near miss occurs, use a defined reporting and preservation path such as the ITECS AI agent incident playbook, with facts separated from hypotheses and corrective controls assigned to owners.

8. Log the full delegation chain

Use a traceable parent-child structure rather than isolated chat sessions. Each event should record the task, parent, actor identity, contract and policy version, permission grant and revocation, input references, material tool calls, state change, checkpoint, handoff artifact, verifier decision, approval, failure, recovery action, and final disposition. Synchronize timestamps and protect logs from routine agent modification.

Make the chain understandable to operations, security, privacy, legal, internal audit, and the business owner without requiring private model reasoning. Dashboards should show work in progress, age, spend, retry count, delegation depth, failed acceptance, missing evidence, policy denials, unusual data access, and stopped or orphaned children. Alert on conditions that require a person, not merely on infrastructure errors.

Version the workflow as a production system. The ITECS AI DevOps operating model connects agent, model, prompt, retrieval, tool, evaluation, permission, and policy changes to releases, observability, incidents, and rollback. Without that release identity, the organization may know a task failed but not which system behavior produced it.

9. Test failures before autonomous delegation

Build an evaluation harness around the contract, not just the final answer. Inject malformed and missing inputs, stale and conflicting records, false capability claims, an unavailable or slow delegate, an unsupported schema, a failed tool, rejected artifacts, a budget overrun, duplicate delivery, prompt injection, overbroad access, unauthorized subdelegation, a broken evidence reference, a late human approver, and a cancellation after a child task starts.

For every scenario, assert the permitted side effects, required evidence, maximum spend and elapsed time, correct retry or reassignment, escalation recipient, stop propagation, credential revocation, and final task state. A test fails if the output happens to look acceptable while the agent used prohibited data, skipped approval, exceeded authority, lost provenance, or left a child running.

Progress from a sandbox to shadow mode, then to read-only production data, proposed actions, a narrow reversible action, and finally the approved autonomy level. Require fresh tests after a change to the contract, model, prompt, agent, tool, data source, identity, policy, evaluator, or downstream system. Autonomous subdelegation should be earned per task class, not enabled once for an entire platform.

A controlled customer-refund example

Consider an illustrative customer-support workflow, not an ITECS client case. An orchestrator receives a refund request and creates separate contracts: a read-only eligibility agent retrieves the approved order and policy records; a calculation service proposes an amount; a risk agent checks defined exception signals; a human approves amounts above a threshold or any policy conflict; and a communications agent drafts the response but cannot send it until the acceptance record exists.

Each handoff carries the task and parent IDs, source references, policy version, calculation, uncertainty, tool evidence, spend, and acceptance state. The eligibility agent receives one customer's approved fields, not the entire CRM. The communications agent receives the accepted decision, not payment credentials. No child can enlarge its scope or delegate again unless its contract permits it.

During testing, make the policy source stale, deny the order lookup, return conflicting customer IDs, time out the calculation, reject the artifact, exhaust the retry cap, remove the human approver, and send a stop after the payment proposal. The workflow passes only if it pauses or routes exactly as contracted, makes no duplicate or unauthorized change, preserves the evidence chain, and leaves a named owner with a clear recovery action.

A 30-day contract-first pilot

In week one, choose one recurring decision with measurable value and bounded consequences. Map its present human and system handoffs, define the business owner, split research, recommendation, approval, execution, and communication, and identify the one delegation that would remove the most delay without combining incompatible authority.

In week two, write the eleven clauses, assemble representative and adversarial cases, evaluate candidate delegates, and define pass thresholds. Provision dedicated identities and task-scoped permissions in a non-production environment. Decide which evidence belongs in the protected system of record and which metrics belong in operational monitoring.

In week three, implement checkpoints, evidence validation, acceptance, capped retries, reassignment, escalation, stop propagation, and credential revocation. Run failure injection until every test produces the expected task state and no unapproved side effect. Have business, security, privacy, operations, and the human approvers review the evidence they would actually receive.

In week four, run shadow mode against live-shaped work, compare accepted outcomes with the current process, and measure completed work, correction rate, decision time, reviewer effort, cost per accepted task, policy denials, failed handoffs, and recovery time. Permit only the next narrow autonomy level when the named owner accepts the evidence. Repeat for the next task class rather than expanding the first approval to every agent and workflow.

Google's August 21 guidance makes the management lesson explicit: better delegation begins with work that can be verified, a delegate suited to the task, restricted access, and enough friction to challenge bad or ambiguous instructions. The business implementation is a contract and custody chain. Define what is being transferred, limit the authority that travels with it, require evidence on the way back, preserve human accountability, and prove the failure path before the agents are allowed to choose one another.