The Continuity Layer
Primer

Memory Is Not Continuity

thecontinuitylayer.com/primer

A 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.

01

The hierarchy

  1. 01
    Memory stores the past. A record of what happened.
  2. 02
    Context retrieves what might be relevant. A guess, made per query, about which stored things matter right now.
  3. 03
    State tracks what is currently true. Not everything that happened — what still holds.
  4. 04
    Continuity carries the living situation forward. State, plus the reasons it changed, held across sessions, tools, and models.
Long context — extends what one session can hold. It doesn't survive the session ending.
RAG — retrieves chunks that resemble the question. It doesn't know which of those chunks are still true.
Vector databases — search by similarity. They don't reconstruct which version of a fact is current.
Knowledge graphs — store relationships between entities. Most implementations don't automatically resolve stale-versus-current when a relationship changes.
Memory APIs — store profile-shaped facts about a user. They don't generally preserve the active shape of a project, a workflow, or an in-flight agent task.
Continuity — the composite of what the other five don't do alone: persist, update, order in time, disambiguate, reconstruct, work the same way regardless of which model is asking, and stay operationally useful.
02

Continuity Properties

Seven properties this project uses to evaluate a continuity claim.

01

Persistence beyond a session

Does state outlive the conversation that created it?
02

Update handling

When a fact changes, is the old value superseded with a reason, or silently overwritten?
03

Temporal ordering

Can the system say what was true at a given time, not just what's true now?
04

Disambiguation

Can it tell apart two similar-looking facts or entities instead of merging them?
05

Reconstruction

Can it rebuild the current shape of a project or task, not just retrieve fragments of it?
06

Model independence

Does the same state work if the model underneath changes?
07

Operational usefulness

Does it actually change what a person or agent can do, or is it a record nobody consults?

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.

03

How to read this site

The Primer is the model. The other paths test it, document it, or map the wider field around it.

Model

Primer

The structural account: what must persist, what must be governed, and how continuity differs from memory alone.
Recorded proof (bounded)

Lab

Demos and tests for continuity claims before they are treated as stronger claims.
Receipts

Evidence Library

References, source trail, and limits behind the framework and its evaluation posture.
Field map

Landscape

The wider AI field being tracked: labs, tools, papers, benchmarks, and emerging claims.
04

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

Explore the Landscape →
05

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.

06

What We Track

  1. 01
    What actually persists — facts, embeddings, transcripts, something else?
  2. 02
    Where does it live — local, hosted, portable, locked to one vendor?
  3. 03
    Who owns it — the user, the app, the model provider, the runtime?
  4. 04
    What happens when a stored fact goes stale — is it updated, or does it just sit there?
  5. 05
    Can the system distinguish current truth from historical record?
  6. 06
    Can it disambiguate similar entities or facts instead of collapsing them?
  7. 07
    Does it reconstruct current state, or only retrieve similar-looking fragments?
  8. 08
    Does it work across models, or is it tied to one?
  9. 09
    Is there public evidence for the claim — a paper, a repo, a reproducible eval — or is it a vendor assertion?
  10. 10
    Is the deployment local, cloud, hybrid, or contractually locked to a single provider?
07

Open Questions

  1. 01
    Is continuity a distinct layer, or just a better-composed version of memory, context, and retrieval working together?
  2. 02
    Can any of this be made deterministic at meaningful scale, or does disambiguation always involve judgment calls?
  3. 03
    What actually counts as a valid benchmark for continuity, given how young and fragmented the eval landscape still is?
  4. 04
    How do privacy, provenance, consent, deletion, and portability work once state persists indefinitely across sessions and tools?
  5. 05
    Who owns continuity state when a user, an app, a model provider, a runtime, an enterprise, and a device all touch it?
  6. 06
    When multiple agents hold conflicting interpretations of the same situation, whose version wins, and on what basis?
  7. 07
    Beyond 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?
Keep going

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.