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.
* 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.