LangChain AI Updates: November 6, 2026

1. LangChain Explains How Deep Agents’ Async Subagents Report Back, and Deep Agents 0.7.33 Gives Their Notifications Standard Metadata

LangChain published “Agents Are Going Async” on November 5, a closer look at the async subagents it added to Deep Agents and Managed Deep Agents at the end of October. An orchestrator stays available to the user while subagents run as background workers on their own threads, managed through five tools: start_async_task, check_async_task, update_async_task, cancel_async_task and list_async_tasks. A subagent definition’s update_strategy decides what a follow-up does: "interrupt" (the default) stops the current run and restarts the subagent with the new instruction, while "enqueue" holds it until the current run finishes. Every unfinished task is listed in the orchestrator’s system prompt. When a task finishes, a busy orchestrator picks up the result before its next model call, an idle one is woken with a new run, and one paused on an approval gets the result only after the user answers. A subagent that needs approval shows as waiting and is answered on its own thread without interrupting the orchestrator; in Managed Deep Agents on Slack, the request posts back to the original thread. Task notifications are in beta, and an async-deep-agents repository has a supervisor with researcher and coder subagents in Python and TypeScript. The post cites Claude Code’s background subagents, OpenAI’s dots and DeepSeek Harness as examples of the same split between one agent that talks to the user and background workers. Separately, deepagents 0.7.33 (November 5) tags async subagent notifications with standard metadata (lc_source="async_subagent" with the task event, read through langchain-core’s get_notification_metadata), deprecates the old additional_kwargs["deepagents_notification"] key and drops the [SYSTEM NOTIFICATION - NOT USER INPUT] line from the message. Source

2. Deep Agents 0.7.33 Raises on Model Refusals by Default and Returns Subagent Refusals to the Parent as Task Results

LangChain released deepagents 0.7.33 on November 5, applying the refusal content blocks and ModelRefusalError that langchain-core 1.7.5 introduced the day before. Providers return refusals as successful responses, so a refusing model used to end the run as a completed task and a refusing subagent handed its parent an empty result. ModelRefusalMiddleware is now in the default middleware stack of the main agent, declarative subagents and the general-purpose subagent, and it sits after user middleware, so a configured ModelFallbackMiddleware retries the refused request on the next model before anything raises; model-level with_fallbacks does not see refusals, because they are detected after the model call. The task tool reports a subagent refusal to the parent as a task result, with the refusal category and a note that retrying the same request is unlikely to succeed, instead of failing the parent run. That covers a refusal content block in the subagent’s last message, a raised ModelRefusalError and a structured-output refusal that fails parsing, and async subagent results carry the same notice, though a subagent that raises does not return its file and todo updates. Teams that want the old behavior can exclude the middleware through a harness profile’s excluded_middleware. The release also moves the rubric middleware out of beta, restricts the Python grep fallback to the requested file while clipping long result lines around the match, and reports failed compaction with an error status. Later the same day, deepagents 0.7.34 anchored the summarization cutoff to a message ID, and deepagents-code 0.2.5 sized its compaction input budget to the selected model. Source PR

3. LangGraph.js 1.7 Ports Strict Resume, and Its Dev Server Makes It an Opt-In strict_resume Run Option

LangChain released @langchain/langgraph 1.7.0 late on November 4 (US time), the JavaScript counterpart of the strict resume mode LangGraph 1.2.20 added in Python. With the private configurable key __pregel_strict_resume set, the root graph throws UnknownInterruptError before writing anything when a Command({ resume }) names an interrupt that is not pending, is an empty map, or is one value while several interrupts are pending, and each interrupt() call in a task now gets its own id. The JS release also fixes two older behaviors: a task that raises several interrupts at once, such as a subgraph with parallel interrupts, now keeps all of them instead of only the last, and falsy resume values such as Command({ resume: false }) reach interrupt() instead of throwing EmptyInputError. On the server side, @langchain/langgraph-api 1.6.0 turned strict resume on for every run on the JS dev server, so a double-clicked answer or a single value sent to several pending interrupts failed. Version 1.7.0, released November 6, makes it opt-in through a strict_resume: true field on run creation and on the protocol’s run.start and input.respond, and tells a thread’s other protocol clients which interrupts a run answered with a new input.answered event. @langchain/langgraph-sdk 1.14.0 adds a matching strictResume option to client.runs.create(), stream(), wait() and useStream’s submit(), hides interrupts another client already answered, and adds a lifecycle stream mode with an event when each subgraph starts and ends. The previous SDK release, 1.13.0, added streamNamespaces to stream only chosen namespaces of a run and stopped retrying POST and PATCH requests that may already have reached the server, so a retry can no longer create a second run. In Python, langgraph-sdk 0.4.14 adds strict_resume to runs.create, stream and wait, and langgraph-cli 0.4.42 adds a deploy metrics command. Source Dev server SDK Python SDK