What gets lost when an agent summarizes a long session

What gets lost when an agent summarizes a long session is mostly the precise material: exact values, negative constraints, rejected options and the conditions attached to rules, while the broad goal and recent activity survive. Long sessions eventually run out of room, and tools respond by summarizing or truncating earlier conversation. A summary is a compression, and compression favors the gist. 'We are adding retries to the webhook sender' survives easily. 'Never retry on a 4xx response, because the partner bills per call' often does not, and neither does the port number you agreed on or the library you ruled out an hour ago. The agent carries on fluently, so nothing signals the loss until it makes a choice you had already excluded. The fix is not to avoid summaries but to keep the fragile facts somewhere summaries cannot touch. This article describes what tends to survive, what tends to vanish and how to protect and check the important parts. It does not describe any particular tool's internals.

What a summary usually keeps

Summaries are good at the shape of the work. Whatever method a tool uses, a condensed version of a long conversation tends to preserve:

The overall goal, especially if it was repeated several times.

The recent state: the last few files edited, the current failing test, the step in progress.

The main storyline: 'investigated the timeout, found it in the sender, added a retry loop'.

Names that appear often: the main modules, the feature, the ticket number.

This is why a summarized session feels continuous. The agent still knows what it is doing and can describe it convincingly. For many tasks that is enough, especially short ones where the early conversation held little that mattered.

The trouble is that the facts a summary keeps are the ones you would rarely need to repeat. Frequency and recency decide what survives, not importance. A rule mentioned once, early, carefully, is exactly the kind of statement that loses out. The general mechanics of a filling window are covered in context window limits for coding agents; this page is about the specific content that goes missing when the window is compressed.

What tends to vanish

Five kinds of information are fragile under summarization.

Negative constraints. 'Do not change the public API', 'do not add dependencies', 'leave the CSV format alone'. Summaries describe what was done, and prohibitions are about what was not done, so they drop out easily.

Rejected options and their reasons. 'We tried a queue library and dropped it because the service must stay dependency-free.' The summary may keep 'tried a queue library' and lose the reason, or lose both, inviting the agent to try again.

Exact values. Port numbers, version pins, thresholds, timeouts, error strings, file paths and line numbers get rounded into prose: 'configured the timeout' instead of 'timeout is 30 seconds, not 60'.

Conditions and exceptions. 'Retry on 5xx, never on 4xx, except 429' collapses to 'added retries'.

Uncertainty and provenance. 'The cache might be the cause, unconfirmed' becomes 'the cache is the cause'. Who decided something, and whether it was a decision or a guess, also disappears.

When an agent reopens a settled question or picks a value you never agreed to, one of these is usually the reason. An agent that forgot decisions covers the troubleshooting side.

Protect the important facts before a summary happens

Anything that must survive should live in a file the agent rereads, not only in the conversation.

Write constraints into the task record as soon as they are agreed. A line under 'Constraints' in the task file costs seconds and outlasts any session. Per-task Markdown memory gives a structure for this.

Keep a 'Rejected' list with reasons. One line per option: what, why not, date.

Pin exact values in code or config, not in chat. If the timeout is 30 seconds, it should be a named constant with a comment, and the task record should name the constant.

Put lasting decisions in decision records. Choices that will matter beyond this task belong in architecture decision records.

Mark uncertainty in writing. 'Hypothesis, unconfirmed' in a finding stops it hardening into fact.

Checkpoint before long operations. Before a large refactor or a long debugging run, ask the agent to update the task record with current constraints and state. If the session is compressed during that work, the record is still intact.

Prefer fresh sessions to marathon ones. Ending a session and starting a new one from a good record is often safer than letting a long one compress itself repeatedly.

Check the summary after it happens

You often cannot see exactly when a session was compressed, but you can test what the agent still knows.

Ask for the constraints, not the progress. 'List every constraint and rejected option for this task.' Compare the answer with your task record. Missing items tell you what was lost, and you can restate them, or better, point the agent back at the record.

Ask for exact values. 'What timeout, port and retry count are we using?' Vague answers are a warning sign.

Watch for drift signals: the agent proposes something you rejected, re-reads files it already analyzed, or describes a hypothesis as a finding.

Reload from the record rather than re-explaining. Telling the agent again in chat adds the facts back to a window that is already full, and they will be compressed again. 'Re-read tasks/ENG-42.md before continuing' puts them back at full fidelity.

When the drift is large, stop and start over: update the record, end the session and begin a fresh one from the record. That is the routine in how to hand off an AI coding session, applied to yourself.

None of this depends on how a particular tool compresses context. It only assumes that some loss will happen.

QUESTIONS

Why does my agent ignore constraints late in a long session?

Often because the constraint was stated once, early, and was lost or weakened when the conversation was summarized to make room. Prohibitions and exceptions are especially fragile. Put constraints in a task file the agent rereads, and ask it to list them before risky steps to confirm they are still known.

Should I ask the agent to summarize the session itself?

Yes, as a draft, and then correct it against your record. A requested summary at a checkpoint is better than an automatic one under pressure, because you can check it for missing constraints, rejected options and exact values. Save the corrected version to the task record, not the chat.

How do I check whether a summary dropped something important?

Ask targeted questions: list every constraint, every rejected option with its reason, and the exact values in use. Compare the answers with your written record. Anything missing or vague was likely lost. Reload the record rather than retyping the facts into an already crowded conversation.

RELATED GUIDES

• How to create a project card in BRAIN FLUID Desk
• What is a project management harness?

RELATED HARNESS PAGES

• Context window limits for coding agents Context window limits for coding agents: what fills the window in real work, what gets dropped first and how it turns into mistakes.
• Why did my AI agent forget what we decided yesterday? Agent sessions don't carry memory, and decisions left in chat vanish. Find where the decision lives, write a record, and read it at session start.
• Per-task Markdown memory Per-task Markdown memory: one short record per unit of work, with outcome, scope, criteria, findings and next step, instead of one global notes file.
• Why does my AI agent ignore project instructions? Agents skip project instructions that are buried, contradicted, lost to context limits or too vague to act on. How to find which, and fix it.