skip to content

What must a compaction summary carry forward in a long agent session?

level: middleimportance: must knowfreq 68%

answer

  1. what only the transcript knows
  2. goal, decisions, open artifacts
  3. reasons, not just choices
  4. pointers beat copies
  5. re-read files, do not summarize them

basics

~20 s

Four things only the conversation knows: the goal with any standing constraints, the decisions already made and why, the artifacts still open mid-edit, and the approaches already ruled out. Anything readable from a file or a query should be a pointer, not a copy.

solid answer

~50 s

Split the history into what only the transcript knows and what the world still holds. **Only the transcript knows** the goal and the user's standing constraints, the decisions made and the reasoning behind them, the state of anything in flight — which file is half-edited, which step of the plan is next — and the approaches already tried and rejected, so the agent does not loop back into them. Those must be written into the summary explicitly, ideally against a fixed template rather than left to the model's discretion. **The world still holds** file contents, query results, log output and repository state; for those, carry only the identifier — a path, a query, an issue id — and re-read at the point of use. Re-reading is cheaper than summarizing and returns the current version rather than a stale snapshot of something the agent itself may since have changed.

code

json · 11 lines
json
{
  "goal": "migrate the orders schema to a tenant-scoped layout",
  "standing_constraints": ["never run against production", "no downtime window available"],
  "decisions": [
    {"choice": "tenant_id stays nullable during backfill", "reason": "NOT NULL add locked the table in staging"},
    {"choice": "backfill in 10k-row batches", "reason": "larger batches pushed replica lag over 2s"}
  ],
  "open_artifacts": ["db/migrations/2026_08_orders_tenant.sql (half written, step 3 of 5)"],
  "rejected": ["single ALTER TABLE with NOT NULL - locked the table"],
  "reread_from_source": ["db/schema.sql", "docs/migration-runbook.md"]
}

go deeper

for a junior

Know that the summary must keep the goal and any rules the user gave, and that files can simply be read again rather than copied into the summary.

for a middle

Be able to sort the history with the test 'does this fact exist anywhere but the transcript?', and name the four categories that must survive: goal with constraints, decisions with reasons, open artifacts, rejected approaches.

for a senior

Argue for a fixed template over model discretion, explain why re-reading beats summarizing on both cost and staleness, and describe the behavioural symptoms you monitor to catch a defective summary in production.

for a principal

Own the design question of what session state should never have lived in the transcript at all — pushing goals, constraints and plans into durable artifacts so compaction becomes a routine event rather than a risk to the run.

## The organizing question When a four-hour database-migration agent crosses its compaction threshold mid-run, the useful question is not "what is important?" — everything felt important when it was written. It is: **which of these facts exists nowhere except in this transcript?** That test sorts the history cleanly. ## What only the transcript knows **The goal, with its standing constraints.** The migration's objective survives easily because the agent restates it constantly. What gets lost is the constraint stated once and never repeated — "never run this against prod." Nothing in the codebase encodes it. If it drops, the agent has no way to know it ever existed, and the next plausible-looking step may be exactly the forbidden one. Treat standing constraints as a mandatory section of the summary, not a judgement call. **Decisions and their reasons.** Suppose the agent decided to keep the new column nullable through the backfill because a NOT NULL add locked the table in staging, and to batch the backfill at ten thousand rows because larger batches pushed replica lag past two seconds. The decisions may be visible in the migration file; the *reasons* are not. A summary that carries the choice without the reason invites the agent to revisit and reverse it the next time the tradeoff surfaces. **Open artifacts and position in the plan.** Which file is half-written. Which step of a five-step plan is done. Which long-running job is in flight and how you check on it. Without this the agent either redoes finished work or reports success on work it never completed. **Rejected approaches.** Negative results are expensive to reacquire — each one cost a failed attempt. "Single ALTER TABLE with NOT NULL: locked the table in staging" is one line that saves the agent from paying for that lesson twice. ## What should be a pointer instead File contents, full tool output, log dumps, query results, directory listings. These are the bulk of a long session's tokens and almost never belong in a summary, for three reasons. First, **cost asymmetry**: summarizing a file costs a model call now and still yields a lossy copy; carrying the path costs a few tokens and yields the real thing on demand. Second, **staleness**: in an agent session the agent is often the thing mutating those files. A summary of a schema file written an hour ago may describe a state the agent has since edited away. Re-reading returns truth; a summary returns a memory. Third, **compounding drift**. If a session compacts several times, a summarized copy gets summarized again, and again, each pass introducing distortion. Pointers do not degrade — a path is a path after ten compactions. The practical form is a summary rich in identifiers: file paths, query strings, ticket ids, branch names, the exact command that produced a result. The agent then loads what it needs through its tools when it needs it. ## Structure beats prose A free-form narrative summary is where constraints go to die — the model writes a flowing account of what happened and the one-sentence prohibition from three hours ago simply does not make the edit. A fixed template with required sections (goal, constraints, decisions with reasons, open artifacts, rejected approaches, pointers to re-read) forces each category to be considered, and makes an omission visible when you inspect the summary. Some teams go further and keep the durable parts in a file the agent maintains as it works, so the summary is partly a pointer to that file rather than the sole custodian of the session's history. ## Write before you clear The ordering constraint is easy to get wrong. Anything you intend to persist outside the window — notes to a file, facts to a store — must be written **before** the history is cleared, not after. Once the messages are gone the model cannot author a note about them, and a harness that clears first and then asks the agent to record what it learned is asking a question that can no longer be answered. ## How you know it is working Instrument for the symptoms of a bad summary rather than grading summaries directly: does the agent repeat completed work, re-ask the user for something already stated, re-try an approach already rejected, or propose something a stated constraint forbids? Each maps to a missing section, which is a fixable defect in the template rather than a mysterious model failure.

  • Why carry a rejected approach forward at all — isn't that wasted tokens?
    Negative results are the most expensive facts in the session; each cost a failed attempt and possibly a damaged environment. One line recording that a single ALTER TABLE with NOT NULL locked the table stops the agent from rediscovering it at full price, and stops it from re-proposing something a human already vetoed.
  • A session has compacted three times. What degrades across those passes?
    Anything summarized rather than pointed at, because each pass re-summarizes the previous summary and drift compounds. Constraints and decisions survive if the template makes them mandatory sections copied forward near-verbatim; free-form narrative erodes fastest. Pointers do not degrade at all, which is the strongest argument for preferring them.
  • Where in the sequence should durable notes be written?
    Before the clear, always. Once the history is removed the model cannot author a note about material it can no longer see. A harness that clears first and then asks the agent to record what it learned is asking an unanswerable question, and the loss is silent — you get a plausible but empty note.

It is the handover note you leave when going on leave mid-project: the decisions and their reasons, what is half-done, and what you already tried and abandoned — plus where the documents live, not photocopies of them.

saying these in an interview costs you the question

  • Summarizing file contents instead of keeping the path and re-reading
  • Recording decisions without the reasoning behind them
  • Letting the model write a free-form narrative with no required sections
  • Assuming a constraint stated once will survive because it mattered
  • Writing notes to durable storage after clearing rather than before

context

resolving links…