Claude Code & Codex Mobile & Web Client

Back to Blog

Feb 9, 2026 By Kartik Sarangmath

What Is an Async Agent, Really?

Spoiler: you may or may not find out

Look up the term “async agents” online. You’ll find dozens of posts using the phrase, and the ones that bother to define the term all seem to be talking about different things. It shows up in product announcements, HN threads, and architecture blog posts, always casually, as if the meaning were obvious. So I wanted to figure out which definition was actually correct.

The most common definition I saw was that an async agent is simply an agent that runs for a while. A long-running task feels async. If it keeps working while you go to the bathroom or refill your water bottle, that feels asynchronous. And it’s true that a task running long enough gives you the opportunity to go do something else. But then how long does the task need to run before it counts? What about an agent that finishes in a second versus one that takes an hour? Is the fast one synchronous and the slow one async? Can I create an async agent by adding a sleep statement before running the agent? That doesn’t feel like a satisfying definition.

Another definition I kept running into was that async agents are the ones running in the cloud. Devin runs remotely, so it’s async. Claude Code runs locally, so it’s not. But if I spin up an EC2 instance, SSH in, install Claude Code, and run it there, did I just convert it into an async agent? The tool didn’t change. Only the machine running it did. That can’t be it.

The third definition was that async agents are event-driven. The ones that get triggered without you. A PR lands and an agent spins up. A cron job fires and the agent messages you on Slack. That feels asynchronous because you aren’t the one typing the command at that moment. But a cron job can kick off any program. The trigger is asynchronous, but that doesn’t make the program it runs async. That’s scheduling, not a property of the agent itself.

None of these are wrong exactly, but none of them feel like definitions either. They’re all describing properties that happen to correlate with the thing people are trying to point at. So let’s go back to basics.

What’s an Agent? What’s Async?

As Simon Willison put it, an agent is just an LLM that runs tools in a loop. I’d go a step further and say an agent also needs continuity of context. If I start up two different sessions of Claude Code, those are two different agents. If I type /clear in an instance of Claude Code, I’ve killed one agent and spawned a new one. The context is what makes it that agent.

Now, asynchrony.¹ The technical definition says it’s when events happen independently of the main program flow. The key insight is that an async function isn’t magically async by itself. It’s async relative to its caller. If the caller doesn’t wait, the function runs independently. If the caller waits, it’s effectively synchronous. The async part isn’t the function. It’s the caller’s decision to not block on it.

Think about what coding looked like before agents. You typed; work happened. You stopped typing; work stopped. You could only progress one task at a time, all of it synchronous.

When coding agents arrived, they unlocked something new. They made asynchronous work possible. You could delegate work and not wait for it to finish. You could give an agent a task, go make lunch, and come back to a finished PR. For the first time, your work could keep progressing while you did something else.

But that didn’t make the agent inherently async. You could turn around and ask the same agent a quick question and wait for the answer. In that moment, you used it synchronously. The agent didn’t change. Your behavior did.

So what is this “async agent” that everyone keeps referring to? It’s in the eye of the beholder. The real async agents were the friends we made along the way.

But seriously, no agent is inherently async. It just depends on whether you wait for it to finish or not.

Using Agents Asynchronously

If you do choose to use agents asynchronously, you unlock something powerful: concurrency. You can delegate multiple tasks to multiple agents and let them all make progress at the same time. But once you do that, you hit a practical problem: they’re all working on the same codebase on your machine. That’s not how real engineering teams work. Every engineer has their own computer, their own copy of the code, their own branch.

Why not just have everyone edit the same codebase in real time, like Google Docs? Seems like it would eliminate an entire class of problems: broken merges, conflicting edits, diverging branches… basically all the stuff Git makes you deal with. Collaborative coding has been tried, and it hasn’t caught on for good reason (this is what Replit did early on). The problem is that without isolation, one person’s work-in-progress can break another person’s working code. You need each task to live in its own environment where it can be built, tested, and validated independently.

Agents run into the same problem. They need their own copy of the codebase to make progress without stepping on each other. That’s why tools like Conductor and Omnara rely on git worktrees, why people like Boris (creator of Claude Code) literally clone whole directories, and why apps like Codex Web or Sculptor use isolated VMs or local containers. Each agent gets its own workspace so one agent’s progress doesn’t break another’s.

With isolated workspaces, you’re the manager. You’re the one spawning agents, watching agents, coordinating agents. Delegating work to agents is a huge force multiplier. It dramatically increases output, but it also increases the amount of context you have to manage and switch between. There is a ceiling.

Which begs the question: can an agent manage the agents?

So What Should “Async Agent” Actually Mean?

Honestly, we probably shouldn’t use the term at all. But if you’re going to anyway, it should mean something that isn’t already true of every agent. And there’s a natural parallel from programming that gives us exactly the right distinction.

In software, there’s a difference between an async function and the runtime that manages it. An async function can run without blocking its caller. The async runtime is the thing that manages the event loop: it spawns functions, schedules them, and coordinates their results. The function is just along for the ride. The runtime is doing the orchestration.

Agents map onto this perfectly. Every agent today is an async function. You call it, it runs, you go do something else. But an async agent, in the meaningful sense, is the runtime. It’s an agent that manages its own event loop of other agents.

You give it a task; it spins up a subagent in a background workspace and keeps interacting with you. You ask it to build a login page. “Got it.” It delegates that to another agent running in the background. You ask it for a billing page. “Sure, and by the way, the login agent wants to know if you prefer GitHub or Google OAuth.” You’re not switching tabs or managing ten sessions. The agent is managing the team. You’re talking to one entity, and that entity orchestrates all the others.

You stopped being the developer. You stopped being the manager. You’re just the person with the intent, and the agent figures out the rest.

Early attempts at this model exist. Claude’s Agent Teams and Gastown are early examples. And Cognition’s “Don’t Build Multi-Agents” post explains why it’s hard today: context sharing, token costs, unreliable inter-agent reasoning. But these are engineering constraints, not architectural ones. As models get cheaper, context windows expand, and agent-to-agent communication improves, this architecture will stop being experimental and start becoming the default.

In programming, we distinguish an async runtime from a regular program because it manages concurrent execution. It spawns functions, schedules them, coordinates their results, and handles the plumbing that makes this possible: event loops, callbacks, shared state. A sequential program does not.

The same distinction applies to agents. An agent that spawns subagents, manages their execution, shares context between them, and coordinates their results is architecturally different from an agent that just grinds through a task on its own.

So if you’re going to call something an “async agent,” call it that. Not an agent that runs for a while. Not an agent that runs in the cloud. Not an agent triggered by a cron job. An agent that manages other agents concurrently. Everything else is just an agent you happened to not wait for.