| Internet-Draft | Agent-Human Interaction | August 2026 |
| Okutomi | Expires 19 February 2027 | [Page] |
This intentionally incomplete design note defines an overlay for Human and Agent participation in existing Task and Action protocols. It separates the responsible Participant from the authenticated Actor, records Human interactions, excludes Humans from Agent discovery, and binds each change to its authorized request. It defines neither a wire protocol nor Humans as Agents.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 February 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
| Specification | Reused concepts |
|---|---|
| A2A 1.0 [A2A] | Task, Message, Task state, and Agent Card |
| MCP 2026-07-28 [MCP-TOOLS] | Tool discovery, Tool calls, and input-required results |
| WS-HumanTask 1.1 [WS-HUMANTASK] | People assignment, ownership, delegation, and Human Task handling |
| ROS 2 Actions [ROS2-ACTIONS] | Accepted, executing, canceling, and terminal execution states |
| W3C PROV-DM [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.¶
Human or Agent -- holds ----> Participant role Assignment ----- links ----> Participant and Task Interaction Event records -> interaction history Action ---------- runs -----> under an accepted Assignment Agent ----------- calls ----> Tool Actor ----------- sends ----> operation
A natural person who can accept responsibility.¶
An automated entity that can accept responsibility, run an Action, or act for a Human when its authority has been verified.¶
A callable function or resource. A Tool cannot accept an Assignment; a service with continuing responsibility is an Agent.¶
A responsibility role held by a Human or Agent, not a fourth entity class.¶
The authenticated sender of an operation, which may differ from the Participant.¶
The continuing responsibility link between a Participant and a Task.¶
A recorded question, response, correction, or withdrawal.¶
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.¶
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 [SEMI-E40], [SEMI-E90], [SEMI-E94], [SEMI-E157], [SEMI-E170], and [SEMI-E174] provide background; this document does not claim conformance.¶
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 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.¶
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.¶
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.¶
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.¶
This section is to be removed before publishing as an RFC.¶
This section follows [RFC7942]. 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 https://github.com/ToppyMicroServices/agents-secure-binding.¶
| 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.¶
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.¶
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.¶
This document requests no IANA actions.¶