Agent Architecture and Orchestration
Agent Lifecycle — Stack
Agent lifecycle › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
What you are choosing is a home for running instances and a guarantee about what happens to them when the machine underneath goes away.
- Survival of a restart. Whether an instance mid-task survives a deploy, a crash, or a node eviction, and what it costs to get that property.
- Transition visibility. Whether state changes are observable events with timestamps and causes, or merely the current value of a field somewhere.
- Supervision semantics. What the runtime does on its own when an instance fails — restart, escalate, leave it dead — and whether that policy is declarative.
- Timers and external wake-ups. Whether an instance can sleep for four hours or until a webhook arrives without occupying a worker the entire time.
- Resource ownership. Whether acquired resources can be tied to the instance such that they are released when it dies, including when it dies badly.
- Instance affinity. Whether a given instance must be served by a specific process, and what that does to rolling deploys and autoscaling.
- Disposal. Whether finished instances are enumerable, countable, and deletable on a retention schedule, or simply stop being referenced.
Options
| Option | Best for | Watch out for |
|---|---|---|
| In-process objects scoped to one request | Short interactive turns where a lost instance is a retry, not an incident | Nothing survives a deploy; a four-hour approval wait is impossible to express |
| Session store with stateless workers (Redis, PostgreSQL) | Conversational agents that must survive restarts without a workflow engine | Every state change is a serialisation decision; partial writes create instances in impossible states |
| Actor runtimes (Erlang/OTP, Orleans, Akka, Ray actors, Dapr actors) | Many concurrent long-lived instances with supervision and restart policies built in | Actor placement and affinity interact badly with aggressive autoscaling; durability is often an add-on |
| Durable workflow engines (Temporal, Restate, Azure Durable Functions, AWS Step Functions) | Instances that must survive anything, with timers and external signals as first-class | Determinism constraints on the code; versioning in-flight instances across deploys is its own discipline |
| Framework checkpointers (graph-runtime persistence layers over SQL or key-value stores) | Agent loops that already use a graph runtime and need resumability without new infrastructure | Checkpoint contents are framework-shaped; a framework upgrade can orphan in-flight instances |
| Container or microVM per instance (Kubernetes Jobs, Firecracker-based sandboxes) | Instances that execute untrusted code and need hard isolation boundaries | Start-up cost per instance; reaping is now an infrastructure concern with its own failure modes |
| Queue plus correlation identifier, no explicit instance object | Fan-out batch work where instances are bookkeeping rather than conversation | Lifecycle becomes implicit in message existence; "how many are running" stops being answerable |