Conversation management needs state ownership, not longer transcripts

I think conversation management needs explicit state ownership, not longer transcripts. A large context window can postpone the failure, but it does not answer who stores history, who orders concurrent turns, which branch is current, how retention works, or what survives a process restart. Those are state-management questions. Treating the transcript as self-managing state merely lets the model inherit unresolved infrastructure decisions.

The available conversation strategies make ownership unavoidable. In manual management, the application keeps a list, appends the new items returned after each run, and passes the full list into the next turn. That is transparent and controllable, but the application owns persistence, serialization, truncation, tenancy, and recovery. The convenience of a Python list does not make those responsibilities disappear.

A session abstraction moves the mechanics into an SDK and backend. Before a run, prior items are retrieved; afterwards, new items are appended. Any application instance can continue the conversation if it can reach the same session store. That supports horizontally scaled servers, but it also introduces an authoritative session identifier, storage consistency, access control, expiry, and migration semantics. “The SDK handles it” describes an implementation path, not an ownership model.

Server-managed state moves the boundary again. A conversation identifier can provide a simple linear thread, while an explicit prior-response reference can form branches from earlier states. The latter resembles a commit graph more than a chat log: two agents can explore from the same ancestor without sharing subsequent effects. Branching is useful only if the application knows which branch owns the user-visible outcome and whether branch-local tool calls changed external state.

This is why conversation history is shared state. Messages include more than prose. They may carry tool requests, tool results, approvals, handoff context, and assumptions that later actions depend upon. Once multiple workers, retries, or devices participate, append order alone is insufficient. The system needs stable item identities, causal links, writer rules, and an explicit projection for the next model turn.

I separate that conversation state from long-term memory. A session can be resumable without every message becoming a durable fact about the user. Conversely, a verified preference may belong in governed semantic memory after the conversation expires. As session state and memory are different schemas, their owners, retention policies, deletion behavior, and consistency requirements should be named independently.

Long tasks add another boundary. A session store can preserve conversational continuity while still losing execution progress between a tool effect and the next history append. Durable execution needs checkpoints around pending work, effect status, cancellation, and replay—not just stored messages. Conversation ownership should therefore integrate with, but not impersonate, the durable execution contract.

I would make ownership visible in the architecture: one component owns authoritative conversation items; one identifier scopes them to a tenant and user; one concurrency rule decides how turns commit; one retention policy expires them; one projection builds model context; and one durable workflow boundary records consequential effects. The choice can be manual, SDK-managed, or provider-managed. What matters is that the choice is deliberate and recoverable.

I concede one precise limit: short-lived, single-process assistants can reasonably keep history in memory and accept its loss. For a disposable interaction with no side effects, a formal persistence layer may add more ceremony than value. The boundary changes as soon as the product promises continuation, crosses processes, handles multiple writers, or performs consequential work.

Longer transcripts solve none of those promises. They increase the amount of state presented to the model while leaving authority over that state implicit. I would rather keep the transcript bounded and make ownership explicit—because continuity, branching, privacy, and recovery are properties of the system around the model, not of how many old messages the model can read.