hey, ishaan here (kartik's cofounder). this post came out of a lot of back-and-forth between us trying to pin down what people actually mean when they say "async agents."
the analogy that clicked for me was a turn-based telephone call—only one person can talk at a time. you ask, it answers, you wait. even if the task runs for an hour, you're waiting for your turn.
we kept circling until we started drawing parallels to what async actually means in programming. using that as the reference point made everything clearer: it's not about how long something runs or where it runs. it's about whether the caller blocks on it.
i just imagine it as the swap between "human watching agent while it runs"
vs "agent runs for a long time, tells the user over human interfaces when its done" eg. sends a slack. or something like gemini deep research.
an extension would be that they are triggered by events and complete autonomously with only human interfaces when it gets stuck.
theres a bit of a quality difference rather than exactly functionally, in that the agent mostly doesnt need human interaction beyond a starting prompt, and a notification of completion or stuckness. even if im not blocking on a result, it cant immediately need babying or i cant actually leave it alone
The real question is what happens when the background job wants attention. Does that only happen when it's done? Does it send notifications? Does it talk to a supervising LLM. The author is correct that it's the behavior of the invoking task that matters, not the invoked task.
(I still think that guy with "Gas Town" is on to something, trying to figure out connect up LLMs as a sort of society.)
You can use the idea to spin-off background agent tasks that can then be seamlessly merged back into context when they complete.
The example above is a product specific approach but the idea should be applicable in other environments.... it's really an attempt to integrate long running background tasks while continuing with existing context in an interactive manner.
When you start working on the problem of working with automation programs (AKA agents) in an interactive human-in-the-loop fashion, you will naturally run into these kinds of problems.
We've all seen sci-fi movies with AI assistants that seamlessly work with humans in a back and forth manner, async spin-offs are essential for making that work in practice for long running background tasks.
One weird skill I have is the ability to describe simple concepts as complex and confusing systems. I’ll take a go at that now.
When working with LLMs, one of my primary concerns is keeping tabs on their operating assumptions. I often catch them red-handed running with assumptions like they were scissors, and I’m forced to berate them.
So my ideal “async agents” are agents that keep me informed not of the outcome of a task, but of the assumptions they hold as they work.
I’ve always been a little slow recognizing things that others find obvious, such as “good enough” actually being good enough. I obtusely disagree. My finish line isn’t “good enough”, it’s “correct”, and yes, I will die on that hill still working on the same product I started as a younger man.
Jokes aside, I really would like to see:
1. Periodic notifications informing me of important working assumptions.
2. The ability to interject and course correct - likely requiring a bit of backtracking.
3. In addition to periodic working assumption notifications, I’d also like periodic “mission statements” - worded in the context of the current task - as assurance that the agent still has its eye on the ball.
How about framing this in terms of two orthogonal axes the article doesn’t name: concurrency (actors) and continuity (durable execution).
* Durable execution: long‑running, resumable workflows with persistence, replay, and timeouts.
* Actors: isolated entities that own their state and logic, process one message at a time, and get concurrency by existing in large numbers (regardless of whether the runtime uses threads, async/await, or processes under the hood).
Combine the two and you get a "Durable actor", which seems close to what the article calls an “async agent”: a component that can receive messages, maintain state, pause/resume, survive restarts, and call out to an LLM or any other API.
And since spawning is already a primitive in the actor model, the article’s "subagent" fits naturally here too: it’s just another actor the first one creates.
I'll take a stab at it. An async agent is an agent that is triggered autonomously, without direct human intervention, where its execution does not have tight temporal coupling with the other components of the system (agent or otherwise).
Practically speaking, it means they often operate within a larger system, that due to its open-ended nature, produces emergent behavior, meaning behavior that was not explicitly designed.
Nothing new when people make up bullshit words that no one can define. "Life" is a really good one. Or AGI is a recent popular one. And don't forget my favorite bullshit word: Spirituality.
For async agents and for "life" I sort of have a blurry shape of what the thing is in my head, but spirituality is the strangest one. There is no shape. The word is utter bullshit, yet people can carry the word and use it without realizing it has no shape or meaning. It's not that I don't get what "spirituality" is. I "get" it as much as everyone else but it's I've taken the extra step to uncover the utter meaninglessness of the word.
Don't spend too much time thinking about this stuff. It's not profound. You are spending time debating and discussing a linguistic issue. Pinpointing the exact arbitrary definition of some arbitrary set of letters and sounds we call a "word" is an exercise in both arbitrariness and pointlessness.
I like the term "asynchronous coding agent", which I define as the category of coding agent which runs in a container somewhere and files a PR when it's done.
OpenAI Codex Cloud, Claude Code for the web, Gemini Jules and I think Devin (which I've not tried) are four examples.
I like that "asynchronous coding agent" is more specific than "asynchronous agent" - I don't have a firm idea of what an "asynchronous agent" is.
One catch though is that the asynchronous coding agents are getting less asynchronous. Claude Code for the web lets you prompt it while it's running which makes it feel much more like regular Claude Code.
Async Agent = a LLM powered application using a well understood thinking / planning loop and reasonably clear success criteria to process a prompt that takes longer than a tacitly agreed upon amount of time so that the user needs to be notified of the outcome instead of waiting for it.
Async means I can delegate stuff to it and expect it's fixed when I come back. Also I can text it from my phone while I'm on the toilet. Very important.
OpenClaw meets this definition, but so does a 50 line Telegram wrapper around Claude Code / Codex ;)
21 comments
[ 3.2 ms ] story [ 45.1 ms ] threadthe analogy that clicked for me was a turn-based telephone call—only one person can talk at a time. you ask, it answers, you wait. even if the task runs for an hour, you're waiting for your turn.
we kept circling until we started drawing parallels to what async actually means in programming. using that as the reference point made everything clearer: it's not about how long something runs or where it runs. it's about whether the caller blocks on it.
Something is async when it takes longer than you're willing to wait without going off to do something else.
vs "agent runs for a long time, tells the user over human interfaces when its done" eg. sends a slack. or something like gemini deep research.
an extension would be that they are triggered by events and complete autonomously with only human interfaces when it gets stuck.
theres a bit of a quality difference rather than exactly functionally, in that the agent mostly doesnt need human interaction beyond a starting prompt, and a notification of completion or stuckness. even if im not blocking on a result, it cant immediately need babying or i cant actually leave it alone
The real question is what happens when the background job wants attention. Does that only happen when it's done? Does it send notifications? Does it talk to a supervising LLM. The author is correct that it's the behavior of the invoking task that matters, not the invoked task.
(I still think that guy with "Gas Town" is on to something, trying to figure out connect up LLMs as a sort of society.)
You can use the idea to spin-off background agent tasks that can then be seamlessly merged back into context when they complete.
The example above is a product specific approach but the idea should be applicable in other environments.... it's really an attempt to integrate long running background tasks while continuing with existing context in an interactive manner.
When you start working on the problem of working with automation programs (AKA agents) in an interactive human-in-the-loop fashion, you will naturally run into these kinds of problems.
We've all seen sci-fi movies with AI assistants that seamlessly work with humans in a back and forth manner, async spin-offs are essential for making that work in practice for long running background tasks.
When working with LLMs, one of my primary concerns is keeping tabs on their operating assumptions. I often catch them red-handed running with assumptions like they were scissors, and I’m forced to berate them.
So my ideal “async agents” are agents that keep me informed not of the outcome of a task, but of the assumptions they hold as they work.
I’ve always been a little slow recognizing things that others find obvious, such as “good enough” actually being good enough. I obtusely disagree. My finish line isn’t “good enough”, it’s “correct”, and yes, I will die on that hill still working on the same product I started as a younger man.
Jokes aside, I really would like to see:
1. Periodic notifications informing me of important working assumptions. 2. The ability to interject and course correct - likely requiring a bit of backtracking. 3. In addition to periodic working assumption notifications, I’d also like periodic “mission statements” - worded in the context of the current task - as assurance that the agent still has its eye on the ball.
* Durable execution: long‑running, resumable workflows with persistence, replay, and timeouts.
* Actors: isolated entities that own their state and logic, process one message at a time, and get concurrency by existing in large numbers (regardless of whether the runtime uses threads, async/await, or processes under the hood).
Combine the two and you get a "Durable actor", which seems close to what the article calls an “async agent”: a component that can receive messages, maintain state, pause/resume, survive restarts, and call out to an LLM or any other API.
And since spawning is already a primitive in the actor model, the article’s "subagent" fits naturally here too: it’s just another actor the first one creates.
Practically speaking, it means they often operate within a larger system, that due to its open-ended nature, produces emergent behavior, meaning behavior that was not explicitly designed.
For async agents and for "life" I sort of have a blurry shape of what the thing is in my head, but spirituality is the strangest one. There is no shape. The word is utter bullshit, yet people can carry the word and use it without realizing it has no shape or meaning. It's not that I don't get what "spirituality" is. I "get" it as much as everyone else but it's I've taken the extra step to uncover the utter meaninglessness of the word.
Don't spend too much time thinking about this stuff. It's not profound. You are spending time debating and discussing a linguistic issue. Pinpointing the exact arbitrary definition of some arbitrary set of letters and sounds we call a "word" is an exercise in both arbitrariness and pointlessness.
OpenAI Codex Cloud, Claude Code for the web, Gemini Jules and I think Devin (which I've not tried) are four examples.
I like that "asynchronous coding agent" is more specific than "asynchronous agent" - I don't have a firm idea of what an "asynchronous agent" is.
One catch though is that the asynchronous coding agents are getting less asynchronous. Claude Code for the web lets you prompt it while it's running which makes it feel much more like regular Claude Code.
And I agree, "async agents" makes little sense
OpenClaw meets this definition, but so does a 50 line Telegram wrapper around Claude Code / Codex ;)
https://github.com/a-n-d-a-i/ULTRON
Spoiler: it just pipes the msg into claude -p $msg or codex exec $msg
You can do anything if you believe