An Agent-Human Interaction Overlay for Task Protocols

Problem Existing specifications cover Agent Tasks, Tool calls, Human Tasks, Actions, and history, but not how they fit together when software acts for a responsible Human. Humans may reply later or more than once, correct a response, delegate work, or become unreachable. Treating this as one Agent call or Task state obscures responsibility, response history, and privacy boundaries.

Scope and Reused Specifications This -00 is a discussion document, not an application protocol. An implementation selects an existing Task protocol and, when needed, an Action protocol. The table lists concepts this overlay can reuse without adopting their wire formats. Reused specifications

Specification	Reused concepts
A2A 1.0	Task, Message, Task state, and Agent Card
MCP 2026-07-28	Tool discovery, Tool calls, and input-required results
WS-HumanTask 1.1	People assignment, ownership, delegation, and Human Task handling
ROS 2 Actions	Accepted, executing, canceling, and terminal execution states
W3C PROV-DM	Association, role, delegation, and provenance (history and origin)

These specifications retain their wire formats and full state machines. Although PROV-DM uses Agent broadly enough to include a person, this document keeps Human and Agent as separate entity classes.

Overlay Model

Responsibility, communication, and execution Participant role Assignment ----- links ----> Participant and Task Interaction Event records -> interaction history Action ---------- runs -----> under an accepted Assignment Agent ----------- calls ----> Tool Actor ----------- sends ----> operation ]]>

Human: A natural person who can accept responsibility.
Agent: An automated entity that can accept responsibility, run an Action, or act for a Human when its authority has been verified.
Tool: A callable function or resource. A Tool cannot accept an Assignment; a service with continuing responsibility is an Agent.
Participant: A responsibility role held by a Human or Agent, not a fourth entity class.
Actor: The authenticated sender of an operation, which may differ from the Participant.
Assignment: The continuing responsibility link between a Participant and a Task.
Interaction Event: A recorded question, response, correction, or withdrawal.
Action: An execution governed by the selected protocol and linked to an accepted Assignment.

An LLM may be a Tool or part of an Agent, but is not a responsibility class.

Additional Coordination Rules

Responsibility Is Not Execution Execution state belongs to the selected Task or Action protocol, not the Assignment. A slow Human response alone is not an Assignment or Action failure. Action success does not automatically fulfill an Assignment, and release or revocation does not automatically cancel an Action. For uncertain execution, WAITING means the resume condition is known, INDETERMINATE that an external effect is unknown, and ORPHANED that the executor is lost. A timeout alone is not failure, and lease expiry is not cancellation. If a timeout may hide an external effect, retry waits for reconciliation to establish the outcome or rule out a duplicate effect. The selected protocol defines the concrete states and events. A WAITING Action retains its resume condition across restarts. A timer or probe permits another check; it does not satisfy the condition, nor does moving the Action to PAUSED. PAUSED requires a confirmed stop, not merely a request or lost response. RESUME and TAKEOVER require fresh authorization and a new lease generation; the system applying the effect rejects older generations. Uncertain execution remains INDETERMINATE pending reconciliation. If the executor is lost during cancellation, recovery continues cancellation or reconciliation. Physical Effects (Non-Normative). In physical processes such as semiconductor fabrication or robotic automation, Action completion alone proves neither the physical effect nor product quality. A correction to a running operation is separately bound and cannot rewrite an earlier request or effect. Domain records may support reconciliation. The SEMI references , , , , , and provide background; this document does not claim conformance.

Delegation Retains Parent Responsibility Delegating an accepted Assignment creates an OFFERED child while the parent remains ACCEPTED. The parent event, child offer, and immutable delegation record are stored together; if any fails, none is stored. An external authorization service verifies that the child's authority is within the parent's, and the system checks that decision against both authority digests. Delegation is not a Task dependency.

Interaction History Is Append-Only Interaction Events are immutable. Multiple RESPONSE events may point to one QUESTION through in_reply_to. CORRECTION and WITHDRAWAL point through supersedes to the author's earlier RESPONSE or CORRECTION, which remains stored. A RESPONSE or CORRECTION may be INTERIM or FINAL. FINAL expresses only the author's intent; it does not close the interaction, fulfill an Assignment, or complete an Action. content_ref locates the content, content_digest identifies its bytes, and each complete event identifies both Participant and Actor.

Human Discovery and Reachability Humans are excluded from Agent search. Human discovery uses a separate opt-in process, and peer-supplied data cannot reclassify a Human as an Agent. Consent is limited to a Human-requester pair, purpose, capability, channel, and period. Search returns a pairwise opaque candidate ID, capability and channel metadata, a contact-request reference, and an expiry. It reveals no Participant ID, consent proof, or direct contact. After separate Human approval, a reachability grant supplies a purpose-limited HTTPS relay-session reference, not a direct contact. Consent and grants are revocable, and current Participant status is checked on use.

Exact Operation Binding For an accepted Human operation, a trusted registry supplies the responsible ACTIVE HUMAN Participant, while verified ASB grant and proof data supply the Actor. The receiver binds both identities and all decision-relevant fields to the request digest and current ASB session. Trusted Actor identity, Human kind and status, TLS binding, Store state, and replay result come from receiver-side sources, not caller assertions. Before commit, the receiver checks expiry, revocation, replay, revision, and duplicate event IDs. Interaction Events remain append-only and do not change Assignments. Session expiry blocks new authorization but does not stop an accepted Action or alter an Assignment. If a transport timeout leaves the result unknown, the caller opens a new authenticated session and checks whether the operation was stored before retrying. A retry reuses the event ID and request content with fresh proof; the stored event ID and result let the receiver return the earlier result. Pause, resume, cancel, takeover, and execution-changing corrections are new operations. Each uses a new event ID, an exact request digest, and fresh proof. This overlay does not redefine ASB, TLS, or database protocols; it defines how their verified results bind to a coordination operation.

Dependency Safety Rule A Task dependency means waiting for another Task; delegation is not one. A binding may reuse ALL, ANY, or QUORUM conditions from an existing workflow model. To avoid false positives, it reports no deadlock while a target is unknown or external progress, such as a timer, signal, or Human response, remains possible.

Implementation Status This section follows . Information is current as of 18 August 2026. At commit 9c5fef9, public main implements Task Participants, Assignments, Interaction Events, dependencies, and conservative deadlock detection. It also provides Agent-only discovery, Human matching and reachability, exact ASB request binding, direct TLS ingress, JSON Schemas, Store interfaces, in-memory adapters, and tests. The Action lifecycle and Task-Action binding exist only in development code. They are not part of that revision, which still includes AUTOMATED_SERVICE as a Participant kind and has not adopted the proposed Human-Agent-Tool model. The ingress cannot yet look up a result after a lost response, and replay use and Store commit do not succeed or fail together. The development Action code fences Store updates but lacks an external executor or physical-system adapter. The repository is available at .

Implemented State and Status Values Values present in the ASB repository

Layer	Implemented values	Availability
Participant registry status	ACTIVE, SUSPENDED, REVOKED	Public main
Assignment responsibility state	OFFERED, ACCEPTED, DECLINED, RELEASED, REVOKED, FULFILLED	Public main
Action execution state	ACCEPTED, RUNNING, WAITING, PAUSED, ORPHANED, CANCELING, INDETERMINATE, SUCCEEDED, FAILED, CANCELED	Development code
Reconciliation status	"REQUIRED", "RUNNING", "RESOLVED"	Development code
Reconciliation result	NO_EFFECT, SUCCEEDED, FAILED, CANCELED	Development code
Outcome status	SUCCEEDED, FAILED, CANCELED	Development code

The repository has no separate Task state machine; the selected Task protocol supplies it. QUESTION, RESPONSE, CORRECTION, and WITHDRAWAL are event kinds, while INTERIM and FINAL are response assertions. These are not states. A Tool receives no Assignment and therefore has no Assignment state.

Security Considerations Network input is not itself a trusted operation. The receiver derives the Actor from verified ASB data, Participant status from a trusted registry, transport binding from its TLS connection, and revision from the Store. Before commit, one application service checks request binding, expiry, revocation, replay, and revision; any failure rejects the operation. Reverse-proxy headers cannot replace trusted TLS termination.

Privacy Considerations Participant, interaction, dependency, and contact records can reveal who is involved, availability, communications, and work structure. Human matching limits disclosure through pairwise candidate IDs and relay references rather than direct contacts. The repository's in-memory example is not an encrypted contact store and provides no production relay, abuse prevention, or retention controls. Deployments keep direct contacts outside the coordination package and normal logs, and enforce consent, revocation, and retention at the relay. Public contact data does not grant permission for indexing or automated use.

IANA Considerations This document requests no IANA actions.