For a long time, most of us built software under roughly the same mental model.
A user clicks a button. The browser sends a request. A server that's been warm for hours or days runs deterministic logic. A database updates a few rows. Repeat that a few billion times and you get most web applications of the last twenty years.
That world came with assumptions we rarely named: servers live a long time, connections are stable, concurrency is paced by human clicks, and "state" mostly means the latest value.
Then we started building agents.
Imagine a coding agent refactoring a two‑million‑line codebase. You give it one instruction:
"Make this service multi‑tenant and update the relevant tests."
From your point of view, that's a single request. From the agent's point of view, it's a trajectory: dozens or hundreds of steps. It has to understand the current design, sketch a plan, follow call graphs, touch many files, run tests, fix failures, and iterate.
Within seconds, one instruction can fan out into thousands of tool calls and repeated model calls. To the agent, it's one coherent path. To a traditional database, it no longer looks like a request. It looks like a tree of work squeezed into a tiny window of time.
Start with the lowest layer: where code runs.
We used to aim everything at a small number of long‑lived servers. You tuned them, kept them warm, and built systems around stable identities and stable connections.
That isn't the world many teams operate in now.
Compute has been sliced into short‑lived units: browser workers, service workers, edge runtimes, serverless functions, containers, micro‑VMs. They appear, do some work, and vanish. You don't SSH into a Lambda. It shows up, runs, and disappears.
Early serverless stacks made the mismatch obvious. People bolted short‑lived functions onto long‑lived, connection‑hungry databases. Sometimes it worked. Often it meant connection storms, cold starts, and awkward coordination patterns.
Agents naturally lean into the compute world we've ended up with. They are parallel and bursty by default. One "session" can span minutes or hours, but it rarely runs as one warm process. It fans out into many short steps across many workers, sometimes with gaps in between. That shape fits edge and serverless extremely well.
The catch is continuity. From the agent's point of view, it's one coherent run. From infrastructure's point of view, it's a sequence of short executions stitched together over time. No single worker lives as long as the run itself. A session might pause and resume hours later, hop across regions, branch, and rejoin.
So durable state comes back, but in a different form. It's not enough to persist the latest values. You need to persist the continuation of the run: the "what happens next," plus the context it depends on, somewhere more durable than any one process. Short‑lived workers can then pick up that continuation, advance it a little, and hand it back off.
If the word continuation doesn't resonate, here's the plain version: