Context Overflow Eats Requirements: Slice Tasks

Requirement eleven vanished by message forty

A spec held eleven requirements. The session ran forty messages: building, fixing, refining. At message forty-one came the check on requirement eleven (webhook idempotency, the important one). Never implemented. Not rejected, not postponed — absent, as if unwritten. The agent, asked, apologized and explained it had "focused on the core flow."

It hadn't chosen. It had forgotten — attention buried eleven under forty messages of subsequent context, compacted summaries keeping recent work and shedding early constraints. My most important requirement died of distance.

Context overflow fix starts here: sessions don't hold what you tell them at the start past a certain length. Design for forgetting.

Brief survival vs session length

Three things machine forgetting teaches:

1. Recency beats importance, always. Message-3's critical constraint loses to message-37's trivial detail in attention math — models weight recent context heaviest regardless of your priority labels. "IMPORTANT:" prefixes decay like everything else. Position in time outranks emphasis in text, every long session.
2. Compaction keeps work, sheds constraints. Summaries preserve what was built (files, decisions, diffs) and drop what was ruled out (non-goals, prohibitions, edge requirements). The don'ts evaporate first — exactly the requirements whose violation looks like progress. Summarized sessions remember achievements and forget boundaries.
3. Re-stating feels redundant, works perfectly. Repeating key constraints mid-session ("reminder: additive migrations only") feels silly to humans and functions as refresh to models. The embarrassment is social; the mechanism is attentional. Unembarrassed repetition beats dignified forgetting, every forty-message session.

The slicing post covered size. This one covers memory — same enemy, longer fuse.

Context overflow fix protocol

Slice to fit, freeze briefs, re-state load-bearing rules — forgetting designed around, not denied.

Step 1 — Slice tasks to single-session size.

ONE session = ONE behavior + its tests + its proof (≤25 messages target)
multi-behavior features → sequenced sessions, each with its own brief
handover note between: what shipped, what was decided, what still holds

Twenty-five messages keeps the brief within effective attention — requirements from message one survive to message twenty-five. Bigger work sequences through handover notes (written, committed, re-read) instead of marathon threads. Sessions end while memory holds; handovers carry truth forward in text that doesn't decay.

Step 2 — Freeze briefs and re-state the load-bearing three.

brief v1.0 (frozen at session start — mid-flight edits version to v1.1 + restart affected work)
mid-session refresh (message ~15, copy-paste, unembarrassed):
  "Still holding: (1) additive migrations only, (2) ≤40-line routes, (3) no new deps."

Frozen briefs prevent mid-flight drift (edits version explicitly, affected work restarts knowingly). The three-rule refresh re-anchors what compaction sheds fastest — prohibitions and shapes, the exact classes that evaporate. Fifteen is the refresh point because decay shows by twenty; prevention beats resurrection, in memory as in data.

Step 3 — Verify per slice against the slice brief.

# slice acceptance (from ITS brief, not the project brief):
# each requirement → one curl/test/grep, checked before next slice starts
# cross-slice check at the end: all slice briefs' critical lines, re-verified together

Per-slice proof catches drops within the session that dropped them (cheap, contextual, fixable now). End-to-end re-verification catches cross-slice amnesia (requirement eleven, remembered at integration). Two verification scopes because forgetting has two scales: within-session drift and cross-session loss. Both cheap to check, ruinous to discover in prod.

Which is the point — sessions sized for memory, truth carried in text.

Marathon vs sliced months

BoringPush sessions end while memory holds.

The part nobody advertises: slicing plus handovers plus refreshes adds ~10 minutes of ceremony per feature (briefs, notes, re-states) that marathons skip. Priced against seven silently-dropped requirements including one idempotency gap that cost real money: ceremony is cheap, amnesia is expensive, and the embarrassment of repetition fades while incidents don't. Size for memory, write for continuity.

FAQ

How does context overflow fix differ across 200k vs 1M context models?

Bigger windows delay forgetting (more messages before decay) without changing its shape (recency still wins, compaction still sheds constraints). Million-token sessions run longer marathons into the same wall — later, harder, more confident. Slice by requirement count, not token budget: attention quality degrades before capacity fills. Windows grow; wisdom stays sliced.

Should handover notes live in git or chat?

Git (docs/handovers/ or session logs committed): chat scrolls, summarizes, and vanishes across model switches — committed text persists versioned and searchable. Next session reads the note file first (frozen context, exact words), not a summary of a summary. Continuity in files, not in vibes. Write handovers like the next reader is a stranger — it is, even when it's you Monday.

What goes into a handover note versus the brief?

Brief: what TO do (goals, non-goals, acceptance, constraints) — written before. Handover: what WAS done plus what still HOLDS (shipped files, decisions taken, live constraints re-stated) — written after. Briefs face forward, handovers face both ways. Together they chain sessions without shared memory: each session starts briefed and ends handing over.

Can compaction settings fix this instead of process?

Partially: higher compaction thresholds and constraint-preserving summary prompts help (instruct summarizers to keep prohibitions verbatim). But summaries still compress judgment calls into conclusions, losing the reasoning future sessions need. Better summaries delay amnesia; slicing prevents it. Improve the tool AND size the work — either alone leaks eventually.

How do subagent fleets handle context limits?

Worse per agent (each has its own window, its own decay) unless isolated with frozen briefs per agent (the isolation contract covers this: brief version pinned, proof per handoff). Fleet amnesia multiplies like fleet hallucination — same containment (isolate, freeze, verify per link). Parallel forgetting is still forgetting, just concurrent. Govern interfaces, assume decay everywhere.

When is one long session actually fine?

Exploratory spikes (no requirements to drop — learning is the output), single-file tasks (brief fits in working memory regardless), and supervised pair-sessions (human holds requirements, agent holds code). Long is fine when forgetting costs nothing: no constraints, no acceptance lines, no integration pending. Default sliced; marathon by exception, with eyes open.

Keep reading

• Subagents Multiply Hallucinations: Isolate Them — the parallel version of this decay
• Build Features With AI That Don't Need Rewrites — slicing by pipeline layer
• Don't Ship It. Prove It First. — per-slice proof, the companion law