Esta página aún no está traducida; se muestra la versión en inglés.
Cómo funciona

Where a conversation lives between turns

If every turn is one self-contained request, where does the rest of the conversation sit? What gets stored per turn and what never does, the verbatim window, how older turns are folded into a rolling summary exactly once, what happens when a single turn still overflows, and which facts outlive the session.

Every turn is one self-contained request: the model keeps nothing between turns, and whatever is not in the request does not exist as far as it is concerned. Which raises the obvious question — if the model remembers nothing, where is the conversation?

It is on our side, in three tiers with three different lifetimes. A turn is assembled out of them each time, and the difference between the tiers is not importance but how far back they reach.

The three tiers

one conversation over time
durable memoryfacts about this customer · survives the session, follows them across channelsships to Rotterdamrolling summaryeverything older,folded in oncecursor: never twicerecent turns, verbatim
Recent turns go into the request word for word. What falls out of that window is folded into a rolling summary, once — a cursor makes sure it is never summarised twice. Facts worth keeping are lifted out separately and outlive the session entirely.

What is stored, and what never is

Each turn writes exactly two rows: what the visitor said, and what the agent replied. Both are encrypted at rest with a per-user key, the same way the rest of their content is (Private by design).

What is not written is as deliberate. The tool calls the model made, the raw payloads those tools returned, the intermediate reasoning it did on the way — none of it is persisted. It existed for one turn, inside one request, and it is gone. The conversation record is what was actually said, which is also why a stored conversation can be read by a human without wading through a machine's working-out.

The verbatim window

The most recent turns go into the request word for word — currently the last twelve messages. This is the tier that makes an agent feel like it is in the conversation with you: pronouns resolve, corrections stick, "the second one" means something.

The window is a fixed count rather than a token budget on purpose. A fixed count is predictable — you can reason about what the agent will still have in front of it. When the window does not fit the budget, the request-level priority takes over (what gets dropped) and the oldest of those messages are the first to go.

The rolling summary

Everything older than the window is not discarded. As soon as more messages have accumulated than the window holds, the excess — the oldest ones — are folded into the session's summary, and a cursor advances past them.

That cursor is the part worth knowing. The summary is not regenerated from the whole conversation each time; it is extended incrementally: the existing summary plus the messages that just fell out of the window produce the new summary, and those messages are never summarised again. This is what keeps a long conversation from costing more and more to maintain, and it is why the summary drifts rather than being rewritten — early context stays as it was first recorded.

The summary is capped (a few hundred tokens), stored on the session, and encrypted like everything else. It is one block in the request, above the history.

When a single turn still overflows

The two mechanisms above are steady-state. A single turn can still be too large on its own — a very long question, a large document pasted in, a knowledge base that contributed unusually heavily.

In that case the request-level budget drops the oldest history first, and the turns it dropped are compacted into the summary block for that turn rather than simply removed. The distinction matters: dropping loses the content silently, compacting keeps its substance and only loses the wording. Nothing is quietly deleted to make a request fit.

What outlives the session

The tiers above all belong to one conversation. Two things do not:

  • Durable facts about the customer — derived from turns as they happen, deduplicated so the same fact is updated rather than accumulated, and retrieved by relevance rather than recency. They follow the person across sessions and across channels. Per-customer memory covers how they are derived and what gets recalled.
  • A short profile — refreshed periodically from recent messages, carrying standing context rather than facts.

So a new session is a genuinely fresh conversation — no history, no summary — but not an amnesiac one. What the agent learned about the person is still there.

What this means for you

  • A session is whatever keeps the same session id. The web widget keeps one per visitor; an API caller decides. Starting a new one is how you deliberately drop the thread without losing what was learned about the customer.
  • A long conversation degrades gracefully rather than suddenly. The oldest turns lose their wording before they lose their substance, and their substance before it is gone entirely.
  • Exports and records show the conversation, not the machinery. Because tool traffic was never stored, what you read back is what a person would have read.