Sessions seeded from client-supplied history

[mgoldsborough]

session/load and resume replay what the agent stored. That fits an editor, where the agent owns the conversation. It doesn't fit a host that owns the conversation and uses an agent to run one turn of it.

That's how we run agents. The host keeps the conversation, the files and the record of every tool call, and each turn goes to a pooled agent that may never have seen the session before. Today the only way to hand it the earlier messages is a transcript pasted into the prompt, which flattens tool calls and their results into text, or an agent-specific _meta key. We use both, and both cost us: the transcript loses structure the model should see, and the _meta key works with one agent.

What we'd want is a history on session/new: earlier messages in ACP's own content blocks, tool calls and results included, behind a capability the agent advertises. The agent treats it as the start of the session and stores nothing it wasn't asked to. A client with no history sends nothing, so nothing changes for editors.

Questions before anyone writes an RFD:

• Is ACP's content model enough for a tool call and its result in history, or does this need a message type of its own?
• Should a session started this way be loadable later, or is it the client's alone to keep?
• Does this overlap with session rewind (docs(rfd): Session Rewind — truncate and edit history (v2) #1321) closely enough to share a shape?

[JordanNewell]

We are building curtis — a BYOK, polyglot session-finishing agent (registry PR #721, open) — and the OP describes the architecture our product is pointed at: client owns the transcript, agents run turns without owning session state. Today's adapter uses agent-persisted sessions (loadSession); a client-supplied history on session/new, gated behind an advertised capability as proposed, is the piece that would let us run pooled stateless workers without transcript-in-prompt hacks. So: strong yes to the direction, and reads on your three questions:

1. Content model — reuse the existing v2 session-update blocks. History should be an array of the same agent_message / agent_thought / tool_call blocks the agent would have emitted live, with tool results attached. A new message type forks the model right where alignment matters most. Two practical concerns: tool results may need a truncated signal (real session histories carry large file dumps), and hosts should redact secrets before handing history to an agent they may not fully control.

2. Loadability — client-owned, agent stores nothing unless separately asked. A seeded session should not be session/load-able by default; mixing the two ownership models in one session invites double-memory bugs. If an agent wants to adopt the history as its own, that should be an explicit persisted hand-off, not an implicit side effect.

3. Relation to rewind — I would argue it is a closer sibling of session/inject (docs(rfd): steer and queue prompts sent while the Agent is working #1261) than of rewind (docs(rfd): Session Rewind — truncate and edit history (v2) #1321). Inject is additive at runtime, history is additive at creation, rewind is destructive — all three can share the v2 prompt-lifecycle substrate (agent-owned messageId, echo, state_change), but seeding should not inherit truncate/edit semantics it does not need.

Last design note: stateless agents have to reconstruct causality from history, so explicit message ordering matters once parallel tool calls interleave — worth settling in the RFD rather than leaving to convention.