From the evolution of synchronous Agent to asynchronous Agent, I systematically sorted out the relevant content!
The watershed between Async Agent and ordinary Agent is not "whether it can call tools", but whether it can leave the current dialogue window, continue to receive tasks, retain the state, run verification, return to review, and then return the results to the person.
Early Copilot was more like synchronous completion: people wrote the main line, and the model completed partial parts.
Later tool agents began to be able to check information, run commands, and adjust APIs, but most of them still stopped in one turn or one session.
The coding agent takes a step forward: enter the repo, modify files, run tests, and submit PRs.
For example, the cloud isolation environment officially described by OpenAI Codex is a typical form of this layer: [Introducing Codex] (Async Agent pushes one layer forward.
It deals with "how this task will be hosted in the next tens of minutes, hours or even days." It is a stability factor for long task Agent architecture.
Task Timeline: Spec -> Triage -> PR -> Review -> Merge This shows that Async Agent is oriented to the software life cycle, not a single code generation.
Tasks span stages, each with different context, permissions, and verification thresholds.
The harness Anthropic talks about in long-running agents is to solve this cross-stage advancement problem: [Effective harnesses for long-running agents]( Orchestrator / Scheduler Ordinary Agent can be pushed by the user sentence by sentence.
Async Agent requires a scheduling layer: When to start workers, when to pause, when to retry, and when to hand over results to humans.
This is where the control plane problem begins.
When multiple agents run for a long time, what is often broken is not reasoning, but registry, stream state, and conversation state.
For real engineering cases, you can see this Codex issue: [subagent tasks trigger reconnect loop and stream disconnect]( Context -> Plan -> Tool Use -> Code -> Test -> Review` This chain is the main workflow of Async Agent.
Synchronize Agent The context is usually maintained by the current window, and the Async Agent must turn the context into a manageable asset.
If the plan is changed, the tool state must be synchronized; if the code is changed, the test must be reproducible; after the review comment comes back, the agent must know its position in the original task.
Anthropic further splits this problem into the separation of brain, hands, and session, which is very suitable for understanding the underlying trends of Async Agent: [Scaling Managed Agents]( Knowledge / Playbooks / Checkpoint / Scoped Secrets / VM Sandbox This group is the biggest engineering difference between Async Agent and ordinary Agents.
Knowledge solves the local prior when entering the project.
Playbooks precipitates the team's recurring operations into execution strategies.
Checkpoint Make long tasks recoverable rather than relying on the model to "remember" them.
Scoped Secrets determine what resources the agent can access.
VM Sandbox gives it the ability to isolate, destroy, and reproduce.
The design of [Knowledge]( in Devin docs has a product context, but the mechanism is worth taking apart.
The longer the Observability / Trace Replay / Video Verification Async Agent, the more necessary it is to turn "what it has done" into replayable evidence.
Many failures are not that the last step is wrong, but that a certain state in the middle is written crookedly, and all subsequent steps continue to advance on the wrong track.
Here you can receive the direction of the event-sourced agent runtime: [The Log is the Agent]( The log is only a post-audit, debugging is still difficult; if the log becomes the state source of the runtime, replay, fork, diff, and lineage will have the opportunity to become native capabilities.
This is why Async Agent will become a trend.
After the model capability is improved, the marginal gap of single-step generation will be narrowed.
Where the gap really widens, we will turn to these more engineering aspects: - How long tasks maintain session continuity - How memory is written, revised, and forgotten, instead of being accumulated infinitely: [Is Agent Memory a Database?]( - How harness splits the target into verifiable trajectories: [Harnesses for Inference-Time Alignment over Execution Trajectories]( - How trace serves training, playback, and quality control: [Polar: Agentic RL on Any Harn ess at Scale]() - review How to change from manual cover to a first-class link in agent workflow - permission boundary How to prevent the agent from misunderstanding "can do" as "should do" So when I look at Async Agent now, I don't understand it as "Agent running in the background".
A more accurate statement is: Async Agent is the transitional form of Agent from chat interface to software production runtime.
Ordinary agents solve the problem of intelligence in an interaction.
Async Agent solves the status, verification, permissions, playback and delivery within an execution cycle.
After AI Coding truly enters the engineering scene, competition will become more and more like runtime engineering rather than prompt engineering.