State, memory, persistence

Compile with a checkpointer and pass a thread_id at invoke time - that is the whole API surface:

• thread_id is a conversation's name. Same id = same accumulated state, so follow-up questions ("and the median of that column?") resolve. New id = clean slate. In an app, thread_id maps to a user session, a ticket, a pipeline run.
• The ladder is a deployment decision, not a code change:

Because the checkpoint is written AFTER each super-step, a crash mid-run only loses the step in flight. Invoke again with the same thread_id and LangGraph loads the latest checkpoint and continues - it does not replay finished work, does not re-bill you for completed model calls, does not lose the conversation. The industry name is durable execution; the mental model is a video game save file.

• What this quietly buys you: long-running agents that survive deploys, laptop-lid-close resilience in dev, and the ability to park a run for hours - which is exactly how b7's human approval gates will work (a pause is just a checkpoint nobody has resumed yet).
• The honest cost: every super-step writes state to storage. For chatty graphs with fat states that is real I/O - one reason state should carry references (a path, an id) rather than payloads (the whole CSV).

• The full state, every super-step. A checkpoint holds the complete state values (all channels, not a diff), plus metadata: which nodes ran, what is scheduled next, a unique checkpoint_id. That completeness is what makes b7's time travel possible - any checkpoint is a valid restart point.
• History is a list you can read. graph.get_state(config) returns the current snapshot; graph.get_state_history(config) yields every checkpoint of the thread, newest first. Print a few after tonight's demo - seeing your conversation as a stack of snapshots makes b7 obvious before it is taught.
• Checkpoints are per-thread. Two thread_ids never share checkpoint state. Cross-thread sharing is a different tool - the Store, in Part 2.

The Store is a namespaced key-value memory, passed at compile time alongside the checkpointer. Any node can read or write it, from any thread:

• Namespaces are tuples - ("users", "phoebe") - so one Store cleanly holds many users, teams, or projects. Design them like folder paths.
• The division of labor: a fact belongs in the Store when it should be true in the NEXT conversation too. "The amount column we discussed" = thread. "Phoebe prefers medians" = Store.
• Production swap: like checkpointers, InMemoryStore has database-backed siblings - same API, deployment-grade storage. The code you write tonight is the code you ship.

• Threads get fat. Checkpointing preserves every message, and models have context limits and per-token prices. The standard moves: trim (keep the last N messages), or summarize (compress old turns into a running summary message). You already met the productized version - b4's SummarizationMiddleware does exactly this at the create_agent altitude; at graph level you own the policy in a node.
• Two shapes of long-term memory. A profile is one document per subject, updated in place ("phoebe.prefs" - tonight's demo). A collection is many small records searched at recall time (every stats caveat DataDesk ever learned). Profiles are simpler and stay consistent; collections scale further but need retrieval discipline - which is b8's topic wearing a memory hat.
• Write policy matters more than storage. Decide WHEN memories get saved: explicitly ("remember this"), on a schedule (end of thread), or model-decided (a memory tool). Start explicit - model-decided writes are how bots end up "remembering" things users never said.