LangChain 1.4 alpha: an agent that can ask a question and wait for the answer without falling over

Most agent demos never ask you anything. They take a prompt, call tools, and either finish or fail. Real work is messier: the tool discovers it needs a date range, a confirmation, a choice between two customers with the same surname. An agent that cannot stop and ask will guess, and a guess with write access is how you end up explaining yourself to a finance team.

The LangChain 1.4 alpha (the branch I looked at is 1.4.0a4) is aimed at exactly that gap. It builds on the MCP work I described in MCP is first-party in LangChain now and adds four things: MCP elicitation routed through LangGraph interrupts, stricter error handling, PII redaction, and a wider model and provider choice in init_chat_model. One caveat before anything else. This is an alpha. I have not run it, the API can still move, and I could not pin down the exact release date of the alpha itself (the package metadata suggests roughly two weeks ago, which is not a date I would put in a changelog).

What elicitation actually is

MCP elicitation is a mechanism that lets a server ask the user for input in the middle of a tool call. The server says, in effect, I need one more piece of information before I continue. The client is supposed to surface that to a human and send the answer back.

The awkward part is what the client does in the meantime. In a chat window it is easy, you render a form. In a long-running agent run, possibly triggered by a webhook at 3 a.m., there may be no human attached at all. You need the run to stop, persist its state, and resume hours later when somebody looks at the queue. That is a different problem from showing a dialog.

Why interrupts are the right primitive

LangGraph already has that machinery. An interrupt pauses the graph at a node, checkpoints the state, and hands a payload to whoever is listening. Resuming means feeding a value back in, and the graph continues from the same point. Here is the bare pattern in plain LangGraph, which is what the elicitation feature leans on:

from langgraph.types import interrupt, Command

def confirm_node(state):
    answer = interrupt({"question": "Refund 240 EUR to customer 1187?"})
    return {"approved": answer == "yes"}

# later, from a worker or an API handler:
graph.invoke(Command(resume="yes"), config=thread_config)

That needs a checkpointer, because the pause has to survive a process restart. What I like about mapping elicitation onto this is that the server's question becomes an ordinary graph event. You can route it to Slack, a ticket queue or a UI, you can time it out, and you can audit it. A request that hangs on an open socket offers none of that.

I am describing the LangGraph primitive here, not the exact 1.4 wiring. The alpha notes say elicitation is carried by interrupts, and I would check the actual signatures before copying anything.

PII redaction and the error handling nobody screenshots

The other two additions are less exciting and probably matter more. PII redaction sits in the path of tool calls, so that an email address or an account number in a prompt or a tool result does not get shipped to a model provider or written to a trace in clear text. Whether the redaction is good enough for your compliance officer is a separate question, and regex-style masking has a long history of missing the thing you cared about. I would treat it as a sensible default, not a control I could point an auditor at.

Stricter error handling is the same story. Tool failures that used to be swallowed or turned into vague model-visible strings are supposed to be handled more explicitly. Anyone who has watched an agent cheerfully retry a failing call nine times knows why that is overdue.

The init_chat_model change is housekeeping, a broader set of models and providers you can name with one string. Handy, but it does not change the design.

An agent you can trust with real permissions is one that knows when to stop, and stopping safely is a storage problem before it is an intelligence problem.

What I would do with it now

Nothing in production. The interesting move this week is to build one small graph with a single interrupt in front of a write action, run it with a real checkpointer, and kill the process between the question and the answer. If the run resumes cleanly, you understand the model that elicitation will plug into, and you will know how the 1.4 release fits when it stabilises.

And the harder question is not technical. Who is on the other end of that interrupt at 3 a.m., and what happens to the run if nobody ever answers?