Delegated tasks, messages and artifacts

The mechanism

Delegation hands a bounded task to another participant and receives messages, artifacts and status over time. That interaction can outlive a single request. The parent must know which task is being updated, who owns its artifacts and whether it is working, waiting for input, completed, failed or canceled. A2A defines a task-oriented protocol surface for such exchanges; this does not prove that either participant is intelligent or correct. A tool call and a delegated task can both be asynchronous, but they may expose different lifecycles and ownership contracts. The delegator should not turn a dropped connection into a new task without checking the existing identity. It should also retain its own final-goal and authority checks rather than treating a remote completed status as permission to publish an artifact.

The request declares a task identity, goal and permitted information/effects for the receiving service.
Status and artifact updates refer to that identity while execution continues.
An input-required state asks for missing information without claiming completion or starting a duplicate task.
The parent verifies the returned artifact and applies its own task and permission contract before further effects.

Science and assumptions

Delegated tasks, messages and artifacts · explicit relationship

A delegated task retains its identity across messages, input requests and artifact updates. Remote completion is checked against the parent’s task and authority before further effects.

A fictional delegated review task T17 returns a partial inspection note while its state is working. It later requests the asset revision and remains input-required. Sending that revision resumes T17; creating unrelated T18 instead could duplicate work and lose the original context. When T17 reports completion with an artifact, the parent checks that it refers to FAN-7 and the requested revision. A completed artifact for FAN-9 remains wrong for this task. This is a worked message lifecycle, not a running A2A endpoint.

Assumptions Worked lifecycle based on the inspected A2A specification; no network endpoint, interoperability test or multi-agent runtime is executed. The concrete protocol revision must be pinned for a future adapter.

Engineering example

Distinctions and tradeoffs

Delegation does not transfer unlimited authority or make a remote completion flag an independent correctness verdict.

Task-oriented protocols support long-lived work but require explicit ownership, reconnection and failure handling.

Coordinated AI systems need identities and outcome contracts between participants, not merely more agent names.

Specifications and interfaces

Mechanism boundary: How is an unfinished delegated task represented?
Worked lifecycle based on the inspected A2A specification; no network endpoint, interoperability test or multi-agent runtime is executed. The concrete protocol revision must be pinned for a future adapter.
Evidence type: Authored worked example
Worked explanation with a bounded numeric or state example. This lesson does not claim an executing implementation of an external model or platform.

Interfaces

Declared input and state Input: The request declares a task identity, goal and permitted information/effects for the receiving service.
Checked outcome Output: Track task identity, partial artifacts and input-required states without equating remote completion with accepted task success.

Check your understanding

The network disconnects while delegated task T17 is working. What should the parent avoid?

Checking T17’s existing status
Blindly creating a duplicate task for the same intended effect
Retaining the task identity

Answer and reasoning

Blindly creating a duplicate task for the same intended effect

A lost connection does not establish that the task stopped; duplication must be controlled at the task/effect boundary.

Evidence and scope

This is a worked explanation, not an executing external platform, model or robot. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. Worked lifecycle based on the inspected A2A specification; no network endpoint, interoperability test or multi-agent runtime is executed. The concrete protocol revision must be pinned for a future adapter.

The worked example explains this mechanism. General numerical labs are a reference; they do not execute this lesson’s full mechanism.