[Epic] Multi-turn interaction gaps — state acceptance rules, interruptibility, and task lifecycle

## Multi-turn interaction gaps — state acceptance rules, interruptibility, and task lifecycle

Section 3.4 of the A2A specification defines the foundations of multi-turn interaction: `contextId` and `taskId` semantics, the `INPUT_REQUIRED` pattern, follow-up message references, and context inheritance. However, several practical scenarios are left unspecified. This epic tracks the gaps.

## Gaps

### 1. No normative rules for which states accept a follow-up message

§3.4.3 states that clients *can* send additional messages with a `taskId` reference, but the spec does not define:

- Which task states MUST accept a follow-up message
- Which states MUST reject one, and with which error
- Whether sending to a `WORKING` or `SUBMITTED` task is valid or an error

Two open proposals take opposing positions on this, and the tension needs a TSC decision:

- **#1027** proposes that follow-up messages MUST only be accepted in `INPUT_REQUIRED`. Sending to any other non-terminal state (e.g. `WORKING`) MUST return an `UnsupportedOperationError` ("Task not accepting input"). This makes the protocol deterministic.
- **#1022** proposes the opposite: agents should be *able* to accept messages while actively `WORKING` (mid-execution steering, as in long agentic loops), advertised via a new `guidable` capability flag on the Agent Card.

Without a normative answer here, client and agent implementations diverge.

- **#1022** — [Feat]: Support being able to send messages to actively running tasks
- **#1027** — [Feat]: Clarify multi-turn message acceptance requirements for `message/send`

### 2. No mechanism to re-engage a task in a terminal state

Once a task reaches `COMPLETED`, `FAILED`, or `CANCELED`, the spec provides no way to continue within the same task context. Conversational agents frequently need to handle follow-ups to just-completed actions ("actually, move that meeting to 16:00"). Today clients must start a fresh task, losing direct task linkage.

- **#1095** — [Feat]: Task Revival Proposal

### 3. No agent-initiated handoff from synchronous to asynchronous delivery

Clients must choose their delivery strategy (`message/send`, `message/stream`, push) before an agent has enough information to know how long a task will take. There is no mechanism for an agent to signal mid-stream: *"this will take much longer than expected — please switch to async polling or push."*

- **#1960** — [Feat]: Agent-Initiated Transition from Synchronous to Asynchronous Task Delivery

### 4. Cancellation of in-progress tasks is underspecified

Related to task lifecycle during execution: the spec does not define how an agent responds when cancellation cannot complete immediately (e.g. a rollback is running), and the `CancelTaskRequest` message definition is absent from the proto.

- **#1680** — [Feat]: How to respond to a task that cannot be cancelled immediately?
- **#1684** — [Bug]: The definition of `CancelTaskRequest` is missing

---

## Out of scope

The following are already addressed in §3.4 and are not tracked here:
- `contextId` and `taskId` semantics, assignment, and mismatch handling
- The `INPUT_REQUIRED` state pattern itself
- Context inheritance across tasks

**#902** (Managing multi-step user interactions) is a documentation/guidance gap rather than a protocol gap, and may be better resolved by expanding §3.4 examples rather than a protocol change.

---

## Child issues

| # | Area | Title |
|---|------|-------|
| #1022 | State rules | Support sending messages to actively running tasks |
| #1027 | State rules | Clarify multi-turn message acceptance requirements for `message/send` |
| #1095 | Lifecycle | Task Revival Proposal |
| #1680 | Cancellation | How to respond to a task that cannot be cancelled immediately? |
| #1684 | Cancellation | The definition of `CancelTaskRequest` is missing |
| #1960 | Async handoff | Agent-Initiated Transition from Synchronous to Asynchronous Delivery |