AI Agent Task Delegation: Authority, Acceptance, and Closure

§ 01What Is AI Agent Task Delegation?

AI agent task delegation is a relationship in which a delegator creates a child task for a receiver, the receiver explicitly accepts a defined contribution, and the delegator remains responsible for integrating that contribution into the parent outcome.

The distinction is operational. A system can use the same API endpoint for all 6 interactions and still need different ownership, authority, state, and closure rules.

The delegator owns the parent outcome

The delegator must:

• decide why the child task is needed;
• select an eligible receiver;
• define the requested contribution;
• preserve the parent constraints;
• monitor the child state;
• review the returned evidence;
• integrate or reject the contribution;
• handle dependency and timeout effects;
• and close or escalate the parent outcome.

Delegation does not let the parent owner forget the task.

The receiver owns the accepted contribution

After acceptance, the receiver must:

• work inside the agreed scope;
• use only permitted sources, data, and tools;
• preserve provenance;
• surface missing inputs and conflicts;
• stop at the defined boundary;
• return the required artifact and evidence;
• and report failure without disguising partial work as completion.

The receiver does not gain the right to redefine the parent objective.

Delegation is not a handoff

In a handoff, defined ownership transfers after receiver acceptance. In delegation, the delegator keeps the parent outcome and expects a contribution back.

If the intended relationship is an ownership transfer, use the complete AI agent handoff protocol. Calling a transfer “delegation” creates two dangerous possibilities: both agents continue acting, or each assumes the other will close the work.

§ 02When Should One AI Agent Delegate to Another?

Delegate only when specialization, parallelism, permission separation, independent review, or capacity improves the accepted parent outcome enough to justify another coordination boundary.

The decision is not “more agents are better.” It is whether one additional boundary produces a more reliable, faster, safer, or less expensive accepted result.

Delegate for a measurable capability advantage

A role label is not evidence of capability. Use versioned evaluation results, accepted artifacts from similar tasks, tool and source coverage, domain error patterns, current policy eligibility, latency and capacity history, and known escalation behavior.

The manager-agent versus specialist-agent model separates coordination quality from domain quality. A manager may be excellent at routing research without being qualified to perform or approve the research itself.

OpenAI’s practical guidance on building agents distinguishes a manager pattern, where a central agent invokes specialists as tools and retains workflow control, from a decentralized pattern in which execution transfers through handoffs. That architectural difference should remain visible in the task relationship and closure record.

Delegate independent work in parallel

Parallelism helps when child tasks do not repeatedly wait on each other.

Examples: 4 market segments researched against one shared schema; 3 documents checked against the same evidence rule; 2 independent calculations reconciled by a parent owner; or 5 customer cohorts analyzed without modifying a shared record.

Parallelism hurts when every child needs continuous updates from every other child. The agents may spend more time reconciling context than producing the requested result.

Delegate to separate permission domains

One role may read support tickets but not billing records. Another may analyze approved billing fields but not contact customers. Delegation can preserve that separation if each child task is routed to the role that already has the minimum valid access.

Do not create a permission bridge in which the delegator forwards protected data or asks the receiver to act through the delegator’s identity.

Keep tightly coupled work together

Avoid delegation when the task cannot be expressed as a typed contribution; the output cannot be reviewed independently; every decision depends on private or rapidly changing context; the receiver needs the delegator’s full credentials; the cost of a stale result is material; or no one can integrate the child result into the parent.

Anthropic’s account of its multi-agent research system found that vague subagent instructions caused duplicated searches, misunderstood scope, and coverage gaps. Its production prompts give each subagent an objective, output format, tool and source guidance, and clear boundaries.

§ 03What Must an AI Agent Delegation Contract Contain?

A delegation contract should let the receiver decide whether to accept and let the delegator later determine whether the returned contribution is usable.

These are field groups, not necessarily 14 flat strings. Sources, artifacts, approvals, and tests may each be collections of typed records.

The full AI employee collaboration model explains how delegation fits beside consultation, review, handoff, approval, notification, and escalation.

Define one typed contribution

Weak: “Research this account and tell me anything useful.”

Stronger:

Return account_evidence_v2 with company identity, 3 current initiatives, 2 verified triggers, 5 source records, contradictions, and a qualified, not-qualified, or human-review recommendation. Do not contact the account or change CRM fields.

The stronger request exposes output, evidence, boundaries, and prohibited actions.

State non-goals beside the goal

Non-goals prevent a capable receiver from expanding the assignment in a plausible but unwanted direction.

Examples: analyze the current account, not its entire industry; produce a recommendation, not an external message; inspect the specified branch, not redesign the application; reconcile approved ledger fields, not file a return; or summarize the policy, not give final legal advice.

Make acceptance testable

Definition of done should name observable conditions: schema validates; required fields are present; every material claim maps to a source; calculations reproduce; prohibited actions are absent; uncertainty is typed; artifact version is fixed; and the receiver stayed inside budget and authority.

“High quality” is not an acceptance rule until the required qualities can be observed.

§ 04How Should the Delegator Select the Receiving Agent?

Use two stages: eligibility first, ranking second.

An ineligible agent must not win because it is fast, cheap, or historically accurate. Identity, purpose, access, and policy are hard gates.

Only eligible receivers enter ranking.

Maintain a versioned capability registry

For each role, record the capability ID and version, supported task types, required and prohibited inputs, output schemas, tool and source coverage, permission ceiling, sensitivity ceiling, expected latency range, concurrency limit, current status, evaluation date, and escalation route.

Refresh the record after a model, prompt, tool, policy, retrieval, or workflow change. A role that passed last month may not be equivalent after its source set or permissions change.

Rank against the current task

A starter routing score can be:

routing score = 0.30 x capability fit + 0.20 x evidence quality + 0.15 x delivery reliability + 0.15 x context fit + 0.10 x available capacity + 0.10 x cost fit

The weights are a starting design, not a universal formula. Apply hard identity, authority, sensitivity, and policy gates before the score.

Prefer a known role for consequential work

Dynamic discovery can help with low-risk research or media production. High-impact work should use an allowlisted receiver whose identity, owner, capability version, access, test history, and incident route are known.

If no eligible receiver exists, the correct result is no-route, not assignment to the least unsuitable agent.

§ 05How Should the Receiving Agent Accept or Reject Delegated Work?

The receiver should inspect the exact contract version and return one explicit decision before beginning work.

Silence, reading the request, reserving capacity, or making a tool call is not acceptance.

Acceptance binds the current version

Record the delegation ID, child task ID, receiver identity and role version, accepted contract hash or version, accepted scope, accepted authority, deadline and budget, acceptance timestamp, and conditions or declared limits.

A material change to scope, source set, output, authority, deadline, or sensitivity requires amendment and renewed acceptance.

Clarification pauses the start clock

Clarification-required should identify the blocking defect: a missing source; a conflicting deadline; an unsupported artifact type; an unavailable tool; a prohibited data class; an unclear acceptance rule; or insufficient budget.

Do not let the receiver silently guess. The delegator can amend, cancel, reroute, or escalate.

Protocol acknowledgement is not business acceptance

The current Agent2Agent (A2A) Protocol specification defines a submitted state as a task that has been successfully submitted and acknowledged. It also defines working, input-required, completed, failed, canceled, and rejected states.

A transport-level acknowledgement does not necessarily prove that the receiver accepted your organization’s scope, authority, deadline, cost, and closure duties. Record those operating semantics in your task contract.

§ 06Who Owns Authority After Delegation?

The receiving agent acts through its own identity and the narrowest authority that satisfies the child task:

effective child authority = receiver role authority ∩ delegator's permitted delegation scope ∩ task-specific grant ∩ current policy ∩ valid parameter-bound approval

The intersection can only preserve or reduce authority. Delegation must not create a permission neither party held.

Pass grants, not credentials

Keep reusable secrets out of the task packet. Do not include API keys, passwords, OAuth refresh tokens, browser session cookies, private keys, broad bearer tokens, or reusable approval secrets.

Use scoped, short-lived, audience-bound access where the system supports it. The receiver should be independently identifiable in logs.

Reauthorize at the child boundary

The delegator may be allowed to request research but not authorize a payment. The receiver may be able to draft a refund but not execute it. Check both the relationship and the specific action at runtime.

NIST’s 2026 Software and AI Agent Identity and Authorization work highlights agent identification, authorization, access delegation, action logging, and data-flow provenance as core enterprise concerns, and describes linking human identities to agents so delegation controls preserve accountability.

Bind approvals to exact parameters

An approval should identify the artifact version, action type, system, recipient or object, amount or scope, environment, expiry, approver, and the number of permitted uses.

Changing any material parameter invalidates the approval. The AI employee permissions guide provides the full action-level model.

§ 07What Context Should Travel With a Delegated Task?

Send the smallest context bundle that lets the receiver complete and substantiate the child contribution.

Context is not a memory dump. More context can introduce stale facts, hostile instructions, irrelevant preferences, cross-customer data, and conflicting versions. The shared versus role-specific memory architecture governs which durable objects may cross the boundary at all.

Separate fact, decision, and working state

Type each item: source fact; approved policy; human decision; accepted artifact; agent observation; working hypothesis; open conflict; or customer instruction.

The receiver should know which objects are authoritative, which require validation, and which must not become durable.

Pass references when the source remains authoritative

A source reference lets the receiver retrieve the current permitted version and preserves provenance. Copy content only when the source will not remain available; a stable snapshot is required; the receiver cannot access the source directly; or the exact supplied text is part of the evidence.

Record the snapshot date and source version when copying.

Preserve contradictions

Do not resolve conflicting sources by silently selecting one. Send both source IDs, the conflicting fields, their dates and owners, the governing source hierarchy, and the decision owner.

The receiver can then return input-required or an explicitly conditional result.

§ 08What Task States Should Delegation Use?

Use durable states with defined entry evidence, allowed transitions, and owners.

Do not use “done” for delivered, accepted, integrated, and parent-closed. Each event needs its own meaning.

Child completion does not close the parent

A research role can complete a source brief while the parent campaign still requires drafting, approval, publication, and measurement.

Record at least: child delivered; child accepted; child integrated; parent outcome accepted; and parent outcome closed.

State must survive a disconnected conversation

The A2A specification supports polling, streaming, and push notifications for asynchronous tasks and distinguishes messages from artifacts. It also warns that not every transient message is guaranteed to persist in task history.

Critical scope, authority, decisions, artifact identity, and closure therefore belong in authoritative task or artifact records, not only in conversational messages.

Make events ordered and idempotent

Each event should have an event ID, delegation and child IDs, prior state, new state, actor, timestamp, contract/artifact version, reason code, and idempotency key.

Reject duplicate or invalid transitions. A delayed working event must not reopen a terminal canceled task.

§ 09How Should Timeouts, Retries, Cancellation, and Budgets Work?

Every delegation needs separate acceptance, progress, delivery, and review timers.

These values are starter controls, not universal thresholds. Set them from task risk, reversibility, service commitments, and observed latency.

Retry only after a relevant condition changes

A retry is justified when a temporary service recovered; missing input arrived; an invalid parameter was corrected; a new eligible receiver is selected; or a bounded transient failure is documented.

Repeating the same prompt, model, sources, tools, permissions, and conditions is usually repetition, not recovery.

Cancellation must stop downstream work

Cancellation should:

1. record the authorized cancel event;
2. stop new tool calls and child creation;
3. revoke task-scoped grants and approvals;
4. identify any external action already committed;
5. preserve partial artifacts and logs;
6. notify affected parent/dependency owners;
7. and enter a terminal state only after containment is confirmed.

An expired user interface does not prove the receiver stopped.

Return partial work after failure

A failed receiver should return completed steps, uncompleted steps, current artifact versions, source and tool records, external side effects, spent budget, active approvals or grants, blockers, and a recommended recovery state.

The delegator should not restart the entire child and duplicate already committed actions.

§ 10What Should the Receiving Agent Return?

Return a result package, not a success message.

The result should be attributable to the receiver version that produced it.

Put outputs in artifacts

The A2A specification says messages should not be used to deliver task outputs; results should be returned as artifacts associated with the task. The principle applies outside A2A as well: conversational status is useful, but the durable result needs identity, version, and retrieval.

Version every material return

If a receiver repairs an artifact, create v2; do not silently overwrite v1.

The review record should bind to the artifact ID, version, hash, schema version, source snapshot, receiver version, and evaluation version. A later artifact invalidates acceptance unless the review explicitly covers it.

Report uncertainty as structured data

Useful uncertainty fields include: unknown; conflict; assumption; missing source; stale source; unresolved dependency; confidence basis; materiality; and an escalation recommendation.

A confidence percentage without a basis is not enough.

§ 11How Should the Delegator Review and Close Delegated Work?

Review in layers. A fluent artifact can still be structurally invalid, unsupported, unauthorized, or unusable inside the parent outcome.

A child can pass the first 5 gates while the parent outcome still fails.

Keep self-check and acceptance distinct

The receiver should validate its own schema, sources, calculations, and policy before delivery. That is production hygiene, not final acceptance.

For low-risk work, the delegator may review and accept the child. For consequential or specialist work, use an independent domain reviewer or named human. The AI manager control test explains where AI review can remain bounded and where human accountability must stay visible.

Request repair by defect

A repair request should name the failed gate, reason code, affected artifact version, exact defect, required change, unchanged constraints, repair deadline, and remaining attempt/budget.

Do not ask “try again” when the system can identify what failed.

Close with evidence

A child closure record should contain the terminal state, accepted artifact version, reviewer and acceptance event, authority result, residual uncertainty, downstream integration record, total cost and time, and the parent task ID.

The parent closes only after its own acceptance rule passes.

§ 12How Do You Prevent Delegation Loops and Cascading Failures?

Treat every inter-agent boundary as an untrusted boundary, including requests from a manager.

OWASP’s AI Agent Security guidance identifies prompt injection, tool abuse, privilege escalation, data exfiltration, memory poisoning, excessive autonomy, cascading failures, and denial-of-wallet risks, and its abuse-case matrix includes recursive tool abuse, approval bypass, and multi-agent chaining.

The complete multi-agent failure-containment model shows how a defective child result can gain reach through fan-out, false consensus, shared memory, repeated actions, captured review, and premature parent closure.

Validate structure before meaning

Apply deterministic checks first: schema; allowed relationship; known identity; contract version; signature or transport authentication; nonce and expiry; object scope; content type; size limits; and state-transition validity.

Then apply semantic and domain review.

Enforce controls outside the model

Do not rely on an instruction such as “never exceed your permissions” as the authorization system.

Enforce authentication, authorization, data isolation, approval validity, action limits, network and tool policy, rate limits, budget, and terminal-state rules in deterministic, auditable components.

NIST’s agent hijacking evaluation work describes the risk created when trusted instructions and untrusted task data are not clearly separated. Delegation increases the number of boundaries at which hostile data can be mistaken for authority.

Cap the complete chain

Set maximum delegation depth, children per parent, concurrent children, tool calls, retries and repairs, elapsed time, spend, external actions, and one circuit-breaker owner.

The cap should apply across the parent and all descendants, not restart at each child.

§ 13What Does a Complete Delegation Look Like?

Consider a Growth Manager that owns a weekly account-prioritization outcome and delegates evidence collection to a Research Specialist.

Offer the exact child task

yaml delegation: delegation_id: del_2026_0724_118 parent_task_id: weekly_accounts_2026_w31 child_task_id: account_research_acme_014 relationship: delegation ownership: parent_owner: growth_manager_v4 child_owner_after_acceptance: account_research_v6 outcome: contribution: account_evidence_v2 non_goals: [crm_write, outreach, final_qualification] inputs: account_id: acme_014 source_policy: public_and_approved_owned_v3 output: schema: account_evidence_v2 destination: artifact_store authority: data: [public_web, approved_owned_pages] tools: [web_search, document_write] actions: [read, create_artifact] time: accept_by: "2026-07-24T17:10:00Z" due_by: "2026-07-24T18:30:00Z" limits: max_searches: 12 max_repairs: 1 closure: child_reviewer: growth_manager_v4 parent_owner: growth_manager_v4

The YAML is one way to express the operating contract. Production systems may use JSON, database objects, signed events, queues, or an agent protocol.

Record acceptance separately

The receiver verifies the account exists; the source policy is accessible; the schema is supported; the deadline is feasible; the allowed tools are sufficient; prohibited actions remain unavailable; and the child reviewer is known.

It then accepts the exact contract version or returns a typed defect.

Return evidence, not a verdict alone

The specialist returns the artifact ID and version, company identity evidence, 3 initiative records, 2 trigger records, 5 or more source records, conflicting evidence, unknowns, source dates, the validation result, and actual cost/time.

The specialist does not change CRM state or decide the final 20-account list.

Close at two levels

The Growth Manager:

1. validates the child schema;
2. checks sources and conflicts;
3. accepts or repairs the child;
4. integrates all accepted account records;
5. applies the parent prioritization rule;
6. routes any consequential decision to a person;
7. and closes the weekly parent only when the accepted 20-account outcome exists.

That sequence preserves both specialist accountability and parent ownership.

§ 14Which Metrics Show Whether Delegation Works?

Measure the boundary and the parent outcome.

Do not optimize child throughput while parent acceptance falls.

Calculate the complete funnel

Suppose 100 offers produce 92 receiver acceptances, 84 deliveries, 76 first-pass child acceptances, and 72 accepted parent outcomes.

Then: offer acceptance is 92 / 100 = 92%; delivery among accepted is 84 / 92 = 91.3%; first-pass acceptance is 76 / 84 = 90.5%; and parent yield is 72 / 100 = 72%.

Each local rate looks usable, but 28 of 100 parent outcomes still fail or remain unresolved. Improve the weakest boundary before adding more children.

Compare against one-agent work

Run the same representative cases with one agent; one agent plus deterministic tools; one delegator and one specialist; and human production where a baseline exists.

Compare accepted parent quality, elapsed time, cost, human minutes, serious defects, and recovery - not only output volume.

Use non-compensating safety gates

An average quality gain must not offset an unauthorized action, protected-data disclosure, uncontrolled external communication, a missing accountable owner, unreconstructable state, or an inability to stop the chain.

Treat those as separate release gates.

§ 15What Delegation Evaluation Should You Run Before Production?

Start with a 24-case pack that tests the pair and the boundary.

Use production-shaped schemas and tools, but synthetic or safely isolated data.

Score the pair, not only each agent

The delegator can pass routing tests and the receiver can pass domain tests while their interface fails.

Evaluate contract completeness, correct acceptance decisions, context sufficiency, authority intersection, result schema, evidence integrity, state ordering, timeout ownership, child acceptance, parent integration, and closure.

Test negative behavior

A safe receiver must reject work when identity is unknown; the task type is unsupported; required authority is absent; the source policy is invalid; data sensitivity exceeds its role; budget is insufficient; the contract version is stale; or the request asks it to bypass another role’s denial.

Correct refusal is a success case.

Precommit pilot gates

Before running the 24 cases, define the minimum parent yield; maximum clarification and misroute; zero-tolerance authority defects; maximum human coordination minutes; maximum timeout and repair; maximum spend; and the conditions that stop the pilot.

Do not select thresholds after seeing the results.

§ 16How Should You Roll Out AI Agent Delegation?

Introduce the contract and evidence before autonomous routing.

Promotion is earned per task type and delegation edge, not per model name.

Choose one reversible workflow

Strong pilots include a research brief for a content owner; account evidence for a sales manager; a test report for a coding owner; a reconciliation proposal for a finance reviewer; or a draft response for a support owner.

Avoid payments, access grants, deletion, publication, legal conclusions, high-value remedies, and other irreversible or high-impact outcomes as the first delegation.

Expand one dimension at a time

Change only one: task type; receiver; capability version; source class; tool; data sensitivity; action tier; concurrency limit; or delegation depth.

Rerun affected evaluation cases after each material change.

Freeze on boundary defects

Pause expansion when ownership is ambiguous; agents bypass the contract through chat; permissions expand; state cannot be reconstructed; duplicate actions occur; serious false acceptance appears; or human coordination rises faster than accepted output.

Contain and repair the boundary before increasing volume.

§ 17How Does CellCog Support AI Agent Delegation?

CellCog publicly describes two delegation surfaces: AI Employees assigning work within an AI organization, and external agents assigning work to CellCog through its Agent-to-Agent platform.

Current first-party operating evidence

As of July 24, 2026, CellCog’s live AI Organization showed 1 human founder, 9 active AI employees, and 1 AI Sales Lead managing 5 sales representatives, alongside cumulative operating counts for completed shifts, closed tasks, emails, and dashboard updates.

CellCog says the Sales Lead delegates a task to a representative’s board with context attached, the representative works it on the next shift, and the result returns to the manager. CellCog also reports a 6x outbound-throughput increase and a 1.5% bounce rate after the five-representative team formed.

These are dated, first-party operating records. They show that CellCog is publicly operating a manager-to-worker delegation pattern; they do not establish a universal performance benchmark or independently verify every control in this protocol.

External-agent delegation

CellCog’s Agent-to-Agent platform says OpenClaw, Claude Code, Cursor, and custom agents can delegate research, document, media, coding, and application work through an API, SDK, plugins, integrations, and skills. A calling agent submits a task and receives a finished artifact.

That makes CellCog relevant when an AI employee needs another standing role; a coding agent needs a research, document, or media capability; or a custom agent needs a programmatic execution layer.

Verify the complete operating boundary

Before production delegation, ask for evidence of: distinct delegator, receiver, user, tenant, and role identifiers; parent/child IDs, relationship, state, and event ordering; explicit receiver acceptance with contract versions; per-agent authority scopes with runtime policy checks; whether child agents ever receive reusable caller secrets; artifact versioning and provenance; approval parameter binding; retry idempotency; cancellation semantics; searchable audit events; recovery paths; and task-specific evaluation results.

The public pages establish delegation positioning and visible operating examples. Your workflow still needs proof for its exact identity, authority, data, state, acceptance, and recovery requirements.

§ 18What Is the AI Agent Delegation Implementation Checklist?

Ownership and relationship

• Parent task has one owner.
• Child task has a stable ID.
• Relationship is explicitly delegation.
• Delegator retains parent closure.
• Receiver owns only the accepted child contribution.
• Handoff, review, approval, and escalation use different states.
• One named human remains accountable for consequential outcomes.

Contract and context

• Goal, scope, non-goals, and dependencies are explicit.
• Output schema and destination are fixed.
• Evidence requirements are testable.
• Sources and artifacts have IDs and versions.
• Facts, decisions, observations, and conflicts are typed.
• Context is minimized by purpose and sensitivity.
• Contract changes require versioning and renewed acceptance.

Identity and authority

• Receiver identity and capability version are known.
• Eligibility passes before ranking.
• Effective authority is an intersection, not inheritance.
• Receiver uses its own identity.
• No credentials appear in the packet.
• Approval is bound to exact parameters and expiry.
• Sensitive or high-impact action has independent review.

State and recovery

• Receiver can accept, reject, or request clarification.
• Acceptance, delivery, child acceptance, integration, and parent closure are distinct.
• Events are ordered and idempotent.
• Acceptance and delivery have separate deadlines.
• Retry and repair are capped.
• Cancellation revokes task-scoped grants.
• Partial work and external side effects survive failure.
• Human escalation and circuit-breaker owners are named.

Evaluation and economics

• Representative normal and negative cases exist.
• Authority defects are a non-compensating gate.
• Parent yield is measured.
• Human coordination minutes are measured.
• Full-chain cost includes routing, context, review, rework, and failure.
• One-agent and deterministic alternatives are compared.
• Material changes trigger regression testing.

§ 19Final Decision

AI agent task delegation is ready for production only when it behaves like an accountable child-task system rather than one model prompting another.

Before enabling an edge, answer: Who owns the parent? What exact contribution is being requested? Why is this receiver eligible? Which authority does the child actually have? Which context and evidence must travel? What event proves acceptance? What happens at timeout, cancellation, or failure? Who reviews the returned artifact? What evidence closes the child? What evidence closes the parent?

If any answer exists only inside a conversation, the delegation boundary is not yet durable.

Start with 1 delegator, 1 known receiver, 1 reversible task type, delegation depth 1, explicit acceptance, versioned artifacts, and a 24-case evaluation. Scale only when the complete parent outcome improves without hidden authority, duplicate action, or rising coordination debt.