Agents Are Going Async

Imagine a chief of staff who disappears every time you hand them a big project and only comes back once it's done. You'd probably fire them immediately. A good chief of staff keeps projects moving in the background while staying reachable and keeping you updated along the way. As we ask agents to work toward bigger goals, they need the same two properties. An agent has to be responsive, acting on a new instruction right away with the context of everything before it, and productive, making progress on many large tasks at once.

The architecture we've used to build agents for a while can't meet both requirements. In a standard ReAct loop, each long tool call blocks the loop and every other task queues behind it. Instead, we're seeing the ecosystem converge on a split between one agent that stays with the user and background workers that do the long work. Claude Code runs subagents in the background by default, OpenAI's dots hand work to background workers to make progress on several things at once, and DeepSeek Harness built its super agent around a router that talks to people and background workers that run tasks in parallel.

We’re bringing this pattern to Deep Agents with async subagents. An orchestrator stays available to the user and keeps the conversation's context organized, while async subagents run as background workers and report back when they finish. The amount of work the agent can take on then grows with the number of background workers instead of the length of one loop.

How async subagents work

An agent runs in a loop. The model calls a tool, waits for the result, and decides what to do next. Historically, tools and subagents blocked that loop until they returned, like code that awaits each slow call in turn. An async subagent works like a task started with asyncio.create_task or a Promise you don't await yet. The call returns right away, the work runs independently in the background, and the result comes back later.

Async work depends on two properties of the system:

• The user can reach the orchestrator. The orchestrator is the agent the user interacts directly with. Subagents no longer hold its loop, so the user can reach it whenever its own loop isn't busy, instead of waiting for every subagent to finish.
• Tasks run in parallel without blocking. The orchestrator starts subagents as work comes in, instead of waiting for a whole batch to return.

The orchestrator manages async subagents with five tools:

• start_async_task starts a subagent on its own thread and returns right away.
• check_async_task gets a task's status and, once it finishes, 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.

Steering a running subagent is separate from reaching the orchestrator. When the orchestrator sends 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. Use it for a correction like "use Postgres instead."
• "enqueue" holds the follow-up until the current run finishes. Use it for an addition like "run the tests when you're done."

How notifications work

Every unfinished task is listed in the orchestrator's system prompt, so it always knows what's in flight. It can poll with check_async_task or tasks can report back on their own:

• If the orchestrator is busy, it checks its unfinished tasks before each model call and picks up the result mid-run.
• If it's idle, the subagent wakes it with a new run.
• If it's paused on an approval, the approval is left alone, and the result arrives once the user answers.

A subagent that 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.

We expect this pattern to generalize beyond subagents to tools across the board. OpenAI recently added support for async tool calling, where the model keeps working after it calls a tool and your application sends the result back in a later request.

Use async subagents

Async subagents are available in Deep Agents for Python and JavaScript, and in Managed Deep Agents, where making a subagent async takes one field:

from managed_deepagents import define_deep_agent

agent = define_deep_agent(
    name="research-assistant",
    model="openai:gpt-5.5",
    subagents=[
        {
            "name": "researcher",
            "description": "Researches a topic in the background.",
            "system_prompt": "Research the topic and report your findings.",
            "async": True,
        },
    ],
)

In Managed Deep Agents, every served agent also gets an async copy of the general-purpose subagent, so it can decide at runtime whether to run delegated work in the foreground or the background.

Task notifications are in beta, so the API may still change. The async-deep-agents repo has a working supervisor with researcher and coder subagents in Python and TypeScript.

Give async subagents a try, and let us know what you think in GitHub issues or on the forum.