Async Agents Move the Failure Modes

Originally published at Trida AI. The most important design decision in the new async agent pattern is not the parallelism. It is who stays behind to answer the phone. LangChain's Agents Are Going Async describes the split its Deep Agents framework now ships: an orchestrator holds the conversation with the user while async subagents run the long work in the background. In the older shape, a subagent call blocked the orchestrator's loop until it returned, so one slow task froze everything, including the conversation. Now the hand-off returns at once, the loop stays free, and the amount of work an agent can carry grows with the number of workers instead of the length of one loop. We think the direction is right. We also think teams will misread what it fixes. Async removes a waiting problem. In exchange it creates a supervision problem, because work that used to fail in front of you now fails, waits, and finishes somewhere you are not looking. The failure modes did not leave. They moved. What the orchestrator actually does all day The mechanics are worth stating plainly, because the duties hide inside them. The orchestrator manages background work through five operations: start a task, check its status, send it new instructions, cancel it, and list everything in flight. Every unfinished task is listed in its system prompt, so it always carries a picture of what is outstanding. Steering splits into two choices with different costs. An interrupt (the default) stops the worker's current run and restarts it with the new instruction — right for a correction, wasteful for an addition, because the run in progress is stopped before it finishes. An enqueue holds the follow-up until the current run finishes, which preserves that work and delays the change. Neither is a detail. Picking between them, task by task, is a judgment the orchestrator now makes on your behalf. Results find their way back three ways. A busy orchestrator picks up finished results before its next model call. An idle one is woken by the worker reporting in. A paused one — waiting on an approval — is left alone, and the result waits with it. And when a background worker itself needs an approval, the request surfaces on that worker's own thread, where the user answers it without disturbing the main conversation. Read that list again as a job description. Track everything outstanding. Decide what an interruption should cost. Hold results until the moment they can be received. Route approvals to the right thread. That is not routing. That is supervision, and it is the part of the system that now decides whether the whole arrangement feels reliable or haunted. What each part is doing while the work runs. One vendor comparison, delegated once, still being steered the next morning — the conversation and the work now run on separate clocks. Where the failures go when nobody is watching A synchronous agent fails in the conversation. The user sees the error, asks a question, redirects. A background worker fails at 2 a.m. in a thread nobody has open. Unless the system gives that failure a destination (a record a person can inspect, with what the task was, how it failed, and what it touched before it stopped), the failure is just missing output. The user finds out when the result they were promised does not arrive, which is the worst notification design there is. Waiting rots in the same quiet way. An approval request sitting on a background thread has no natural owner: the user may not know it exists, and the orchestrator is paused around it. A task can wait for days while every dashboard shows the system as healthy, because waiting is not an error state. It needs an age, and at some age it needs to escalate to a person. Two more relocations are easier to miss. A worker that runs after the user has logged off runs on access granted inside a conversation that is over, so the grant's lifetime belongs to the task, not to the session. A credential that outlives the work is a standing invitation, whoever ends up holding it. And a result that lands the next morning arrives after the user's context has moved on. It has to carry its receipts with it: what it read, when it read it, and which claims stand on which sources. A bare answer, delivered late, asks to be trusted at exactly the moment checking it is hardest. The test is the task list Here is the evaluation we would apply to any async agent setup, our own included. Show the user a single list of everything running in their name: each task, when it started, what state it is in, what it is waiting on, and what happens if it fails. If that list exists and stays honest, the supervision duties above have somewhere to live. If it does not, and the only way to learn what is outstanding is to ask the orchestrator and take its word, then the background is a black box with good manners. The background task list, as the user sees it. Waiting and failed appear as states with ages and owners, not as gaps between messages. None of this makes async a bad trade. For genuinely long work (research that takes an hour, a migration that runs overnight) a blocking conversation is the worse design, and we would not go back. But there are places the split earns nothing. Short tasks pay the coordination cost and get nothing in return. Work the user needs to watch unfold, because the reasoning is the product, gets worse when it happens offstage. And tools that cannot report progress or accept a cancellation make poor background workers: they cannot be supervised, only launched. So build the orchestrator as a supervisor, not a dispatcher. Give its tasks a ledger, its failures a destination, its approvals an age, and its results receipts. The parallelism is the easy part, and it is mostly solved. What async actually moves into your product is the oldest management problem there is: work you cannot see, done by workers you have to trust, reported back after you have stopped watching. Design for that, and the pattern holds up. Design only for the parallelism, and you will meet the failure modes at their new address. Work with us If your agents are starting to run work in the background (research, migrations, overnight jobs) and nobody can say exactly what is outstanding, what it is waiting on, or where its failures land, we can help you build the supervision layer before the list gets long. Tell us about the deployment through Trida AI's intake.