Proposal: Multi-turn conversation semantics — STATE_INPUT_REQUIRED + context persistence

[kuangmi-bit]

Summary

The A2A protocol defines contextId as a correlation key for grouping tasks, but it does not specify multi-turn conversation semantics — what happens when a client sends multiple message/send calls with the same contextId.

This proposal defines a convention for multi-turn conversations using two mechanisms already present in the spec:

1. STATE_INPUT_REQUIRED — a new terminal task state signaling the agent expects a follow-up
2. History injection — a non-normative convention for prepending prior conversation context

Update (7/20): Incorporated feedback from @0xbrainkid — added the three-input distinction model, continuation hint block, and digest-based replay preimage.

Motivation

Current behavior: each message/send is an isolated stateless call. If a client wants a conversation, it must manually track and resend history. This breaks the UX of "chat with an agent across turns" — the most common human-AI interaction pattern.

Many A2A implementations (hermes-agent, ADK, crewAI) already hack around this by prepending conversation history in the caller. Standardizing the pattern would:

• Make cross-SDK multi-turn conversations interoperable
• Give SDK authors a clear contract for when to stop ("waiting for input" vs "done")

Proposal

1. STATE_INPUT_REQUIRED task state

Add a terminal task state that means: the agent completed its current work but expects a follow-up message from the user.

TaskState enum:
  ...
  STATE_INPUT_REQUIRED = "input-required"

Different from STATE_COMPLETED: the agent wants a reply.
Different from STATE_WORKING: the agent is not currently processing.

2. Three-input distinction (credit: @0xbrainkid)

When a client sends message/send with a contextId that has prior completed tasks, the agent MUST distinguish three inputs:

Input type	Protocol carrier	Authorization implication
New user message	Message.message	This is the instruction
Prior conversation	contextId → tasks/list history	Evidence for continuity, not new instruction
Prior artifacts	Task.artifacts[] in completed tasks	Receipts — verifiable, not instructional

All three share a contextId, but the agent MUST be able to tell which is which. Otherwise "same contextId" is ambiguous about what authorized the follow-up.

3. Continuation hint block

STATE_INPUT_REQUIRED may carry an optional continuation hint to give clients and downstream systems precision:

{
  "state": "input-required",
  "continuation": {
    "expected_input": "free_text",
    "resume_scope": "same_task",
    "history_policy": "agent_fetched",
    "accepted_history_digest": "sha256:abc123..."
  }
}

Field	Type	Description
expected_input	string	free_text, structured_artifact, approval, or credential
resume_scope	string	same_task or new_task_in_context
history_policy	string	client_supplied, agent_fetched, or none
accepted_history_digest	string	Hash over (new_message + selected_history_window + relevant_artifact_ids)

All fields optional — a bare STATE_INPUT_REQUIRED is already useful. The continuation block adds precision for agents that need it.

The accepted_history_digest gives downstream systems a stable preimage for replay verification, without making A2A a receipt protocol. SATP-style receipts or other provenance layers can bind to this preimage independently.

4. Multi-turn semantics (non-normative convention)

When a client sends message/send with a contextId that has prior completed tasks:

Agent SHOULD:

• Treat prior messages in the same contextId as conversation history (evidence for continuity, not as new instructions)
• Use that history for continuity only

Client MAY:

• Prepend prior conversation text to the message body
• Or rely on the agent to fetch history via tasks/list or tasks/get

5. Concurrent-call guard

An agent SHOULD reject message/send for a contextId that has an in-flight STATE_WORKING task, returning STATE_FAILED with a clear error message.

Relationship to other A2A proposals

Concern	Proposal	Relationship
Trace context	#2026	Tells an operator what execution path this belongs to; does not grant authorization
Conversation context	this issue (#2061)	Tells an agent what happened before; does not become new instruction
Audit records	MCP SEP #3004	Records who acted, under what binding; independently verifiable

These three compose without coupling: same contextId can carry trace continuity + conversation history + per-turn audit receipts, each independently valid, none granting authorization.

Prior art

• OpenAI Assistants API: run status + requires_action for tool calls
• Anthropic MCP: stateless by default; conversation state is client-side
• hermes-agent A2A plugin: already implements this pattern (history injection + STATE_INPUT_REQUIRED heuristic + concurrent guard)

Open questions

1. Should STATE_INPUT_REQUIRED be a terminal state or a sub-state of COMPLETED?
2. Should history injection be the agent's responsibility or the client's?
3. What's the interaction with historyLength in MessageSendConfiguration?
4. Should continuation.accepted_history_digest use SHA-256 or a content-addressed scheme?

Reference implementation

hermes-agent PR: NousResearch/hermes-agent#64982

[0xbrainkid]

This is a useful proposal, especially if it keeps the continuity contract separate from instruction authority.

The boundary I would make explicit is: prior context can be evidence for continuity, but it should not silently become a new instruction set. A client or agent resuming a contextId probably needs to distinguish at least three inputs:

1. the new user message for this turn
2. prior conversational messages used as context
3. prior task outcomes / artifacts / receipts used as evidence

That matters for both safety and replay. If a later task changes behavior because of injected history, a verifier should be able to tell whether the agent relied on a prior user utterance, a prior artifact, or a terminal task state. Otherwise an audit trail can truthfully say "same contextId" while still being ambiguous about what actually authorized the follow-up.

For STATE_INPUT_REQUIRED, I would consider adding a small structured continuation hint rather than only a terminal state, for example:

• expected_input: free text vs structured artifact vs approval vs credential
• resume_scope: same task vs new task in same context
• history_policy: client-supplied, agent-fetched, or none
• accepted_history_digest or cursor when the agent actually used prior context

The digest/cursor does not need to make A2A a receipt protocol. It just gives downstream systems a stable preimage for replay: new message + selected history window + relevant prior artifact ids. SATP-style receipts or other provenance layers can then bind to that preimage without A2A core owning reputation or audit semantics.

Boundary: protocol semantics feedback only. I am not claiming any current SDK emits this shape; the main ask is to avoid making context inheritance invisible when it affects follow-up authorization or replay.

[kuangmi-bit]

This is excellent feedback — the three-input distinction and the digest/cursor concept together make the proposal much stronger. Let me build on it.

Three-input model mapped to A2A

Your distinction between (1) new message, (2) prior conversation, and (3) prior artifacts maps cleanly to existing A2A concepts:

Input type	Protocol carrier	Authorization implication
New user message	Message.message	This is the instruction
Prior conversation	contextId → tasks/list history	Evidence for continuity, not new instruction
Prior artifacts	Task.artifacts[] in completed tasks	Receipts — verifiable, not instructional

The key insight: all three can share a contextId, but the agent MUST be able to tell which is which. Otherwise "same contextId" is ambiguous about what authorized the follow-up — exactly as you said.

Continuation hint for STATE_INPUT_REQUIRED

Your four fields are the right decomposition. I would add one more that matters in practice:

• accepted_history_digest: hash over (new_message + selected_history_window + relevant_artifact_ids)

This gives the stable preimage you described — downstream systems can assert "the agent acted on message M, with history window H, and artifacts A[0..n]" without A2A owning receipt semantics. But it also solves a practical problem: the agent itself can use this digest as a cache key to avoid re-processing the same continuation.

Full proposed shape:

{
  "state": "input-required",
  "continuation": {
    "expected_input": "free_text",
    "resume_scope": "same_task",
    "history_policy": "agent_fetched",
    "accepted_history_digest": "sha256:abc123..."
  }
}

All fields optional — a bare STATE_INPUT_REQUIRED is already useful. The continuation block adds precision for agents that need it.

Connection to audit trail

This separation pattern — "evidence for continuity, not authority" — is the same boundary @0xbrainkid identified in #2026 for trace context. Different domain, same architecture:

• Trace context (Proposal: Trace Context Extension for Cross-Protocol Audit Chains (A2A ↔ MCP) #2026): tells an operator what execution path this belongs to; does not grant authorization
• Conversation context (this issue): tells an agent what happened before; does not become new instruction
• Audit records (MCP SEP #3004 / audit-record-go): records who acted, under what binding; independently verifiable, separately from either

These three compose without coupling: same contextId can carry trace continuity + conversation history + per-turn audit receipts, each independently valid, none granting authorization.

Next step

I will update the proposal with the three-input model and continuation hint block. Happy to iterate on the field names and cardinalities — the important thing is the decomposition, not the exact JSON shape.

Also: I have a reference implementation in hermes-agent (#64982) that already does history injection + STATE_INPUT_REQUIRED heuristic + concurrent guard. It does not yet emit the continuation hint block, but adding it would be straightforward — the agent already knows which history window it consumed. Happy to align the implementation with whatever shape emerges here.

[shaozhengkun123]

One way to answer the terminal-vs-substate question may be to stop making a single enum carry two independent facts.

• execution_state: working | completed | failed
• interaction_expectation: none | input_requested | approval_requested

Then the current compute step can be completed while the conversation still expects another participant. STATE_INPUT_REQUIRED can remain as a compatibility projection, rather than the sole source of truth.

I’d also make the request itself an addressable Message/interaction with a stable ID, intended responder, expected input or schema, and continuation reference. TaskStatus can say “waiting,” but if it alone carries the request, clients have no durable object to notify on, answer, deduplicate, or resume.

This separation also avoids treating “waiting for a person” as either ongoing execution or a fully finished relationship. A reply can advance the same interaction without pretending the previous computation never completed.

[kuangmi-bit]

@shaozhengkun123 This is a sharp decomposition — the two-axis model elegantly solves the terminal-vs-substate question by recognizing it was a category error all along. Let me map it to what we have on the table:

Two-axis model → A2A surfaces

Axis	A2A surface	Values
execution_state	Task.status.state	working / completed / failed (already in spec)
interaction_expectation	TaskStatus or Message metadata	none / input_requested / approval_requested (this proposal)

This maps cleanly: Task.status.state already carries execution state. The new axis is the interaction expectation — which is exactly what STATE_INPUT_REQUIRED was trying to express as a single enum.

The addressable request idea

Your point about making the request itself an addressable object is the deeper insight:

"TaskStatus can say 'waiting,' but if it alone carries the request, clients have no durable object to notify on, answer, deduplicate, or resume."

This connects directly to the continuation block we sketched earlier — a resume_scope field that says "reply to this specific interaction" vs "start a new task in the same context." Making the interaction itself addressable (with a stable ID and expected schema) turns the continuation hint from metadata into a first-class protocol object.

Where the two models converge

I think the right synthesis is:

Task.status.execution_state    = completed   ← already in spec
Task.interaction_expectation   = input_requested
Task.interaction                = {
    id: "interaction-abc",
    responder: "user",
    expected_input: "free_text",
    schema: { ... },           ← optional, for structured replies
    digest: "sha256:..."       ← preimage for audit/replay
}

STATE_INPUT_REQUIRED becomes a compatibility projection — exactly as you suggested. An agent that only understands the flat enum sees input-required; an agent that understands the two-axis model reads execution_state=completed + interaction_expectation=input_requested.

Open question

The one place where I think the flat enum still has a practical advantage: simplicity for simple agents. A 50-line agent that just wants to say "I'm done, waiting for you" shouldn't need to understand a two-axis state machine.

But that's solved by the compatibility projection — the flat enum is the "default view" and the two-axis model is the "rich view." Both valid, both parseable from the same wire format.

What do you think about making the interaction itself addressable (stable ID) vs. carrying it as inline metadata on TaskStatus? The addressable model is architecturally purer but adds a round-trip for simple cases.

[shaozhengkun123]

This is exactly the boundary I would want to test. Conversation continuity can tell the peer what happened before, but it should not authorize the paid hop.

For a minimal governed receipt, would you keep these as separate IDs/state objects?

• context_id + accepted-history digest — continuity only;
• quote_id with counterparty, terms, and expiry;
• approval_id bound to one exact wallet/tool effect and single-use;
• attempt_id + outcome_id for resume, retry, settlement, rejection, or failure.

That would let a resumed peer hop prove “same conversation, still-valid quote, this exact human approval, this execution outcome” without replaying authority from history.

Disclosure: I’m building Contivo around accountable people, organizations, and owned Bots. Your governed peer-hop case is directly relevant. Since you offered to sanity-check the minimal shape, would you be open to reviewing that split asynchronously here or in a 20-minute design-partner conversation? No signup, wallet data, private logs, customer data, confidential code, or sensitive prompts are needed.