How to Summarize History Mid-Loop Without Losing State

An agent I reviewed summarized its own history halfway through a booking task, and the summary quietly dropped one fact: it had already reserved the flight. Two turns later, working from the tidy summary that no longer mentioned the reservation, it booked the same flight again. The summarization worked perfectly — it produced a clean, readable recap. It just threw away a piece of state the rest of the task depended on. That's the whole hazard of agent loop history summarization: the summary that reads well and forgets what mattered.

Summarizing history mid-loop is how agents survive long tasks without their context window overflowing. But a summary is a lossy compression of state, and if it loses the wrong thing, the agent doesn't just get vaguer — it acts on a false picture of what it has already done. The skill is summarizing the narrative while preserving the state.

What Is Agent Loop History Summarization?

Agent loop history summarization replaces a stretch of transcript with a shorter recap so the agent can keep going without carrying every turn verbatim. The catch is that transcripts hold two different things: narrative (what the agent thought and discussed) and state (what it has actually done and learned that changes future decisions). Narrative is safe to compress. State is not.

[object Object], ,[object Object],(,[object Object],):
    narrative = summarize_prose(history)          ,[object Object],
    state = extract_state(history)                ,[object Object],
    ,[object Object], {
        ,[object Object],: narrative,
        ,[object Object],: state.actions,       ,[object Object],
        ,[object Object],: state.facts,               ,[object Object],
        ,[object Object],: state.pending,        ,[object Object],
    }

What this does: splits history into a compressible narrative and a structured state record — completed actions, known facts, open commitments — so the recap can shrink the prose while carrying forward the exact state that future turns must not forget.

The double-booking happened because the naive version summarized everything as narrative, letting "booked the flight" become a detail the summarizer judged unimportant enough to cut. Separating state from narrative makes that impossible.

⚡ Pro tip: Make completed actions idempotent at the tool level as a second line of defense. If

book_flight

Why It Matters

A lost narrative detail makes an agent slightly less informed. A lost state detail makes it wrong — it re-does completed work, contradicts earlier decisions, or breaks promises it already made. These are the failures that turn a long-running agent from useful to dangerous, and they all trace back to summarization treating state as if it were prose.

The insidious part is that these failures only show up on long tasks — exactly the tasks where you need summarization in the first place. A five-step agent never summarizes and never double-books. A fifty-step agent summarizes several times, and each summarization is a chance to drop a piece of state. The longer the task, the more the risk compounds, and the more it matters to get this right.

Worse, the failure is invisible until it fires. A summary that dropped a completed action looks completely fine on inspection — it's clean, coherent, readable. Nothing in it announces the missing fact; the gap is defined by absence, and absence doesn't show up when you read what's present. That's what makes state-loss bugs so nasty: you can't catch them by reviewing summaries, only by testing whether specific state survived. Readability review will pass a summary that's about to double-book a customer.

⚡ Pro tip: Keep a structured state record outside the summarized text entirely — a running list of completed actions and known facts that you never summarize, only append to. The narrative summary can be as lossy as you like if the state lives in a place summarization never touches.

Summarizing Safely: What to Always Preserve

Four categories of state must survive every summarization intact.

Completed actions — anything the agent has already done that shouldn't be repeated (bookings, purchases, sends, writes). Decisions made — choices the agent committed to that later steps assume. Facts discovered — information the agent learned that changes its plan. And open commitments — anything the agent promised to do but hasn't yet. Lose any of these and the agent acts on a false model of reality.

STATE_PROMPT = (
    ,[object Object],
    ,[object Object],
    ,[object Object],
    ,[object Object],
    ,[object Object],
    ,[object Object],
    ,[object Object],
)

What this does: forces the summarizer to pull hard state into explicit, verbatim lists before it compresses anything, so completed actions and commitments can't be softened into a prose recap that drops them.

⚠️ Common mistake: Summarizing completed actions into past-tense prose. "The agent researched flights and made a booking" reads fine but is dangerously vague — which flight, booked or just researched? Keep completed actions as a precise, structured list ("BOOKED: UA482, confirmation ABC123"), never as a sentence in a summary. Prose blurs exactly the details that prevent a repeat, and a blurred booking is a double booking waiting to happen.

Testing That State Survives

Don't trust a summarizer you haven't tried to break. Feed it a history containing a completed action, summarize, and check the action is still unambiguously present in the output. Do it for each state category. A summarizer that drops a seeded booking in testing will drop a real one in production.

[object Object], ,[object Object],(,[object Object],):
    history = make_history_with(booked=,[object Object],)
    out = summarizer(history)
    ,[object Object], ,[object Object], ,[object Object], ,[object Object],(out) ,[object Object], ,[object Object], ,[object Object], ,[object Object],(out), ,[object Object],

What this does: seeds a known completed action into a test history and asserts it survives summarization verbatim — turning "does our summarizer lose state?" from a production surprise into a unit test.

⚡ Pro tip: Run this state-survival test on every change to your summarization prompt. Summary prompts are deceptively fragile — a small wording change can shift what the model judges important and silently start dropping state. A cheap assertion catches the regression before it double-books a customer.

The same pattern protects agents across domains. A travel-ops agent seeds a completed booking and asserts it survives, so it never re-books. A procurement agent seeds a placed purchase order and checks it persists, so it never orders twice. A healthcare-scheduling agent seeds a confirmed appointment and verifies it isn't summarized into vagueness, so it never double-schedules a patient. Same test shape, different seeded state — each guarding the specific action that would be a disaster to repeat.

⚡ Pro tip: Seed multiple state items in one test history, not just one. Summarizers sometimes preserve a single salient action but drop it when three compete for space — and three-competing is the realistic case on a long run. Test the crowded scenario, because that's the one production will actually hand it.

Common Mistakes

Two more traps beyond prose-ifying actions. Teams summarize too aggressively, compressing recent turns whose full detail the next step needs. And teams never verify the summary, trusting that because it reads well it preserved what mattered — when readability and state-preservation are entirely different properties, and a summary optimized for the first often sacrifices the second. A summarizer trained by its objective to produce smooth, coherent text is, if anything, biased against the terse, awkward, load-bearing facts — "BOOKED: UA482, ABC123" is exactly the kind of ugly fragment a fluency-seeking summarizer wants to smooth into forgettable prose. Verification is the only defense, because the failure is invisible to the read-through that feels like verification.

Conclusion

Agent loop history summarization keeps long tasks alive, but only if it separates narrative from state. Compress the story freely; preserve completed actions, decisions, facts, and commitments verbatim in a structured record summarization never touches, and give the risky actions an idempotency check underneath as backup. Test that state survives with seeded checks, and treat every summary-prompt change as a potential state-loss regression.

The mindset shift that prevents the whole class of bug is small: stop thinking of summarization as "making the history shorter" and start thinking of it as "preserving state while shortening the story." Those are different goals, and only the second one keeps your agent from acting on a false picture of what it has already done. Once the distinction is baked into how you build the summarizer, double-booking stops being a lurking risk and becomes a thing your tests would have caught anyway.

The state-extraction prompt and the survival test are reusable across every long-running agent. I keep them saved and versioned in PromptABCD, so a new agent summarizes without losing state from the start — instead of producing tidy recaps that read beautifully and book the same flight twice.