async subagents: LangChain Brings Background Workers to Deep Agents

async subagents are LangChain's answer to a problem every team running agents in chat has hit: the moment your agent starts a long task, it stops talking to you. Announced on November 5, 2026, the pattern splits a Deep Agents agent into an orchestrator that stays available to the user and subagents that run tasks in the background and report back when they finish. It is available now in Deep Agents for Python and JavaScript, and in Managed Deep Agents, where making a subagent async takes one field. Source

This post covers what shipped, how the control surface works, what LangChain scoped carefully, and what the pattern means for teams designing agent systems. The facts come from LangChain's announcement and documentation, with Snape Report's coverage as an independent read.

The problem: an agent that disappears while it works

LangChain opens with an analogy: a chief of staff who vanishes every time you hand them a project and only returns when it is done would not last long. A good one keeps projects moving in the background while staying reachable. Agents need the same two properties, which LangChain names as responsive (acting on a new instruction right away, with full context) and productive (making progress on many large tasks at once). Source

The cost of that disappearance is easy to underestimate. On Slack-style and chat surfaces, a blocked agent freezes the conversation itself: the user watches a typing indicator while a research task runs, and any new instruction queues invisibly behind work they can no longer see or redirect. Snape Report's coverage calls out exactly this surface problem as the reason the pattern matters. Source

The standard agent loop cannot deliver both. In a ReAct-style loop, each long tool call blocks the loop, and every other task queues behind it. LangChain argues the ecosystem is converging on a fix: one agent stays with the user while background workers do the long work. It points to Claude Code running subagents in the background by default, OpenAI's dots handing work to background workers, and DeepSeek Harness building its super agent around a router that talks to people while workers run tasks in parallel. Source

What shipped

An async subagent works like a task started with asyncio.create_task, or a Promise you do not await yet: the call returns immediately, the work runs independently in the background, and the result arrives later. The orchestrator's loop stays free, so the user can reach it whenever its own loop is not busy, and the amount of work the system can take on grows with the number of background workers instead of the length of one loop. Source

In Managed Deep Agents, opting in is a single field on the subagent definition: "async": True. Every served agent also gets an async copy of the general-purpose subagent, so it can decide at runtime whether delegated work runs in the foreground or the background. The async-deep-agents repository ships a working supervisor with researcher and coder subagents in both Python and TypeScript. Source

The five tools that form the control surface

The orchestrator manages background work through five tools. start_async_task launches a subagent on its own thread and returns right away. check_async_task gets a task's status and, once finished, its result. update_async_task sends a running task new instructions. cancel_async_task stops a running task. list_async_tasks lists every task and its status. Source

Steering a running subagent is deliberately separate from reaching the orchestrator. When the orchestrator forwards a follow-up with update_async_task, the update_strategy field on that subagent's definition decides what happens. "interrupt", the default, stops the current run and restarts the subagent with the new instruction; LangChain's example is a correction like "use Postgres instead". "enqueue" holds the follow-up until the current run finishes; the example is an addition like "run the tests when you're done". Source

How results find their way back

Every unfinished task is listed in the orchestrator's system prompt, so it always knows what is in flight. From there, reporting adapts to the orchestrator's state. If the orchestrator is busy, it checks unfinished tasks before each model call and picks up results mid-run. If it is idle, the finished subagent wakes it with a new run. If it is paused waiting on an approval, the approval is left alone and the result arrives once the user answers. A subagent that itself needs approval shows up as waiting, and the user answers on the subagent's own thread without interrupting the orchestrator; in Managed Deep Agents on Slack, the request posts back to the original thread. Source

LangChain also notes it expects the pattern to generalize beyond subagents to tools across the board, and points out that OpenAI recently added support for async tool calling, where the model keeps working after calling a tool and the application sends the result back in a later request. Source

What LangChain did not claim

Two scoping notes matter. First, the notification machinery is explicitly in beta, so the API may still change; teams building on it should pin versions and watch the changelog. Second, the November 5 post is the pattern announcement rather than the first code drop: Snape Report notes that Managed Deep Agents v0.10 had already shipped the async flag on October 29, alongside browser use. If you are evaluating maturity, the feature is a week old in production terms, however clean the design reads. Source

There is one more boundary worth noting: async execution changes failure handling, not just responsiveness. A background subagent that fails does not interrupt the orchestrator's conversation, which is the point, but it also means failures surface only through the notification path. Teams adopting the pattern should decide up front how a failed task reaches a human, because the default is a status change in a task list, not an alarm.

It is also worth keeping the claims in proportion. LangChain's convergence argument cites Claude Code, dots, and DeepSeek Harness as evidence of an industry direction, and that is a reasonable read, but the five-tool control surface is LangChain's own design, not a standard. Snape Report frames the open question the same way: whether competing agent frameworks standardize the same control surface is something to watch, not a settled fact. Source

What this means for agent operators, in our assessment

This section is our read, separate from the sources. Async subagents add to a pattern that keeps showing up across vendors: a persistent, user-facing coordinator and disposable workers that do the long tasks. That is the same shape we described in our managed deep agents coverage, the same shape AWS productized in kiro bots this week, and the shape LangChain has now made available as an opt-in flag in Deep Agents. We read the repeated arrival of this split as a signal worth designing for, not proof that the industry has settled on it. If you are still designing agent features as one long blocking loop, this release is a good reason to re-examine that choice.

The detail we would underline for operators is update_strategy. Giving a running background task new instructions is where background agent systems get dangerous: the difference between "interrupt" and "enqueue" is the difference between a correction and an accidental mid-flight rewrite. Our advice is to default every async subagent to "enqueue" and reserve "interrupt" for tasks you can safely restart from scratch. Pair that with the harness-level guardrails we covered in our Harness2 post, and keep approval gates on any subagent that can write to shared systems, exactly as LangChain's own waiting-state design assumes you will.