Building Production-Ready AI Agents with LangGraph

A linear prompt chain works fine until an agent needs to branch, retry a failed step, loop back for clarification, or pause and wait for a person. At that point, forcing the logic through a chain means bolting conditional hacks onto something that was never designed to hold state across a non-linear path.

LangGraph's core idea is to model the agent explicitly as a directed graph: nodes are units of work, edges define what can follow what, and a typed state object is threaded through and updated at every node. That structure is what makes branching, retries, and human review checkpoints first-class citizens instead of workarounds.

Every LangGraph deployment persists its state through a checkpointer, and the choice of backend is the single most consequential production decision in the whole build. In-memory checkpointing is fine for local development, but it means agent state — including anything mid-approval or mid-conversation — disappears the moment the process restarts.

from langgraph.checkpoint.postgres import PostgresSaver

with PostgresSaver.from_conn_string(DATABASE_URL) as checkpointer:
    checkpointer.setup()
    graph = builder.compile(checkpointer=checkpointer)

For production, that means a persistent backend — PostgresSaver is the common choice for teams already running Postgres — with connection pooling configured for the concurrency you actually expect, and a deliberate retention policy for checkpoint data rather than storing it indefinitely by default.

The pattern that makes async approval workflows possible is the interrupt: a node can pause graph execution mid-run, surface a payload for a human to review, and resume later from that exact point once a decision comes back — without replaying the conversation or losing context.

def send_external_email(state):
    decision = interrupt({
        "action": "send_email",
        "to": state["recipient"],
        "draft": state["draft_body"],
    })
    if decision["approved"]:
        return {"status": "sent"}
    return {"status": "rejected", "reason": decision.get("reason")}

This matters because a real approval can take minutes or days — a reviewer might be offline, or the action might need sign-off from someone in a different timezone. Treating the interrupt as a first-class paused state, not an exception to catch and retry, is what makes that wait safe.

Two things become necessary the moment an agent handles real traffic instead of a demo script: streaming intermediate output to whatever's consuming it (a UI, a voice pipeline, a chat interface), so users aren't staring at a spinner for a multi-step task; and tracing every node transition and tool call, so when an agent does something unexpected, the team can see exactly why — not just that it happened.

• Log every node entry/exit, the state diff at each step, and every tool call with its arguments and result.
• Stream partial output where the latency of a full multi-step run would otherwise feel broken to the end user.
• Capture interrupt events distinctly from errors — a paused-for-review state is expected behavior, not a failure, and conflating the two in logs makes debugging much harder.

Skipping any one of these tends to work fine right up until it doesn't — usually the first time a process restarts mid-approval, or the first time someone asks why the agent did what it did.

• No idempotency on tool calls — a retry after a timeout re-executes a side-effecting action (like sending an email) a second time.
• Never testing checkpoint recovery — the first real test of "does this resume correctly" happens during an actual production incident instead of in staging.
• Treating interrupts as exceptional rather than expected, which makes monitoring noisy and hides real errors in a sea of paused-for-review alerts.
• No retention policy on checkpoint data, which quietly accumulates PII and becomes a compliance problem long before anyone notices the storage cost.