Resumability for session/update: fill ReplayFrom's extension point with a messageId cursor

[johnhenry]

Problem

ACP's stable (v1) session/update stream has no way for a client to detect or recover missed notifications after a disconnect. If a client drops mid-turn, whatever streamed while it was gone is simply gone — there's no cursor, sequence number, or event ID on session/update to reconcile against. Recovery today is a fresh session or a re-prompt.

This came up concretely building acp-query (@johnhenry/acpq), a reactive client on @agentclientprotocol/sdk. Its docs state the current position plainly:

ACP has no replay. Session streams cannot be resumed with history, and there is no full read to reconcile against — session/update deltas are meaningful only in arrival order and the agent never re-sends them. A reconnect therefore leaves session state gappy [...] recovery is a fresh session or a re-prompt.

Related: https://github.com/orgs/agentclientprotocol/discussions/396 asked essentially this same question (does a dropped connection lose the turn? is session/resume meant to cover this?) and got one community reply describing a workaround, no maintainer resolution.

What's already in motion

Two things are relevant and encouraging:

1. The Streamable HTTP & WebSocket Transport RFD (merged, Active) explicitly names this as a goal: "SSE Last-Event-ID-style resumption lets a reconnecting client replay messages missed while disconnected." — but that's roadmap language, not a defined mechanism yet.
2. v2's session/resume + replayFrom is real progress — but ReplayFrom currently has exactly one concrete variant, {"type": "start"} (replay everything), with the rest of the union reserved as an open extension point ("custom or future replay cursor" types, values starting _ reserved for implementations).
3. v2 also just made messageId required on agent_message/user_message/agent_message_chunk/agent_thought_chunk (the messageId RFD, completed).

Proposal

Fill the ReplayFrom extension point with a messageId-anchored cursor variant — something like {"type": "messageId", "messageId": "..."} (inclusive, per ReplayFrom's existing semantics) — now that v2 guarantees every relevant message carries a messageId to anchor on. This isn't a new wire concept; it's the specific mechanism the Transport RFD's own language already points at, using an identifier the schema now requires anyway.

I've also left a comment with this same proposal on PR #721 directly, since it's the thread where the roadmap language lives, but opening this here too since the PR is merged and this seemed like the more durable place for ongoing discussion. Happy to prototype against acpq if a concrete shape gets floated.