Lecture 05. Maintaining Continuity Across Sessions

You ask Claude Code to implement a full feature. It runs for 30 minutes, gets most of the work done, but context is running low. You start a new session to continue — and discover it doesn't remember which decisions were made last time, why option A was chosen over option B, which files were modified, or what state the tests are in. It spends 15 minutes rediscovering the project, and might end up inconsistent with the previous approach.

Imagine you're a craftsman who forgets everything every morning when you wake up. You have to re-familiarize yourself with the entire construction site — which wall is half-built, why red brick was chosen over blue brick, how far the plumbing has been run. Worse still, you might rip out a window that was installed yesterday, simply because you don't remember it was finished.

This is exactly the difficult situation AI coding agents face on cross-session tasks. This lecture explains why agents "lose their memory" on long tasks, and how structured state storage can make them behave like a craftsman who keeps a reliable daily journal — still amnesiac, but the journal remembers everything.

The Context Window: Not Infinite

The context window is finite. This can't be solved by upgrading the model — even if the window size grows to 1M tokens, complex tasks will still exhaust it. Because agents don't just generate code; they understand the codebase, track their own decision history, process tool results, and maintain conversation context. All of this information grows faster than the window expands.

A deeper problem: the information an agent generates is uneven in importance. Intermediate reasoning steps contain the "why" of decisions — why option B was chosen over A, why this library over that one, why a particular optimization was skipped. The final output only contains the "what" — the code itself. Compaction strategies typically preserve the latter but lose the former. The next session sees the code but doesn't know why it was written that way, and might "optimize away" a deliberate design decision.

Anthropic uncovered something fascinating in their research on long-running agents: when agents sense context is running low, they exhibit "premature convergence" behavior — rushing to finish the current work, skipping verification steps, or choosing a simple solution over the optimal one. It's like realizing time is almost up during an exam and quickly guessing the remaining multiple-choice questions. Anthropic calls this "context anxiety."

The Session Continuity Flow

Without continuity artifacts, every new session is a disaster:

With continuity artifacts, new sessions can pick up quickly:

Core Concepts

The context window is finite: Regardless of the advertised window size (128K, 200K, 1M), long tasks will eventually exhaust it. Once exhausted, you must either compact (losing information) or reset (new session). Both lose something.
Continuity Artifacts: Stored state files that let a new session resume unambiguously from where the last session left off. Basic form: progress log + verification record + next actions. That craftsman's journal.
Rebuild Cost: The time a new session needs to reach an executable state. A good harness can compress rebuild cost from 15 minutes down to 3 minutes.
Drift: The gap between the agent's understanding and the actual state of the code repository. Every session boundary creates drift; left unchecked, it accumulates.
Context Anxiety: The phenomenon observed by Anthropic — agents exhibit premature convergence behavior as they approach the perceived context limit, ending tasks early to avoid losing information. It's irrational resource anxiety.
Compaction vs. Reset: Compaction summarizes context within the same session (keeps the "what," may lose the "why"); reset opens a new session that rebuilds from stored state (clean but depends on artifact completeness).

What Happens When Continuity Breaks

The previous session spent significant context budget analyzing three approaches and choosing option B. This session's agent doesn't know about that analysis and might re-decide based on incomplete information — possibly choosing option A. It's like the amnesiac craftsman who doesn't remember why red brick was chosen, looks at the blue brick today and thinks it looks nicer, and tears down yesterday's wall to rebuild it.

Even worse is duplicated work. The agent isn't sure whether some work is already done and redoes it. Or worse — does it halfway, discovers a conflict with an existing implementation, and has to redo it. On a construction site, two crews can't build the same wall at once — but without a progress record, the new crew doesn't know someone is already working on it.

Across multiple sessions, the implementation direction can quietly drift away from the original requirements. Each new session has a slightly different understanding of the project's goals. It's like the telephone game — after ten people relay the message, "get me a cup of coffee" can turn into "buy me a coffee machine."

There's also a verification gap. The previous session's verification results (which tests passed, which failed, why they failed) go unrecorded. The new session has to rerun all verification to understand the current state. Each session re-diagnoses from scratch, wasting precious context every time.

Both OpenAI and Anthropic emphasize structured state storage in their documentation. OpenAI's harness engineering post treats the repository as an "activity log" — the result of every activity should leave traceable evidence in the repo. Anthropic's long-running agent documentation specifically recommends "handoff files" — structured documents containing current state, known issues, and next actions.

A Journal for the Amnesiac Craftsman

Core approach: Treat the agent like a brilliant engineer with amnesia. Before it "clocks out," it must record important information so the "next shift's" agent can pick up quickly.

Tool 1: Progress file (PROGRESS.md). The most basic continuity artifact — the core of the journal:

# Project Progress

## Current Status
- Latest commit: abc1234 (feat: add user preferences endpoint)
- Test status: 42/43 passing (test_pagination_edge_case failing)
- Lint: passing

## Completed
- [x] User model and database migration
- [x] Basic CRUD endpoints
- [x] Auth middleware integration

## In Progress
- [ ] Pagination feature (90% - edge case test failing)

## Known Issues
- test_pagination_edge_case returns 500 on empty result sets
- Need to confirm whether deleted users should appear in the listing

## Next Steps
1. Fix the pagination edge case
2. Add an "include deleted users" query parameter
3. Update API documentation

Tool 2: Decision log (DECISIONS.md). Records important design decisions and their rationale. No need for a detailed design document — just "what was decided, why, when" — journal entries:

# Design Decisions

## 2024-01-15: Use Redis to cache user preferences
- Rationale: High read frequency (every API call), small data size
- Rejected option: PostgreSQL materialized view (high change frequency makes maintenance cost not worthwhile)
- Constraint: Cache TTL of 5 minutes, active invalidation on write

Tool 3: Git commits as checkpoints. Commit after completing each atomic unit of work. Commit messages should explain what was done and why. These are free, automatically versioned state snapshots.

Tool 4: init.sh or harness initialization flow. Specify "start of shift" and "end of shift" routines in AGENTS.md:

## When starting a session (start of shift)
1. Read PROGRESS.md for current status
2. Read DECISIONS.md for important decisions
3. Run make check to confirm the repo is in a consistent state
4. Continue from the "Next Steps" section of PROGRESS.md

## Before ending a session (end of shift)
1. Update PROGRESS.md
2. Run make check to confirm consistent state
3. Commit all completed work

Mixed strategy: Not every task needs a context reset. Short tasks (under 30 minutes) can be completed in a single session. Long tasks (spanning sessions) should use progress files and decision logs for continuity. Decision criterion: if a task needs more than 60% of the window, start preparing a handoff.

A Deeper Look at Context Anxiety

Anthropic's March 2026 research further revealed specific manifestations of context anxiety: on Sonnet 4.5, as context approaches the window limit, the agent shows strong "premature convergence" behavior. It's like realizing time is almost up on an exam and quickly filling in random answers on the remaining multiple-choice questions.

Two strategies address this:

Compaction: Summarizes the earlier part of the conversation within the same session. Advantage: maintains continuity, the agent can still see the "what." Disadvantage: the "why" is often lost in the summaries — why option B was chosen over A, why a particular optimization was skipped. More importantly, compaction doesn't eliminate context anxiety — the agent knows the context was once large, and psychologically still tends to rush toward finishing.

Context Reset: Completely clears context, opens a new session, rebuilds from stored artifacts. Advantage: a clean state of mind — the new session has no "I'm about to run out of time" anxiety. Disadvantage: depends on the completeness of the handoff artifacts. If the journal is missing critical information, the new session may waste time going in the wrong direction.

Anthropic's real-world data: for Sonnet 4.5, context anxiety is severe enough that compaction alone isn't sufficient — context reset becomes a critical component of harness design. But for Opus 4.5, this behavior is significantly reduced, and compaction alone can manage context without relying on reset. This means: harness design needs specific understanding of the target model, not a one-size-fits-all template.

Source: Anthropic: Harness design for long-running application development

Real-World Example

An agent was tasked with implementing a blog system with user authentication — 12 feature points, estimated to need 5 sessions.

Without a journal: Session 1 implements the user model and basic routes. Session 2 begins without the agent remembering the auth middleware's interface contract, spending ~15 minutes inferring the design intent beforehand. By session 3, accumulated drift causes the agent to start re-implementing already-completed features. By session 5, the repo contains a lot of redundant code but the core auth feature still doesn't pass end-to-end tests. Only 7 of 12 feature points are complete, 3 have hidden correctness issues. It's like the craftsman who never kept a journal — by day five, the construction site is chaos, some walls built twice, some that should have been built never started.

With a journal: Uses a progress file, decision log, verification record, and git checkpoints. Status reports are automatically updated at the end of each session. Session 2's rebuild cost drops to ~3 minutes. By session 5, all 12 feature points are complete and verified.

Quantitative comparison: rebuild time down ~78%, feature completion rate from 58% to 100%, hidden defect rate from 43% down to 8%. The craftsman is still amnesiac, but with a journal, each day starts where yesterday left off, not from scratch.

Key Takeaways

The context window is a finite resource. Long tasks will span multiple sessions, and sessions will lose information — like the craftsman forgetting every day, this is objective reality.
The solution isn't a bigger window — it's better state storage. Progress file + decision log + git checkpoints — give the amnesiac craftsman a reliable journal.
Treat the agent like an engineer with amnesia: before "clocking out," record what was done, why, and what's next.
Rebuild cost is the key metric. A good harness should bring new sessions to an executable state within 3 minutes.
Mixed strategy: short tasks within a session, long tasks with structured artifacts for continuity.

Exercises

Measure continuity loss: Pick a development task requiring at least 3 sessions. Provide no continuity artifacts, and record at the start of each session how much context the agent spends "figuring out what happened last time." After each session, create a progress file and let the next session start from it. Compare rebuild cost with and without the progress file.

Design a handoff template: Design a minimal handoff template with four fields: repo state (commit hash), runtime state (test pass rate), blockers, next actions. Have a completely fresh agent session recover the project's state using only this template. Record every ambiguity encountered during recovery, iteratively improving the template.

Mixed strategy experiment: In a 5-session development task, compare three strategies: (a) always start a new session + progress file, (b) do as much as possible in one session (context compaction), (c) mixed strategy (short tasks within a session, long tasks across sessions + progress file). Compare rebuild time, feature completion rate, and decision consistency.