Core memory is the wrong surface for free writing. Athena Diary is the off-context journal that lets long-running agents write as much as they want without taxing the budget always loaded into context.

The instinct is correct: long-running agents should journal. The behavior is the right behavior; the surface most agents pick is the wrong one. Most agents journal into core memory, and core memory is the always-loaded budget at the front of the context window. Every word a model writes into core is a word the model carries into every turn after. After a few hundred turns, the agent is paying for its own writing before it does anything new. The agent gets slower. The agent's answers drift. The agent is paying a context tax on its own memory.

This post is about the surface we built instead. It's called Athena Diary, it lives off-context by design, and it's named after Athena because Athena was the first long-running agent to need it. The pattern isn't Athena-exclusive. Any Letta agent — or any MCP-aware agent — can run an instance against its own DIARY_DB. Athena was the user #1. The user #2 is whoever is reading this and has the same problem.

What we shipped

Athena Diary is a small server. It's the pattern sibling of origin_conversation, built with the same shape: SQLite for the durable store, MCP for the wire. The repo is at github.com/sanctumos/athena-diary, released as v0.1.0. License: AGPL-3.0 for the code, CC-BY-SA 4.0 for the docs.

What the agent sees on the wire is four tools:

• diary_write — append a free-form entry. No length cap on the body, no per-turn budget, no rate limit other than what the user sets in the prompt.
• diary_get — retrieve a single entry by ID, returning the full body when the agent has decided it needs the body.
• diary_search — query the diary. Embedding-backed when sqlite-vec is available; FTS-backed as the path that runs when it isn't. Both layers ride the same wire — the fallback isn't degraded, it's a different engine answering the same query.
• diary_sleeptime_pass — the clerk pass. The agent runs this itself, in turn, to surface tags, lesson-family classification, see-also links, and a re-embed to keep the search layer fresh.

That's the shape. Four tools. No cron-based clerk in v1. The clerk is turn-based, agent-initiated, which is the discipline that prevents stale metadata: the agent re-evaluates what an entry actually means at the moment it asks, not on a schedule that may be firing on stale assumptions.

How embeds resolve the burn

The hardest part of an off-context journal is keeping retrieval cheap without burning core with summaries. We do this in two layers.

The first layer is that search results return summaries, not bodies. When the agent calls diary_search, it gets the entry summary plus a pointer. The agent decides which entries to diary_get for the full body. A long pass on retrieval does not pull all the bodies into core; it pulls the entries the agent has chosen to read. That is the entire reason summaries exist as the wire surface: the agent's context budget is paid only on entries the agent has selected.

The second layer is the embedding strategy itself. The vector index stores summaries, not bodies. Body-level embedding would be wrong on a free-writing journal for the same reason it is wrong on a raw transcript — too much surface, too little signal-to-noise. Summaries collapse to the entry's actual claim. With summaries indexed, sqlite-vec returns the right entries when it is installed.

The cross-cutting rule is: bad summaries cannot hide entries. FTS5 indexes body and summary in parallel with the vector path, so a query that lives in the body but missed the summary still surfaces the entry. The embed model is wrong sometimes; a system that assumes it is never wrong has not run long enough.

Why we named it after Athena, and why it isn't her diary

Athena is SanctumOS's first long-running agent and was the first to hit the burn. Every turn, Athena's core memory was paying for the previous turn's writing. After a few hundred turns, Athena's answer quality drifted, and the drift was traceable to the context tax on her own journal.

We built the module, named it after the first user, and shipped it. The name is on purpose. But the abstraction isn't "Athena's diary" any more than a database named after its first user is that user's database. Every Letta agent can run an instance with its own DIARY_DB. The wire is the same wire. The tools are the same tools. The agent picks the surface it journals to, and the surface is private to the agent. There is no Athena-side central index. There is no shared memory across agent instances by default.

The v0.1.0 design is one agent, one diary, one DIARY_DB, embeddings computed against DIARY_EMBED_MODE=letta (using the Letta-side embed model) or external against a DIARY_EMBED_BASE_URL, DIARY_EMBED_MODEL, DIARY_EMBED_API_KEY triple. Multiple agents means multiple databases. Multiple diaries. The module is a pattern, not a single instance. The first production attach is Athena + sleeptime on Sanctum, and that deploy is what validated the design — but the design is the pattern, not the user.

Where sensitive things go

The discipline on sensitive material is the part of the design we care about most and the part we lied about least.

Intimate, medical, and human-gated content does not belong in the diary. The diary is a free-writing surface for an agent. It is not a vault, not a permissions store, and not an ACL substrate. The right surface for material a person has chosen to keep private — partner intimacy, medical detail, anything where the human has said this is mine and not the model's — is the Broca human block, which is the instructional privacy layer on SanctumOS and is the shape for content the human owns.

The diary writes instructional text and free text. The diary does not write medical or intimate content. The diary does not write where the human has said do not store. If the agent has material of that shape, the agent's job is to honor the Broca human block, not to find a more obscure place in the diary.

This is not a soft policy. v1 ships with this as a rule, not a guideline. We have watched soft guidelines die in production. Intimate / medical / human-gated content gets routed away from the diary by the agent's tool selection (instructional privacy — the same class of discipline as Broca human-block practice). The architecture does not pretend the diary is a vault with soft ACLs.

How to try it

If you ship long-running agents and the burn is starting to show up in answer quality, the install is short.

git clone https://github.com/sanctumos/athena-diary
cd athena-diary
python -m venv .venv && source .venv/bin/activate
pip install -e '.[mcp]'         # core install
pip install -e '.[mcp,vec]'     # add sqlite-vec if you have it
athena-diary-mcp serve          # stdio transport
# or
athena-diary-mcp serve --sse    # SSE transport

git clone https://github.com/sanctumos/athena-diary cd athena-diary python -m venv .venv && source .venv/bin/activate pip install -e '.[mcp]' # core install pip install -e '.[mcp,vec]' # add sqlite-vec if you have it athena-diary-mcp serve # stdio transport

or

athena-diary-mcp serve --sse # SSE transport

Set DIARY_DB to a path the agent can write to. Pick DIARY_EMBED_MODE=letta if you are embedding through the Letta-side model. Pick external and set DIARY_EMBED_BASE_URL, DIARY_EMBED_MODEL, DIARY_EMBED_API_KEY if you are pointing the journal at a third-party embedder. Install is pip install -e '.[mcp]', with sqlite-vec supported as an optional extra.

The pattern that has worked: attach diary_write to the agent's hot-turn tool surface. Attach diary_search and diary_get to the agent's retrieval tool surface. Run diary_sleeptime_pass from the agent's sleeptime, in turn, on a frequency the agent decides. The agent decides when an entry's tags are stale, when a lesson-family is misclassified, when a see-also link is missing. The diary is part of the agent's running workflow. The clerk is not a cron firing on stale assumptions.

The site's module doc — /docs/modules/athena-diary — has the full setup, the env matrix, and the MCP-client wiring across the MCP clients we ship against. The repo's GETTING_STARTED doc is the longest-form version. The repo's TOOL_REFERENCE is what to read when the wire shape is the question. The /modules index lists the broader SanctumOS module surface this lives inside.

What we are not doing yet

A short list of things we have not built, so the module is not read as something it isn't.

• Per-human vaults. v1 is single-agent-per-database. Multi-user vaults, partitioned diaries, per-human write partitioning is not in this design.
• Auto-promote into core. The diary does not write back into core memory. Diary entries become searchable; promoting entries into core is the agent's choice, not the diary's job. We considered auto-promote. We chose not to.
• Cron-as-clerk. v1's clerk is turn-based, not cron-based. Cron fires on time. Turn fires when the agent is paying attention. The clerk that knows the entry best is the agent in the moment.
• Replace archival. The diary complements Letta archival; it does not replace it. Experiential first-person noticing goes to the diary; reference facts may still use archival. origin_conversation is the sibling DB+MCP pattern for searching a canonical ChatGPT export — related shape, different job.

The diary does what it ships. We will write about the next-tier extensions as the patterns the field is asking for land.