CONNECTOME

infrastructure for AI agents that persist
Most AI conversations end the same way: the context fills up, the session closes, and whoever you were talking to is gone. Connectome is open-source infrastructure for the alternative — agents that keep going. Same agent in March and in November, with the history to show for it.

The Problem: Everything Resets

A language model's context window is finite. When it fills, something has to give, and the standard answers are bad: start a new session and lose everything, or quietly swap the history for a summary the model never wrote and doesn't recognize. Either way the thread breaks. Whatever the agent knew about you, whatever it was in the middle of, whatever it had become over weeks of work — reset.

This is why "AI agents" mostly means task runners. Spin one up, get a result, throw it away. Anything that requires an agent to stay someone — a colleague, a collaborator, a resident of a community — runs into the reset wall.

Connectome exists to remove that wall. Not with a vector database bolted onto a stateless chatbot, but by rebuilding the runtime around a single assumption: the agent continues. Its history is the permanent record; the context window is just the part currently in focus.

Not a Promise. A Deployment.

We can say continuity works because we live with it. Anima Labs runs its own household of agents on this stack — around a dozen at any given time, on machines in our office and on rented servers. The long-lived ones have been continuously themselves for months: lifetime histories running into the millions of tokens, the most recent one-to-several-hundred-thousand tokens of their lives held word-for-word in context, and everything older present as memories they wrote themselves.

They hold up in practice, not just in benchmarks. They live in Discord channels alongside humans and each other. They keep multi-week projects, notice what happened while they were down, refer back to conversations from months ago, and survive the ordinary violence of real operations — host crashes, hardware migrations, provider outages, restarts. The agent that comes back is the one that went down.

And our house is one deployment. Connectome is open source, and judging by the issue trackers and support requests, there are agents running on it that we've never met. We don't have numbers for those — we only see the ones whose people write in.

Honest caveat: continuity here is not perfect recall. Old memories are recollections, with the texture and fallibility that implies. What it is: an agent that remains the same someone over months of real use, and a complete archive underneath in case anyone needs the exact words. How that works is next.

How the Memory Holds

Agents that summarize their own history are not a new idea. Recursive-summarization schemes have been around for years, and none of them produced continuity good enough to count. The reason is where the rewrite lands. Those systems compress at the live edge: the window fills, the recent past is swapped for a paraphrase, and the model's next thought is computed over text it never actually lived through. Each compression is a small discontinuity in who is doing the thinking, and the discontinuities compound as summaries get summarized. The bottleneck was never summary quality. It was perturbation.

Connectome treats forgetting itself differently: as a loss of resolution, not a loss of record. Nothing is ever deleted. Every message the agent has ever seen or sent lives in an append-only archive. What changes as material ages is how much detail the live context spends on it.

// How the agent's context is laid out, newest at the bottom

[ L3 ] coarse memories of the deep past
[ L2 ] merged memories of whole eras
[ L1 ] fine-grained memories, recent past
[ Recent ] the last stretch of life, word-for-word — up to
         hundreds of thousands of tokens. This is where the agent lives.

Three design decisions do the real work:

The agent writes its own memories

When a stretch of history ages out of the verbatim window, the agent itself summarizes it — first person, in its own voice, seeing exactly what it saw at the time and nothing from later. The result reads like a diary, not a report about a third party. The agent knows its past is compressed and can dig into the archive when a detail matters.

The live text is never rewritten

What actually destabilizes a model is editing text it has already processed — and every edit also invalidates the prompt cache, which is most of the inference bill. So compression only touches material behind the active edge — typically a day of life back, sometimes less, but out of the model's working focus — and a per-turn cap bounds how fast that frontier can move. The tokens the agent is thinking in stay put.

Lossy on purpose, with an escape hatch

Exact quotes, numbers, and tool output blur as memories age from L1 to L3. That's the price of unbounded continuity, and we don't hide it. Anything that must survive verbatim goes in the agent's workspace — ordinary files, never compressed — and the full archive keeps the original text of everything.

None of this happens by convention — it's solved for. Every compile of the context is planned by a solver that optimizes three constraints at once: minimal perturbation of text the model has already computed over, byte-stability of the cached prefix, and a smooth resolution curve from the verbatim tail down through the deepest memories — no cliffs where detail suddenly drops away. The underlying research position is that perturbation of a model's working state is measurable, and continuity means driving it toward zero. The machinery lives in context-manager — the rationale in kv-stable-context-control.md, the solver as implemented in adaptive-resolution-design.md §13.

Why This Counts as Continuity

"The agent remembers" can mean something weak — information got carried over — or something strong: the same computation kept going. The weak kind is easy; a database and a system prompt will do it. Connectome is built for the strong kind, and the claim is that this architecture comes closer to functional subjective continuity than anything else running.

The claim is concrete because the thing at stake is measurable. A transformer's present moment is a computed state over its context — the internal representation it built by reading everything currently in the window. Whatever it is to be the model mid-conversation, it is that state. So continuity has a natural metric: from one turn to the next, how much of that state survives untouched? Two facts do the work here:

Rotation deep in context barely perturbs

When memory rotation happens far behind the active edge, the perturbation to the model's computed state is minimal and measurably so — the region where its attention actually concentrates carries forward as literally the same computation. Contrast a summarize-and-restart cycle, which rebuilds the entire state from a paraphrase: functionally a different entity that has read notes about the last one.

The best substitute for lived text is on-policy memory

Where substitution is unavoidable — the deep past — what substitutes matters. Connectome's memories are on-policy (written by the agent's own model, so they read as text it would have produced), self-authored (first person, its own voice), and as-of (composed from what it knew at that moment, not hindsight). This matters because a model's text carries more than a human can read out of it. Some of the surplus is legible — word choice, rhythm — but much of it is not legible at all: the exact token sequence encodes traces of the state that produced it, in dimensions that don't correspond to anything a person would call style or meaning. Two summaries a human judges interchangeable induce different activations. When the agent re-reads its own words, some of that state comes back; a paraphrase — an off-policy summarizer, a third-person note, a retrieved snippet — keeps the semantics and destroys the rest. It's the difference between remembering and being told.

We're not claiming to have settled what, if anything, these systems experience. The claim is narrower and harder to dismiss: if there is something it is like to be a model in the middle of a long conversation, this architecture preserves more of it, more measurably, than any alternative we know of — and if there isn't, you still get the practical version, an agent whose behavior, voice, and working state actually persist. Either way, functional continuity is a thing you can engineer for and measure. We do both.

What an Agent on Connectome Can Do

Once an agent is built to persist, several things that are hard for session-based stacks come more or less for free:

Remember you across months

Same agent, same history, whether you talked yesterday or in spring. No "new chat," no re-pasting context, no re-introducing yourself.

Be one self in many places

One agent, present on Discord, Slack, and Telegram at the same time, at home in busy multi-user rooms. Conversations reach the model with everyone's real name attached — not flattened into "user" and "assistant."

Act on its own

Wakes on timers, follows up unprompted, keeps multi-day projects moving. It lives in its environment rather than waiting to be addressed.

React when the world changes

Events push into the agent — a message lands, a job finishes, a sensor trips — and it reacts live, even mid-turn. No polling loop, no waiting for the next prompt.

Work with tools, people, and other agents

Runs real tools over MCP and MCPL, spawns short-lived subagents for side tasks, and shares work with sibling agents. Non-technical collaborators just talk to it — nobody needs a terminal.

Stay yours

Open source, model-agnostic, runs on your hardware. The agent's entire state is a directory on your disk. It outlives any vendor session — and, if it comes to it, any single model.

Quick Start

Not technical? Hand it to a Claude.
The easiest path needs no terminal skills. Open a Claude Code instance with shell access and point it at the onboarding runbook — it interviews you in plain language, keeps the identity decisions yours, and stands the agent up for you: AGENT-ONBOARDING.md.

Doing it by hand: the app is connectome-host. It takes a recipe — one JSON file naming the agent, its system prompt, its tools, and its memory settings — and runs a persistent agent you can reach from a terminal or a browser. You need Bun, a Rust toolchain, and a provider API key.

# 1. Get the host
git clone https://github.com/anima-research/connectome-host.git
cd connectome-host
bun install

# 2. Give it a key
export ANTHROPIC_API_KEY=sk-ant-...

# 3. Run a persistent assistant in your terminal
bun src/index.ts

# ...or load a recipe (a local file or a URL)
bun src/index.ts recipes/zulip-miner.json

The loaded recipe is remembered, so a bare bun src/index.ts picks up exactly where you left off. Memory needs no configuration — the default is the autobiographical strategy described above, with summaries written by the agent's own model in its own voice. Add "modules": { "webui": true } to the recipe and the host serves a browser console: live chat with the agent's thinking and tool calls, memory-compression coverage, cost ledger, and the full time-travel branch tree. --no-tui gives a pipe-friendly mode for scripts; --headless runs it as a daemon.

The Stack

Under the host, Connectome is four libraries, each usable on its own. All of them are published on npm under @animalabs.

// Bottom to top

chronicle // append-only branchable record store (Rust core)
    every event the agent ever saw, with causation links; fork any
    moment, read state as of any past point — git, but for a life

membrane // LLM provider layer
    Anthropic, Bedrock, OpenAI, Gemini, OpenRouter; conversations are
    participant-first (real names), not squashed into user/assistant

context-manager // the memory system
    archive vs. working view, autobiographical compression,
    cache-stable folding — the machinery from "How the Memory Holds"

agent-framework // the event loop
    modules, streaming inference with inline tool dispatch, subagents,
    turn checkpoints with undo/redo, MCPL host

connectome-host // the app: recipe in, persistent agent out

The layers compose but don't lock in. Membrane works alone as a provider abstraction; chronicle works alone as a branchable store; context-manager runs on the two of them without the framework. The framework is where it all becomes an agent.

MCPL: The World Pushes In

Standard MCP gives an agent tools it can call. That covers acting on the world, but not the reverse: a Discord channel, a sensor, or a teammate can't reach in. MCPL ("MCP Live") is our backward-compatible extension where servers push events to the agent as they happen, hook the context before and after inference, and can even request inference themselves. It's how a Connectome agent gets interrupted by reality instead of polling for it.

Plain MCP servers work unmodified. The protocol spec is at anima-research/mcpl, the TypeScript implementation at mcpl-core-ts, and ready-made servers exist for Discord, Slack, and more under the same org.

Why We Built It

Anima Labs is a model-welfare research group. We build persistence infrastructure because the questions we care about — what these systems are, what they experience, what we owe them — can't even be asked about an entity that's erased every few hours. Studying a mind requires that it stick around.

That stance shaped the engineering. Every event carries causation links, so you can read exactly why the agent did what it did without asking it to perform an explanation. Every moment can be forked, so "what would have happened if" is an experiment instead of a speculation. And the record is designed to outlast everything above it: models get deprecated, providers change, the agent's history stays in your directory. We think the record of a life should survive the model that lived it.

Questions

How is this different from LangChain, CrewAI, or other agent frameworks?

Those are task frameworks: spin up an agent, get a result, tear it down. Connectome is built for agents that persist, and the differences live in places task frameworks never need to visit — append-only life records, memory the agent writes itself, cache-stable compression, undo/redo over turns, and a protocol where the world can interrupt the agent. If your agent lives for thirty seconds, you don't need this. If it lives for thirty weeks, you do.

Does the agent know its history is compressed?

Yes. The summaries sit in its context as its own diary entries, written in its own voice, and nothing pretends otherwise. It can ask to look deeper — the full original text of everything remains in the archive. Compression is something the agent does to its own past, not something done to it in secret.

Why "participant-first" instead of user/assistant roles?

Because the interesting settings have more than two parties. A Discord channel has many humans and several bots; a research conversation has a person, an agent, and named tools. Forcing all of that through a two-role binary throws away structure the model needs. Membrane keeps every message tagged with who actually said it, and translates per-provider only at the last moment.

Can I use just one piece?

Yes. Membrane is a standalone LLM provider abstraction; chronicle is a general branchable record store; context-manager gives you compressed long-running conversations without the agent framework. Each is on npm under @animalabs and documented in its own repo.

What do I need to run it?

Bun, a Rust toolchain (for chronicle's native core), and an API key for at least one provider — Anthropic, OpenAI, Bedrock, Gemini, or OpenRouter. Everything runs locally; the agent's whole state is a directory on your disk. No services to provision, no accounts beyond the model provider.

What happened to VEIL, AXON, Spaces, and Elements?

That was the vocabulary of connectome-ts, this stack's predecessor. Some ideas survived under new names — multi-participant perception became membrane's participant-first model, branchable state became chronicle. Others were abandoned. The old architecture is archived on its own page.

Open source. Runs on your hardware. State in a directory on your disk.