alt Hacker NewsEveryone’s building “async agents,” but almost no one can define them
Comments
the async framing maps cleanly if you think about it in terms of control flow rather than latency. the real distinction isn't "runs for a long time", it's whether the orchestrator yields control and gets notified via callback/event vs. polling a status endpoint.
most things people call "async agents" today are really just synchronous RPC calls with a long timeout. the agent blocks the caller's context window the entire time. true async means the calling agent can spawn the task, context-switch to something else, and resume when it gets a structured completion signal - basically await semantics but for agent-to-agent or agent-to-human handoffs.
the hard engineering problem isn't the async dispatch, it's state serialization: how do you snapshot enough context that the agent can resume coherently after an arbitrary pause without re-reading the entire conversation history?
that's where most implementations i've seen fall apart.
- I ask for butter and walk away. - It passes the butter to where I expect it to be when I return. - That is its purpose.
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.
"Background job"?
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.)
Read my post on this from 9 months ago: https://jdsemrau.substack.com/p/designing-agents-architectur...
[dead]
For an example of what an "async" agent implementation should help you accomplish: https://youtu.be/hGhnB0LTBUk?si=q78QjgsN5Kml5F1E&t=5m15s
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.