Threads: Giving Each Conversation Its Own State

Recall thread_id from Module 16’s config — used without much explanation beyond “this is the key.” This module gives it the real, proper treatment it deserves, because it’s genuinely the mechanism keeping one real customer’s conversation from ever bleeding into another’s.

What a thread actually is

A thread is a single, continuous, isolated stream of state, identified by a thread_id. Every checkpoint from Module 16 is saved against a specific thread. Two different thread_ids mean two completely separate, genuinely isolated histories, even when running through the exact same compiled graph.

Example 1: proving isolation directly

from langgraph.graph import StateGraph, START, END, MessagesState
from langgraph.checkpoint.memory import InMemorySaver
from langchain.chat_models import init_chat_model

model = init_chat_model("openai:gpt-4o-mini")

def call_model(state: MessagesState) -> dict:
    return {"messages": [model.invoke(state["messages"])]}

builder = StateGraph(MessagesState)
builder.add_node("call_model", call_model)
builder.add_edge(START, "call_model")
builder.add_edge("call_model", END)

graph = builder.compile(checkpointer=InMemorySaver())

config_customer_a = {"configurable": {"thread_id": "customer-a"}}
config_customer_b = {"configurable": {"thread_id": "customer-b"}}

graph.invoke({"messages": [{"role": "user", "content": "My name is Amara."}]}, config=config_customer_a)
graph.invoke({"messages": [{"role": "user", "content": "My name is Diego."}]}, config=config_customer_b)

result_a = graph.invoke({"messages": [{"role": "user", "content": "What's my name?"}]}, config=config_customer_a)
result_b = graph.invoke({"messages": [{"role": "user", "content": "What's my name?"}]}, config=config_customer_b)

print("Customer A:", result_a["messages"][-1].content)
print("Customer B:", result_b["messages"][-1].content)

Run this, and each customer’s real, separate conversation stays genuinely isolated — “Amara” is never visible to customer B’s thread, and vice versa. This is the exact real property a genuine multi-user application needs, and it comes entirely from using two different thread_id values against the same, single compiled graph.

Example 2: the same thread, called repeatedly, genuinely continuing

config = {"configurable": {"thread_id": "support-session-42"}}

graph.invoke({"messages": [{"role": "user", "content": "I need help with my order."}]}, config=config)
graph.invoke({"messages": [{"role": "user", "content": "It's order o_42."}]}, config=config)
result = graph.invoke({"messages": [{"role": "user", "content": "What order number did I give you?"}]}, config=config)

print(result["messages"][-1].content)

Three completely separate .invoke() calls, same thread_id — and the third call correctly recalls “o_42” from the second. Recall Module 16’s own core lesson: each call is really reading the checkpointer’s saved state for "support-session-42", appending to it, and saving the updated result back, exactly like Module 12’s growing conversation, just now genuinely persisted between real, separate calls instead of chained manually within one Python session.

Example 3: inspecting a thread’s full history

history = list(graph.get_state_history(config))
print(f"This thread has {len(history)} saved checkpoints.")
for snapshot in history[:3]:
    print(len(snapshot.values.get("messages", [])), "messages at this checkpoint")

get_state_history gives you every real, individual checkpoint ever saved for this specific thread — not just the current state, but the genuine, complete timeline. This becomes directly useful once this course covers real observability and debugging, letting you see exactly how a specific thread’s state evolved, step by step, over its entire real history.

The genuinely serious mistake this mechanism makes possible

flowchart TD
    A["Real, distinct thread_ids\nper user or session"] --> B["Genuine isolation:\nconversations never mix"]
    C["Accidentally shared\nor hardcoded thread_id"] --> D["Real, serious privacy failure:\none user's data appears\nin another user's conversation"]

This is worth being direct about, because it’s not a theoretical concern. If a real application ever hardcodes a single thread_id, or derives one incorrectly — say, from a session identifier that isn’t actually unique per user — every user sharing that same thread_id genuinely shares the exact same conversation state. One user’s private information, order details, or account data becomes directly visible inside a completely different user’s session. This is the exact same category of real, serious failure as any other data-isolation bug in a genuine, multi-tenant system — worth treating with the same seriousness.

Common mistakes worth avoiding

Hardcoding a single, fixed thread_id “just for testing” and never changing it. Recall this module’s own core warning — this is precisely how two real, different users end up sharing one conversation’s state. Generate a genuinely unique thread_id per real user or session from the very start, even in early development.

Assuming a new thread_id automatically means a fresh, empty state. It does, but only because no checkpoint yet exists for it — the moment any conversation happens against that thread_id, its state persists exactly like any other, for as long as the checkpointer retains it.

Forgetting that InMemorySaver’s thread isolation still disappears on restart. Recall Module 16’s warning — the isolation itself is genuinely real and correct; it’s the persistence across a process restart that InMemorySaver specifically doesn’t provide.

What you should take away from this module

• A thread is a genuinely isolated, continuous stream of state, identified by its thread_id — the real unit Module 16’s checkpointer actually saves against.
• Two different thread_ids, run through the identical compiled graph, produce completely separate, non-interfering conversation histories.
• The same thread_id, called repeatedly across genuinely separate .invoke() calls, produces a real, continuing conversation — exactly like Module 12’s manual version, now properly persisted.
• Mishandling thread_id — hardcoding it, or deriving it incorrectly — is a genuine, serious privacy failure, not a minor bug.

Where this goes next

The next module completes the memory picture properly: checkpoint, thread, and the long-term Store — a precise, honest comparison of six terms that are easy to blur together, plus the real mechanism for memory that survives even across separate threads.