Skip to content
manifesto_engine

Your AI coding agent forgot everything you told it yesterday.

Yesterday's mistakes, yesterday's decisions, yesterday's work - gone. The next session starts at zero. You re-explain the project, re-answer the same questions, and the agent makes the same mistakes again.

I'm building the thing that fixes this. The flagship is CSM - a TypeScript plugin that gives agents persistent, recallable, auditable memory across sessions. It has been running in production for 30 days. Every number on this site is backed by a SELECT against a live database.

CSM case study → What I'm thinking about → Who I am →
59.7K memories
642.6K recall events
2.02B tokens saved
969 tests

snapshot · 2026-07-11 · full evidence →

Continuity, not context.

Bigger context windows are the symptom pretending to be the cure. Tripling the context just triples the cost and triples the surface area for hallucination - it doesn't make the agent remember. What works is memory that persists between sessions, recall that actually finds the right thing, and telemetry that tells you what happened when it didn't.

The continuity loop Experience agent acts Memory extract + store Recall graph + vector Action context in Verify telemetry Learn beliefs feedback loop · not restart CONTINUITY ACCUMULATES VS. STATELESS RESTART
Every session adds. Nothing resets. The green line is continuity; the red dotted line is what every chatbot does.

Flagship system

CSM - Cross-Session Memory

full case study →

Agents forget. Every session restarts from zero.

Most AI coding agents still lack durable, auditable continuity. Some cache threads or read project rules, but preferences, decisions, mistakes, and hard-won context don't persist across sessions. The prompt gets longer. You re-explain yourself. The agent makes the same mistakes.

  • ❌ No persistence of decisions or preferences across sessions
  • ❌ No verifiable telemetry - "it works" is not auditable
  • ❌ Context windows balloon, costs rise, latency degrades

These numbers came out of a real database snapshot: 2026-07-11 · read-only SELECTs against localhost:5432

The CSM PostgreSQL instance, frozen at the timestamp above and queried once. If a number is on this page, it came from those queries - no estimates, no projections.

Evidence · frozen snapshot

verified 2026-07-11
59,715 Total memories 52,336 live · 7,379 archived
35,635 Memory links (graph) semantic + entity edges
58,317 Memory chunks for vector recall
22,749 Experience packets captured tool events
10,663 Compaction events context distillations
2.015B Tokens saved 90.8% reduction
642,650 Recall events 232 sessions with telemetry · 4 sources
584 Total sessions 214 with telemetry · 370 pre-rollout
111 Belief knowledge promoted entries
8 Self-model caps tracked capabilities
121 Work-ledger changes SHA-256 attributed
969 Tests passing across ~244 files

Every number above was obtained via read-only SELECT against the production CSM PostgreSQL database on 2026-07-11 (localhost:5432). Not estimates, not projections. The 370 sessions without recall logs pre-date the telemetry rollout (Phase 6); they used CSM's memory features but didn't emit recall events to the logging table. See the verification SQL query for the exact statements.

Other systems

In development

These are working prototypes - not finished products. The status labels are direct.

Claudex

IN DEVELOPMENT

Desktop code-indexing agent with semantic search and local embeddings.

Tauri 2 + SvelteKit 5 + Fastify sidecar · M1–M4 complete

World Brief

IN DEVELOPMENT

Automated news documentary generator: RSS → storyboard → rendered video.

Python 9-phase pipeline · 47 briefings produced · 7 live RSS feeds

Sovereign

ARCHIVED

Sub-megabyte WASM agent runtime concept - micro-apps on demand.

Python + FastAPI + Tauri · March 2026 sprint · source archived

rules Six things I haven't been talked out of yet

01

Continuity is the bottleneck

An agent that forgets between sessions is a stateless chatbot wearing a fancy costume. Persistent memory that carries context forward is what makes it useful.

02

Local-first by default

Latency, privacy, and cost all favor running on the machine in front of you. The cloud should have to earn a place in your stack.

03

If you can't audit it, don't trust it

A system you can inspect is worth more than one that performs better but can't be examined. Work ledgers, telemetry, replayability - these are features.

04

Compact

Sub-megabyte binaries, sub-second cold starts, fewer dependencies. Complexity is debt that compounds.

05

Tools over products

A tool the user can compose, extend, and inspect beats a polished product that hides its internals. Build things that get out of the way.

06

Evidence over claims

"It works" is not a specification. Show the logs. Show the metrics. If you can't, don't ship it.

What I'm thinking about.

Some of these shipped. Some are still unproven. One is shelved because it didn't work - the WASM agent micro-app sprint tried to make an LLM into a compiler and the LLM lost. Each is labelled with what it actually is.

Shipped

Living State

A pre-session pipeline that scans recent experience packets, updates the self-model, consolidates beliefs, and emits a living-state block. Running in production since June 2026 - 22,749 packets processed.

Prototype

Virtual context windows

Treat external storage as an extension of the context window. The agent reads from disk the way a process reads from swap. Working in CSM but not the default.

Shelved

Agent micro-apps

LLM as compiler. Didn't work. Specification is the bottleneck, not the runtime.

All research, including the failures →

build log The phases CSM went through to get to v1.0.0

Build log

CSM - how it was built

Each phase was an engineering milestone with tests, docs, and failures that didn't make the headlines.

  1. PHASE 1

    Memory extraction ←→ context injection

    First memory write/recall cycle. Plugin pattern established.

    Shipped

  2. PHASE 2

    Vector similarity search

    Embedding generation, cosine similarity recall, chunking.

    Shipped

  3. PHASE 3

    Graph relationships

    memory_links table, semantic graph traversal, linked recall.

    Shipped

  4. PHASE 4

    Experience packets

    Tool-call event capture, internal-state derivation (load, frustration, energy, stance - classification signals, not simulated emotion).

    Shipped

  5. PHASE 5

    Self-model & belief promotion

    Capability tracking, belief candidates, promotion governance.

    Shipped

  6. PHASE 6

    Recall telemetry & quality audit

    Live recall event logging, recall quality reports, governance buckets.

    Shipped

  7. PHASE 7

    Context compaction

    2.0B tokens saved across 10,663 compaction events. 90.8% reduction.

    Shipped

  8. PHASE 8

    Work ledger & surviving changes

    SHA-256 line lineage, run attribution, work-survival recomputation.

    Shipped

  9. Current

    v1.0.0 · production

    969 tests passing · 59,715 memories · 599 sessions · steady-state operation.

    Live