How it works

Perpetuity runs as a proxy at the path of the provider's chat API, so an agent harness adopts it by changing its base URL and nothing else. Every request that comes through gets the same treatment: we work out who is asking and which conversation they are in from the request headers, store the incoming message, retrieve what is relevant from everything that was stored before, render it into text and put it into the request, forward that to the real provider, stream the reply back to the harness, and store the reply as well.

Which provider a request is meant for we read from the request itself, from the credential type and the shape of the model name, so one deployment can serve several providers behind one interface. A handful of per-request headers let a harness switch parts of the pipeline off for a single call.

The model never sees the conversation history as the harness sent it. What it sees instead is a frame made of past turns, quoted verbatim from the store, grouped by conversation with the current one last, labelled with names and times that are resolved when the frame is rendered, and closed by the live question. We then strip every message the harness sent, the live question included, because it is already there as the last rendered turn.

Nothing gets summarized on the way in and nothing is thrown away, so the frame is what the model sees this turn, while the memory is everything it could see. The frame is rendered as alternating user and assistant messages, so the model reads it as a conversation rather than a quoted block. For benchmarks and probes there is also a mode that answers a question without remembering it, where the live question is appended after the frame instead of being captured.

Each stored item carries a small activation state and nothing else about its past: the clock position of its last activation, the peak it reached then, and a decay constant that was fixed when it was created. From those three values we can compute how warm an item is at any later moment, so nothing ever has to be written to cool something down.

The clock is not wall time. It advances only when the agent processes content, measured in tokens, which means an idle agent forgets nothing. Creating an item counts as an activation, so it is born hot in the same write that stores it, and retrieval reheats what it selects with a peak shaped by rank, adopting the new state only where it beats the item's current trajectory.

The frame is simply whatever is still warm enough to render. Heat decides what the model sees but never enters the relevance score, and recency is not a rule we wrote anywhere, new items are just hot.

The frame has a token budget, but the budget is not a fixed number. We derive it per query from how the retrieval scores are spread: a question with one dominant match gets a small budget, and a question whose matches are dispersed across the store, which is what a broad question looks like, gets a larger one, up to a ceiling.

The cap is enforced against the text as it is actually rendered, in two passes, and a mandatory set is never trimmed: the current turn, its own retrieval, and the most recent stretch of the conversation. When the cap did remove something, the model is told so, together with the tool that reaches it. The statistic that sets the budget only decides how much gets rendered, it never changes which item ranks above which.

Besides the frame it gets without asking, the model has a small set of memory tools it can call when the frame feels incomplete: search everything stored, reopen this turn's full retrieved set from before the cap, follow a chain of related items, or count over evidence by category. The tools run inside the proxy, in the middle of the streamed reply, and a call's result is appended to that turn's context on top of the frame.

Each call only returns what the model has not been shown yet during the turn, so a search never repeats the frame. The loop is bounded, and on its last round the model has to answer. The instructions for the tools ride along with the request only when the tools do, so a harness that turns them off gets a prompt that never mentions them.

Candidates for the frame come from an exact scan over every stored item, held resident in the serving process and spread across worker threads with a deterministic merge, so there is no approximate index between the question and the memory. Before every scan the resident copy catches up from the store by reading only what is newer than a watermark, which makes a cold process slower on its first request but never wrong.

The same scan works over a memory pooled across many users at once. Everyone's items sit in one resident arena and score under one shared frequency statistic, while each asking user keeps their own conversation, heat and exclusions. The 93.0 on the benchmarks page was measured exactly this way, with every question retrieved from one memory holding 500 users.

A cheap first pass narrows the field and an exact rescore finishes it, with a budget that grows with the size of the live corpus.

A captured message becomes one or more immutable rows, each paired with exactly one retrieval row, and both are written together with the born-hot activation and the frequency counts in a single transaction, so either everything about a message is stored or nothing is.

Every derived structure has one writer. Activation is only ever patched by retrieval, the chain graph and the binding log each have a single writer, and the decay constant is written once at birth and never again.

The representation the retrieval rows use comes from a versioned dictionary that ships as data, and swapping it is a data operation rather than a code change: the new table is uploaded dark, every retrieval row is re-derived from the stored tokens while heat and novelty stay untouched, and the switch is one atomic flip. An integrity check recomputes the invariants on demand, and a user's memory can be purged as a unit.