Wink Pings

Agents Have Learned to Work in the Background; Humans Still Have to Watch the Failure Logs

LangChain hands long tasks to asynchronous subagents, and DeepSeek is also building a Super-agent. What gets moved away is human waiting time; the compute bill remains. Resuming from checkpoints, state persistence, and handoff are the next hurdle.

LangChain published 'Agents Are Going Async', and DeepSeek has just proposed Super-agent. Viewed together, the focus of discussion around agent architecture has changed: from how to complete a task within a single session to how a system can simultaneously handle multiple long-running tasks.

The old problem is very concrete. In a standard ReAct loop, a long tool call blocks the entire loop, and subsequent tasks queue up. The user has to watch the Session and wait for it to finish before scheduling the next task. The more capable the agent, the more glaring this wait becomes.

The solution LangChain offers in Deep Agents is async subagents. The main agent acts as the orchestrator and handles interaction with the user; time-consuming tasks are handed off to background subagents. Each task has its own Thread and returns immediately after being started, without blocking the main agent.

同步与异步子 Agent 对比:orchestrator 把任务交给异步子 Agent,自己继续和用户交互

Tasks are controlled with five tools: start_async_task starts a task and returns immediately, check_async_task checks status and results, update_async_task sends new instructions to a running task, cancel_async_task stops a task, and list_async_tasks lists all tasks and statuses.

A task can still be modified after it starts running. update_strategy has two values: interrupt is the default strategy, which stops the current run and restarts with new instructions, suitable for corrections like 'switch to Postgres'; enqueue queues new instructions and executes them after the current run finishes, suitable for additions like 'run the tests too when you're done.'

One engineering detail: background task state is saved separately to avoid losing task records after Context compaction. When a task completes, it can proactively notify the main agent. When the main agent is busy, it checks unfinished tasks before each model call and receives results while running; when idle, the subagent wakes it; when paused for approval, the approval stays pending, and the result arrives after the user responds. When a subagent needs approval, it shows as waiting; the user responds in the subagent's own Thread without interrupting the main agent.

异步子 Agent 通知机制:orchestrator 忙碌、空闲、等待审批时的处理

This design is close to DeepSeek's Super-agent approach. The difference lies in emphasis: LangChain focuses more on asynchronous scheduling and control during task execution, while DeepSeek further explores proactively discovering and advancing work through events from GitHub, Feishu, and other sources. Both point to a trend: agents are moving from the execution loop of a single Session to a work system that can continuously handle multiple tasks.

But asynchronous does not mean you can get a response at any time. Some online commenters pointed out the boundary: if the scheduling agent itself is busy, the user still has to wait. Part of the waiting cost has been shifted away from the human, but it has not disappeared entirely.

The tougher controversy is what happens after failure. Some commenters said the real difficulty of async is figuring out which checkpoint to resume from after a crash; when a long task exceeds a single context window, state persistence and idempotent replay are the hard parts; otherwise, you have just replaced watching the Session with watching the failure logs. Another commenter added the handoff problem: when the human returns, they need to understand at a glance what the agent has done during that time. Notifying that a run has finished is easy; continuing from where it last stopped is the real skill.

Cost is also easy to overlook. A commenter did the math: async saves human waiting time, not the compute bill. With background subagents running in parallel, one request may turn into N sessions burning tokens at the same time. If a long task fails midway and restarts from scratch, the entire round's cost is burned. In the future, evaluating an agent may require looking at how much it costs to redo a task after one failure.

Claude Code was also pulled into the discussion. A commenter said Claude Code has been doing similar logic for a long time: workflow and subagent carry very high weight in the system prompt, and when orchestrating it also judges the remaining context and time for a task, urging faster wrap-up when a task has been running for a long time. Xudong Han replied that they had not seen related reports and would look into it. Another commenter said a similar idea appeared earlier in Openclaw, and Codex voice mode also uses this architecture. Yet another commenter noted that DeepSeek's super agent and personal agent look similar on the surface but are not actually the same paradigm.

These claims need more verification, but the direction of the discussion is clear: whether an agent is useful will next depend not only on whether it can hand off tasks, but also on whether it can resume after failure, whether a human returning can understand what happened, and whether parallel token burn can be controlled.

LangChain original article: https://www.langchain.com/blog/agents-are-going-async

Tweet: https://x.com/Xudong07452910/status/2118871055360303354

发布时间: 2026-11-08 00:26