The Window Is Not Memory
Every AI coding assistant has a context window. It feels like memory. It is not. It is a scratchpad — one that fills up, gets summarized, and can vanish entirely when the process crashes, the model switches, or the session ends.
This distinction matters because developers build trust with their AI assistant over the course of a session. Decisions get made, architecture gets discussed, trade-offs get weighed. All of that lives in the transcript — until it does not. And there are more ways to lose it than most people realize.
Six Ways Continuity Breaks
Each row below is a different failure mode. They feel similar ("the AI forgot") but have different causes and different catches.
| What breaks | What it feels like | What catches it |
|---|---|---|
| Window fills up | Agent "forgets" early decisions | Auto-memory (durable facts) + todo-mcp tasks (the plan) |
| Compaction / summarization | Detail goes fuzzy mid-conversation | Context breadcrumbs re-hydrate the depth |
| Crash or process killed | Everything in flight is gone | Write-ahead breadcrumbs + context_resume |
| Model switch | New model has no idea what is happening | State lives in the MCP, not the model — handoff is clean |
| Session ends, you come back tomorrow | "Where was I?" | context_resume + todo_list + sprint-resume memory |
| Multi-week project | Strategic thread lost across sittings | Tasks with dependencies, one in progress at a time |
Six failure modes. One persistent store that catches all of them.
Failure 1: The Window Fills Up
Context windows have a token limit. As the conversation grows, earlier messages are summarized or dropped. The agent retains the gist but loses the specifics — the exact interface you agreed on, the reason you chose one approach over another, the edge case you discussed twenty minutes ago.
The catch: anything that must survive goes into a durable store before the window needs to discard it. Auto-memory holds stable facts and lessons. Todo-mcp tasks hold the strategic plan. Neither depends on the transcript staying intact.
Failure 2: Compaction Hits Mid-Conversation
This is the subtle one. Two hours into a dense design conversation, the window compacts. The summary preserves the outline but loses the texture — the specific field names, the exact error message that led to a decision, the ordering constraint you worked out together.
The catch: the working depth was never only in the transcript. The task list holds the structure of the work. Progress breadcrumbs hold the fine-grained state. Auto-memory holds the decisions and their rationale. When compaction hits, the agent re-hydrates from the store and the next reply lands at full fidelity. The user never feels the seam.
Failure 3: Crash or Process Killed
The CLI crashes. The container gets killed. The SSH session drops. Unlike compaction, which preserves a summary, a crash preserves nothing from the conversation.
The catch: write-ahead breadcrumbs. As the agent works, it drops a progress marker after every meaningful step — before it needs them. The same principle databases use to survive power loss. On restart, context_resume reads the breadcrumb and the agent knows exactly where it was: what is done, what was in progress, what is next. Recovery takes seconds, not the twenty minutes of re-derivation it would otherwise require.
Failure 4: Model Switch
You use a powerful model for the hard design work, then hand off to a faster model for routine execution. Or your tool switches models under the hood. Either way, the new model starts with zero knowledge of what came before.
The catch: state lives in the MCP server, not inside any single model. The new model runs context_resume, reads the same tasks and breadcrumbs, and continues from exactly where the previous model left off. No re-explanation needed. The state never lived in the model to begin with — so swapping the model does not lose the state.
Failure 5: Session Ends, You Come Back Tomorrow
You close your laptop Friday mid-sprint. Monday morning, a fresh session has no idea what you were doing. This is the most common continuity break and the one most developers have simply accepted as the cost of working with AI.
The catch: context_resume is the first command of every session. It returns the active sprint, the task in progress, recently completed tasks, the next recommended task, and any open context. Zero ramp-up. Cold start to fully oriented in one command.
Failure 6: Multi-Week Projects
A project spans weeks. Individual sessions work fine, but the strategic thread — what has been done, what depends on what, what the overall arc looks like — gets lost in the noise of daily work.
The catch: todo-mcp tasks carry permanent IDs and explicit dependencies. Task #8 depends on #7; the agent will not start #8 until #7 is complete. The backlog is always readable, always sequenced, and always reflects the true state of the project — not a stale snapshot from a planning session three weeks ago.
The Architecture Behind the Catches
These six catches are not six separate systems. They are different views of the same four-system architecture:
- Auto-memory — stable facts, preferences, lessons. Auto-loads every session.
- Todo-mcp tasks — strategic work units with IDs and dependencies. Persistent across sessions.
- Todo-mcp context — write-ahead breadcrumbs for crash protection. Cheap, frequent, durable.
- TaskCreate — the live subtask checklist for the current task. Visible to the user in real time.
Each system handles a different kind of state at a different cadence. Together, they ensure that no matter which of the six failure modes hits, the agent has what it needs to continue without losing its place.
What Recovery Actually Looks Like
Here is the shape of a cold-start recovery — Monday morning, fresh session, no transcript:
Active sprint: Identity & Restore
In progress: #7 Harden auth module (blocked on test fixture)
Recently done: #4, #5, #6
Next up: #8 Wire restore-integrity checks (depends on #7)
Open context: decision — DB stays per-environment; coordinate via filesThe agent reads this and immediately knows: resume task #7, build the test fixture that was blocking it, then move to #8. No re-reading the repo. No "remind me what we were doing." One command and the session is oriented.
The Core Frame
The context window is shallow and volatile. Todo-mcp is deep and durable. Skills are the protocol between them — the versioned procedures that ensure state moves from the volatile window into the durable store in the same trustworthy way every time.
Your context window will forget. Your project does not have to.
Getting Started
If you are already using Todo-MCP, you have all six catches in place. The mastery documentation walks through the breadcrumb protocol, the task dependency model, and the session-start sequence that ties them together.
If you have not tried it yet, start with the problem you feel most: if it is crash recovery, read about the breadcrumb pattern. If it is session continuity, the four-system architecture is where it all fits together.