LangGraph in Production: State Management Patterns We Learned the Hard Way

LangGraph made a bet that most agentic AI frameworks got wrong: state should be explicit, persistent, and inspectable. After building and running Agentica on LangGraph in production, we think this bet was correct. But production use has taught us a set of patterns that aren't obvious from the documentation and a set of failure modes that are genuinely hard to diagnose without understanding the internals.

The Checkpoint Bloat Problem

LangGraph stores every conversation turn as a checkpoint blob in Postgres. Each checkpoint contains a full snapshot of all state channels. In early production, we started seeing first-message latencies of 60-90 seconds on threads with more than 50 turns. The root cause took a while to find: LLM provider response metadata.

OpenAI and Google's API responses include large metadata objects — model version information, token counts, latency breakdowns, safety ratings — that LangGraph naively includes in the message object that gets serialized to the checkpoint. These metadata payloads were running 40-50KB per message. After 100 turns, that's 4-5MB of metadata in the checkpoint blob that gets deserialized on every request, even though none of it is used by the agent.

The fix is a sanitization pass on every message before it enters the state reducer. Strip response_metadata, additional_kwargs, and usage_metadata. Truncate content to a reasonable maximum length. This brings checkpoint blobs from 40-50KB per message down to 1-2KB — a 20-40x reduction that makes checkpoint loading O(1) even for long threads.

Reducer Design

LangGraph reducers determine how new state values are merged with existing state. The default reducer for most channel types is replacement: the new value overwrites the old value. For message channels, LangGraph provides an append reducer that adds new messages to the list.

The append reducer is correct for messages but creates a subtle problem over long sessions: the messages list grows without bound. Combined with the checkpoint bloat problem above (even after sanitization), this means long-running threads consume increasing memory and produce increasing checkpoint sizes. The solution is a windowing reducer that keeps only the last N messages, where N is chosen to balance context quality against checkpoint size. We use 40 messages as the default, which provides enough context for almost all real user interactions while bounding checkpoint size at roughly 80KB.

Sub-Graph Context Isolation

LangGraph supports nested graphs — a parent graph can invoke a child graph as a node. This is powerful for composing complex agent workflows, but it has a critical isolation property that's easy to miss: the child graph only sees its own state, not the parent graph's state. Fields like customer_id, user_role, or tenant_id that live in the parent state are invisible to nodes running inside the child graph.

The pattern we use to handle this is config injection: before invoking a child graph, the parent passes user-context fields into the RunnableConfig.configurable dict. Inside the child graph, nodes read user context from get_config().configurable rather than from state. This ensures that context flows correctly through any depth of nesting without requiring the child graph schema to explicitly include parent fields.

Violating this pattern produces bugs that look like authentication failures or permission errors — the agent reports it can't access data it should have access to — but are actually state isolation issues where user context is simply missing from the inner graph's state.

Streaming and Interrupts

LangGraph's interrupt mechanism — used to implement human-in-the-loop workflows — works by raising an exception that pauses graph execution and saves the current checkpoint. Execution resumes from the checkpoint when the interrupt is resolved. This is clean in theory but requires careful handling in streaming contexts.

When streaming agent output to a client via server-sent events, an interrupt mid-stream means the client needs to handle a partial response followed by a pause of indefinite length. In Agentica, we handle this by treating interrupts as a special event type in the stream: when an interrupt is raised, we emit an interrupt event to the client with the authorization request details, close the stream, and open a new stream when execution resumes. The client UI reflects this as a distinct state — the agent is waiting for human input — rather than appearing to hang.

Observability

The single most valuable addition to our LangGraph deployment was structured timing logs around the major phases: checkpoint load, graph execution, checkpoint save, and stream flush. These four numbers, logged on every request, immediately surface the root cause of most latency complaints. Slow checkpoint load points to blob size issues. Slow graph execution points to LLM latency or tool call performance. The logs have diagnosed at least a dozen production issues that would have been very difficult to debug from aggregate metrics alone.