Re-Anchors

83 / 100

SEO Score

Re-Anchors: Give AI Memory Between Sessions - Seekrates AI

How to Give AI a Memory That Survives Closing the Chat

Re-Anchors – You run a four-hour session with your AI agent. Architecture decisions get made. Bugs get fixed. Design pivots get debated and resolved. You close the chat. You come back tomorrow.

The AI remembers nothing.

Not “remembers poorly.” Not “remembers with some gaps.” Nothing. The context window resets. The agent that yesterday understood your database schema, your naming conventions, your architectural constraints, and the three approaches you tried and rejected — that agent is gone. In its place is a polite stranger that asks how it can help you today.

I started calling this phenomenon AI-lzheimer’s Disease. Not as a joke. As a diagnosis.

The Scale of the Problem

For casual users, AI-lzheimer’s doesn’t matter. Ask the AI to write a poem today and a recipe tomorrow, and the lack of continuity is irrelevant. But for anyone building real software across weeks and months of sustained effort, it is devastating.

I hit this wall around session fifty. By session one hundred, I had either solved it or I was going to stop building with AI entirely.

The bootstrap directory — 57 sequential re-anchor files, each one a structured handoff from the previous session. The dates tell the story: sustained, daily, production-grade work.

The Solution: Re-Anchors

The core concept: at the end of every session, create a structured summary; at the start of every session, feed it back.

I call these summaries re-anchors, because they re-anchor the AI to your project’s reality.

That sentence sounds trivially simple. It is not. The devil is in the structure, the format, the protocol, the evolution of the format over time, and the integration with the rest of your development workflow. Getting those details right took me over a year and several hundred sessions.

Re-Anchor Lifecycle — how structured handoffs create session persistence across 57+ sessions.

What a Re-Anchor Contains

A re-anchor is a structured YAML document with defined sections. After months of iteration, the format stabilised to include:

Session metadata — project name, session number, date, roles active, which previous re-anchors were parsed.

State at session end — pipeline status, quality delta (did quality go up or down?), and a one-line summary.

Decisions log — every decision gets an ID and a rationale. This prevents the AI from re-debating settled questions.

Quality scorecard — pass/fail/parked counts across every quality dimension.

Blockers — what’s stuck, who owns it, and what severity.

Next steps — what the next session should work on, in priority order.

A real re-anchor from session 52. Note the quality scorecard — 50 pass, 3 parked, 0 fail, 94% fit-for-purpose.

The Hydration Protocol

Creating re-anchors is half the system. The other half is parsing them. We call this hydration — the process of loading context into a fresh AI session.

The hydration command — four words that trigger the entire context reconstruction.

Sixty seconds later, the AI has reconstructed the complete state of a project spanning dozens of previous sessions. It knows what decisions are settled, what blockers are active, what the next task is, and what methodology governs the work.

The hydration response — complete state reconstruction in under 60 seconds. The AI knows the manuscript status, remaining chapters, revision queue, and blockers.

The Evolution

The first re-anchor I ever wrote was on 4 May 2025. I was working on a project that had grown too complex for a single conversation, and I asked the AI to help me create — and I quote from my own message, typo included — “a re-anchot document.” That misspelling is preserved deliberately in the book.

Within five weeks, I had moved from ad-hoc notes to a repeatable format. Within three months, the format had stabilised into structured YAML. Within six months, the system had expanded to include session protocols, quality gates, and a multi-project governance layer managing six interconnected projects.

Why Longer Context Windows Don’t Solve This

Context windows are ephemeral. They exist for one session. A million-token window that resets to zero is still zero.

Conversation history isn’t structured. You can scroll through past chats. You cannot query “what decisions were made in sessions 40 through 60.”

Memory features are summaries, not state. They store fragments — your name, preferences. They don’t store operational state: decisions, blockers, quality metrics, dependency chains.

The Results

One hundred sessions on a single codebase. Three thousand five hundred lines of production code. One hundred and eleven tests, all passing. Ninety-three per cent first-pass success rate on code deliveries.

Not one dropped thread. Not one re-debated decision. Not one architectural regression.

The re-anchor system didn’t just solve AI-lzheimer’s. It created institutional memory — the kind that, in a factory, lives in shift handover logs and quality manuals. Except this memory is structured, versioned, and queryable. And the senior engineer never leaves.

———

The Re-Anchor Manager — the operating manual for industrial agentic engineering — launches Saturday 15 February. Chapter 1 is free.

Free preview: https://seekrates-ai.com/the-re-anchor-manager/

Full book: https://pixmohan.gumroad.com/l/re_anchor_manager — NZ$19.95