Memory Is Not Continuity
thecontinuitylayer.com/primerA short, structural explanation of what continuity is, how it differs from what most current systems are built to do, and what this site tracks when it evaluates a claim.
If Start Here is the plain-language staircase, the Primer is the field guide. It turns the same idea into a structural model: what must persist, what must be governed, and how a continuity claim should be tested before it is claimed.
The hierarchy
- 01Memory stores the past. A record of what happened.
- 02Context retrieves what might be relevant. A guess, made per query, about which stored things matter right now.
- 03State tracks what is currently true. Not everything that happened — what still holds.
- 04Continuity carries the living situation forward. State, plus the reasons it changed, held across sessions, tools, and models.
Continuity Properties
Seven properties this project uses to evaluate a continuity claim.
Persistence beyond a session
Update handling
Temporal ordering
Disambiguation
Reconstruction
Model independence
Operational usefulness
On ATANT: the ATANT framework is one of the first serious public attempts to evaluate continuity along properties like these — not the only possible standard, and not one this project treats as settled. See the Evidence Library for what it does and doesn’t establish.
How to read this site
The Primer is the model. The other paths test it, document it, or map the wider field around it.
Primer
Lab
Evidence Library
Landscape
Taxonomy Map
Eight axes this project reads the field through. Each ties to categories in the Landscape rather than repeating them.
Memory
What is stored.
See: Memory systems, Personal AI memory
Context
What is available right now, in this call.
See: Context engineering
State
What persists — the current shape of a project or task.
See: Stateful agents, Long-running workflows
Provenance
Where each piece of truth came from.
See: Provenance & audit, Organizational memory
Agents
Who acts, and under what authority.
See: Agent infrastructure
Workflows
How continuity survives a handoff — session to session, tool to tool, agent to agent.
See: Long-running workflows, MCP & tool continuity
Evaluation
How any of this is measured, and against what standard.
See: Eval benchmarks, Papers
Infrastructure
Where the layer actually lives — protocol, runtime, product, or process.
See: MCP & tool continuity, Commercial
Why This Matters Now
Most systems people call “memory” today are strong in-session and weak across time. Agents lose state between steps, between sessions, between tool calls, and at every handoff to a different surface or model. RAG helps a system find something that resembles the answer; it doesn’t help it know what’s still true. Long context helps a session last longer; it doesn’t make what happened in that session durable afterward.
The field responding to this is fragmenting — new labs, papers, and products are appearing on an overlapping set of claims, often using the same words for different things. This project maps that field as it exists today, before the language collapses into vendor claims.
What We Track
- 01What actually persists — facts, embeddings, transcripts, something else?
- 02Where does it live — local, hosted, portable, locked to one vendor?
- 03Who owns it — the user, the app, the model provider, the runtime?
- 04What happens when a stored fact goes stale — is it updated, or does it just sit there?
- 05Can the system distinguish current truth from historical record?
- 06Can it disambiguate similar entities or facts instead of collapsing them?
- 07Does it reconstruct current state, or only retrieve similar-looking fragments?
- 08Does it work across models, or is it tied to one?
- 09Is there public evidence for the claim — a paper, a repo, a reproducible eval — or is it a vendor assertion?
- 10Is the deployment local, cloud, hybrid, or contractually locked to a single provider?
Open Questions
- 01Is continuity a distinct layer, or just a better-composed version of memory, context, and retrieval working together?
- 02Can any of this be made deterministic at meaningful scale, or does disambiguation always involve judgment calls?
- 03What actually counts as a valid benchmark for continuity, given how young and fragmented the eval landscape still is?
- 04How do privacy, provenance, consent, deletion, and portability work once state persists indefinitely across sessions and tools?
- 05Who owns continuity state when a user, an app, a model provider, a runtime, an enterprise, and a device all touch it?
- 06When multiple agents hold conflicting interpretations of the same situation, whose version wins, and on what basis?
- 07Beyond remember and forget: what does it mean for a system to supersede a fact, or to abstain from answering because it isn't sure which version is current?
Test the model, then inspect the receipts.
After the structural model, the next step is proof discipline: what would count as continuity working, what evidence supports the framework, and how to turn the model into local practice.