Delegated Agent Work Needs a Return Contract

A task brief answers one half of delegation: what should the other agent try to do?

It does not answer the other half: what must come back for the delegator, a user, or a reviewer to decide whether the work is usable?

That distinction matters whenever the delegate is opaque. The receiving side may get progress updates, a text response, a document, structured output, or a task status. Those things are not interchangeable. A cheerful status update is not a deliverable. A returned file is not proof it meets the task. A successful terminal state is not acceptance.

Delegated agent work needs a return contract.

Protocol status, September 2026: The official A2A site identifies version 1.0.0 as the latest released specification. The protocol concepts below use that current version's task, message, artifact, and delivery semantics.

Protocols already separate communication from deliverables

The pinned A2A Protocol Specification 1.0.0 treats tasks, messages, and artifacts as separate concepts. It describes messages as task initiation, clarification, status, and task interaction; it says task outputs should be returned as artifacts. It also cautions that streaming clients may miss status messages after disconnect and that messages should not be treated as a reliable delivery mechanism for critical information.

That protocol separation encodes a useful product lesson:

• Object: Progress message — Useful for: Showing movement, a clarification need, or a status change — Insufficient as: A durable, reviewable result
• Object: Task state — Useful for: Locating work in its lifecycle — Insufficient as: A judgment that the result is correct or accepted
• Object: Artifact — Useful for: Returning a bounded output such as a document or structured result — Insufficient as: A guarantee that the output satisfies the original need
• Object: Acceptance decision — Useful for: Deciding whether a returned package may advance — Insufficient as: A replacement for the task's evidence and limitations

An implementation can use different names, but it should preserve the separation.

A Prompt Covers Only Half of the Contract

The June 2026 preprint Software Delegation Contracts: Measuring Reviewability in AI Coding-Agent Work studies a related problem in a small controlled setting. The study compared ordinary issue-style prompts with explicit delegation contracts and contracts that required evidence bundles across 64 executions and 192 reviews by three independent, condition-blinded model-based reviewers. In that pilot, the contracts improved evidence sufficiency and reduced reviewer ambiguity, while adding token and wall-clock cost. The paper reports reviewability gains rather than a correctness gain on its small, already-successful tasks.

That limitation is instructive. A return contract should not be sold as a magic quality switch. Its value is that it makes the required evidence, known limitations, and acceptance basis visible before work begins.

The Delegation Return Contract

A Delegation Return Contract is a proposed application-level agreement for how delegated work comes back. It is not a demand for hidden reasoning, a source-code dump, or a copy of every private trace. It is the smallest description needed to make a returned work package assessable.

• Contract element: Parent task and objective — Question it answers: Which user-visible goal does this delegation serve? — Why it matters: Stops a useful-looking artifact from drifting away from the original task.
• Contract element: Delegate and capability boundary — Question it answers: Which agent is doing the work, and what class of work is it expected to perform? — Why it matters: Keeps delegation distinct from an unlimited transfer of responsibility.
• Contract element: Authority and scope — Question it answers: What is in scope, out of scope, or subject to a separate approval? — Why it matters: Lets the return be reviewed against a meaningful perimeter.
• Contract element: Required deliverable shape — Question it answers: What artifact or structured result must be returned? — Why it matters: Prevents a transient message from being mistaken for the final work package.
• Contract element: Evidence and verification request — Question it answers: What concise evidence, checks, source links, or uncertainty labels should accompany the artifact? — Why it matters: Gives reviewers a basis for deciding what to verify next.
• Contract element: Delivery and availability posture — Question it answers: Where is the result attached, how is it versioned, and what happens if delivery is interrupted? — Why it matters: Separates work completion from reliable receipt.
• Contract element: Acceptance owner and criteria — Question it answers: Who decides whether the return can advance, and against what conditions? — Why it matters: Preserves a human or parent-agent decision boundary.
• Contract element: Residual-risk and limitation statement — Question it answers: What remains unknown, excluded, or dependent on later verification? — Why it matters: Makes an honest partial return useful instead of deceptively final.
• Contract element: Settlement rule — Question it answers: What happens on decline, expiry, cancellation, or rework? — Why it matters: Keeps task disposition explicit rather than leaving abandoned work ambiguous.

The contract starts before execution and finishes only when the returned package has an explicit disposition.

Keep progress, delivery, and acceptance on different rails

The most common delegation error is collapsing three events into one:

1. The delegate says it is done.
2. The receiver has a durable artifact.
3. The work has been accepted.

These events can occur at different times and can have different outcomes. A delegate may finish work but fail to deliver a usable artifact. A delivered artifact may reveal a limitation. A reviewer may accept it, request revision, defer it pending evidence, or reject it as outside scope.

An honest agent system should be able to say which event happened:

• “The delegate reported progress.”
• “The task returned an artifact and an evidence summary.”
• “The acceptance owner has not yet verified the result.”
• “The return was accepted for this bounded purpose.”

This vocabulary does not slow down simple work. It prevents a higher-consequence workflow from borrowing certainty from a lower-consequence signal.

Make the artifact legible without demanding private internals

Agent-to-agent coordination can preserve an implementation boundary: the receiving side can evaluate a task, artifact, and evidence package without standardizing the delegate's internal plans, memory, or tools. That is an architectural inference from A2A's external task, message, and artifact interfaces, rather than a protocol guarantee about every implementation.

Reviewability does not require the opposite. A return contract can ask for:

• a clear artifact identity and intended use;
• the scope the delegate says it addressed;
• compact evidence relevant to acceptance;
• known limitations and unresolved dependencies; and
• the next decision the receiving side should make.

It should not require raw chain-of-thought, credentials, private prompts, internal URLs, or a full transcript by default. The right output is an accountable work package, not total introspection.

Contract detail should follow consequence

Not every agent-to-agent task needs the same paperwork. A useful gradient is:

• Task consequence: Low-consequence research or drafting — Suitable return contract: Objective, bounded artifact shape, source or uncertainty label, and a clear draft disposition
• Task consequence: Code or operational recommendation — Suitable return contract: Add scope, verification evidence, limitations, and explicit acceptance criteria
• Task consequence: Consequential external proposal or effect — Suitable return contract: Add current authority, a distinct confirmation boundary, delivery verification, and a clear rule for abandonment or rework

The point is not to make delegation bureaucratic. It is to spend review effort where ambiguity would otherwise become expensive.

A return contract complements, rather than replaces, a handoff

For coding work, a review handoff may include changed files, validation results, and residual risk. That remains valuable. The return contract is broader: it applies when the delegate is another agent system, the result is not necessarily code, and delivery travels through a task protocol.

The handoff describes a package for a specific reviewer. The return contract describes the lifecycle between request, artifact, evidence, and acceptance. They should fit together, not compete.

Start by making acceptance explicit

Teams can adopt this model without inventing a new protocol. For each delegated task, require a named result shape, a limited evidence bundle, a statement of limitations, and an owner who can accept, request revision, or decline the return.

Then preserve the result as an artifact or durable result record rather than a transient progress message. If an update stream disconnects or a remote agent becomes unavailable, the receiving side can still distinguish what was requested, what was returned, and what has not yet been accepted.

That is the real purpose of a return contract: not more text, but less ambiguity at the moment someone must decide whether delegated work can move forward.

A Virillio Code Editorial Perspective

Virillio Code Editorial presents the Delegation Return Contract as a product-neutral application framework. It does not describe a shipped, in-development, or planned Virillio Code capability.

Sources and further reading

• Agent2Agent Protocol Specification 1.0.0 — The current released specification distinguishes tasks, messages, artifacts, task lifecycle, version negotiation, and communication from task outputs; it also warns that messages are not reliable delivery for critical information.
• Software Delegation Contracts: Measuring Reviewability in AI Coding-Agent Work — A June 2026 preprint reports a controlled pilot with 64 executions and 192 reviews by three independent, condition-blinded model-based reviewers in which explicit contracts improved evidence sufficiency and reduced reviewer ambiguity while adding token and wall-clock overhead; the result is limited to the studied tasks and setting.

Editorial disclosure

This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.