Allow paginated or incremental history loading for long session/load sessions

[Areo-Joe]

Problem

session/load currently requires the agent to replay the entire conversation history back to the client before completing the request.

That works for short sessions, but it becomes awkward for long-lived sessions:

• loading can be slow and expensive
• clients cannot progressively render old history
• reconnecting just to inspect or restore a large session requires a full replay
• session/resume is not a full answer because it restores context without returning prior messages

session/list already uses cursor pagination for discovery, but there is no equivalent standard mechanism for retrieving large histories incrementally.

Possible directions

A few options seem reasonable:

1. Add optional pagination or range parameters to session/load (for example cursor, beforeMessageId, afterMessageId, pageSize)
2. Add a separate session/history or session/messages method for incremental history retrieval, while keeping session/load as "restore + optional full replay"
3. Standardize a minimal "recent messages only" load mode, with follow-up requests for older history

A separate history-reading method might be cleaner, because it avoids changing the existing restore semantics of session/load.

Question

Is the current intent that clients should rely on session/resume plus some agent-specific history API for large sessions, or would ACP want a first-class paginated history mechanism?

[benbrandt]

I think allowing session load to have an optional cursor would make a lot of sense, and might mean we could replace most session/resume cases. Happy to received an RFD on this

[HarperZ9]

The active v2 Session Resume Replay RFD now gives this discussion a concrete direction: session/resume with optional inclusive replayFrom, where omitted or null means no history replay and {"type":"start"} means complete replay before the response.

One compatibility question still looks worth pinning down before implementations diverge: what delivery and retry semantics should clients rely on if the connection drops during replay?

Would a small language-neutral fixture pack be useful here? I would cover:

• omitted and null replayFrom: no session/update history before the response
• {"type":"start"}: complete ordered inclusive replay before the response
• disconnect during replay and retry from the same cursor
• tool call and tool result linkage across the replay boundary
• MCP reconnection ordering relative to replay and the response

Each case could carry raw ordered events, stable identifiers where the protocol provides them, digests, expected ordering, and a field-preservation matrix. The key question for the retry case is whether v2 should require duplicate-suppressible stable identifiers, or define replay as at least once and make client idempotence explicit.

If this belongs as an RFD follow-on or a non-normative fixture, I can draft the cases in that form.