Human-in-the-loop, for real

Ask vs decide

The first version of our adjustment chat interrogated the user endlessly, one question after another. Unbearable. The right posture is act-first: act by default with explicit assumptions, and ask only on a genuine blocker.

Pausing cleanly: interrupt

LangGraph provides interrupt(): called inside a node, it suspends the run and surfaces a question to your app. The graph doesn’t “block” a server thread — it stops and hands control back.

import { interrupt } from "@langchain/langgraph";
// dans un noeud : suspendre le run et demander a l'humain
function clarify(state) {
  if (state.deadline) return state;          // rien a demander -> on continue
  const answer = interrupt({                 // <- le graphe s'arrete ICI
    question: "Quelle est l'echeance visee ?",
    context: state.brief,
  });
  return { ...state, deadline: answer };     // reprise avec la reponse
}

Resuming the run

On the app side, the first call stops at the interrupt and returns the question. You show it, the user answers, and you re-run the same run with their answer via Command({ resume }).

import { Command } from "@langchain/langgraph";
// 1er appel : le graphe tourne jusqu'a l'interrupt, puis rend la main
const first = await graph.invoke({ brief }, config);
// -> first.__interrupt__ contient la question posee a l'utilisateur
// ... on affiche la question, l'utilisateur repond ...
// reprise : on relance le MEME run (meme thread_id) avec la reponse
await graph.invoke(new Command({ resume: "fin mars 2026" }), config);

Durable: surviving the pause

For the agent to resume exactly where it left off — even after a redeploy, or an answer two hours later — the state must be persisted. That’s the checkpointer’s job: it saves the graph state at each step, here in Postgres.

import { PostgresSaver } from "@langchain/langgraph-checkpoint-postgres";
// l'etat du run est persiste -> il survit a un reboot, une repons 2h plus tard
const checkpointer = PostgresSaver.fromConnString(process.env.DATABASE_URL);
const graph = builder.compile({ checkpointer });
// chaque run a un thread_id : c'est lui qui permet de reprendre au bon endroit
const config = { configurable: { thread_id: runId } };

Approval gates: acting under condition

Act-first has one clean exception: irreversible actions. Deleting data, emailing a customer, confirming a payment, pushing to prod — there, the agent doesn't guess, it asks for approval. Anthropic puts it well in Building effective agents: you place checkpoints before high-stakes actions, not at every step. It's the same interrupt() as for a clarification, but what you surface is no longer an open question — it's a plan to approve.

Three possible answers, not two

A good approval gate isn't just "yes / no." You also want to let the human edit the action before it fires. The interrupt payload surfaces the proposed action, and the answer via Command({ resume }) carries the decision — which the node then executes.

import { interrupt, Command } from "@langchain/langgraph";
// Inside a node, before a destructive tool call
async function sendEmailNode(state: State) {
  const draft = state.pendingEmail;
  // Surface the proposed action, not an open question
  const decision = interrupt({
    kind: "approval",
    action: "send_email",
    to: draft.to,
    subject: draft.subject,
    body: draft.body,
  }) as { type: "accept" | "edit" | "reject"; args?: EmailArgs; reason?: string };
  if (decision.type === "reject") {
    // Loop back with the reason, no side effect fired
    return new Command({
      goto: "plan",
      update: { note: `Email rejected: ${decision.reason}` },
    });
  }
  const finalDraft = decision.type === "edit" ? decision.args! : draft;
  await mailer.send(finalDraft); // the only irreversible line, gated
  return { sent: true };
}

Timeout and escalation

An approval gate with no time limit becomes a zombie run: suspended forever because nobody answered. Since state is persisted by the checkpointer (thread_id + Postgres), the run costs nothing while it waits — but you still need a policy. In practice I store a deadline alongside the checkpoint and run a job that, past the delay, resumes the thread with a default decision (usually reject) or escalates to another approver.

Checkpoint isn't durable execution

A checkpointer gives you resumption: state is written at each step, you can re-run a thread by its thread_id, even after a crash — well documented on the Persistence side and the durable execution side. But resuming isn't automatically running to completion. The checkpoint saves your place; it's still on you to detect the failure and re-run with the right identifier.

Sources & further reading