State Management at Depth, Sliding Windows and Summaries

What it costs to let a message list just keep growing

tools-memory-and-multi-agent-systems lesson 18 tracked a venue-booking agent doing the same task twice: GBP 0.42 and 14 minutes with no working memory strategy, GBP 0.04 and 90 seconds once one was in place. That comparison is cross-session memory, not LangGraph's in-graph state, so treat it as a stakes argument, not a LangGraph benchmark. The shape of the cost is the same either way: a messages list that never shrinks eventually costs real money and hits real limits, whether the state resets every session or grows unbounded within one.

Five exercises, one decision, never named

This course's own source material's unit 1.2 walks through five separate exercises: extended state fields, multi-node message processing, sliding windows, summarization, and a multi-node pipeline that combines the earlier pieces. Read in order, each one adds a technique. None of them steps back to name the actual decision underneath all five: every pruning strategy is a bet about what you're willing to lose.

A sliding window bets that only recent messages matter, and throws the rest away completely. A summary bets that the gist of older messages matters more than their exact wording, and compresses instead of discarding. Both exist to solve the growing-cost problem above: a window and a summary are just two different bets about what you can afford to lose while solving it.

The two strategies, and what each one actually throws away

def trim_messages(state: State) -> State:
    """Keep only the last N messages. Older messages are gone, not compressed."""
    window_size = state.get("window_size", 10)
    messages = state["messages"]
    if len(messages) <= window_size:
        return state
    return {"messages": messages[-window_size:]}

A window is cheap and lossy: no LLM call, but anything outside the window is gone, not compressed. Summarization costs an extra call (or a cheaper heuristic) but preserves the gist of what got trimmed. Neither is universally correct. A window is the right bet when older turns stop mattering entirely, a customer support handoff where only the current issue's context matters. A summary is the right bet when the thread of a long task depends on decisions made many turns back, exactly the kind of task the Edinburgh case describes, where "we already ruled out nine venues" has to survive somehow.

The question this course's own source material never asks

Neither the sliding-window exercise nor the summarization exercise asks the reader to justify the choice. Both are presented as "here's how you'd implement this," with window_size as an arbitrary constant. The actual design work is answering, for your specific graph: what's the cost of losing an old message outright, versus the cost of an extra LLM call on every prune? A support bot pruning small talk can afford a hard window. A planning agent pruning "why we rejected option 3" cannot, and needs the summary path even though it costs more per prune.

What this buys you before lesson 04

You can now choose a pruning strategy by asking what it costs to lose versus what it costs to compress, instead of picking whichever one a tutorial happened to show first. Lesson 04 builds on the multi-node pipeline shape this lesson's source material's fifth exercise gestured at, adding the piece neither that exercise nor this lesson has covered yet: routing a message down different paths based on what it actually contains.