An agent that closes the books for the month is not a chat. It runs for two days, talks to seven systems, pauses three times to wait for a human, and resumes after lunch. It has to survive deploys, network failures, model timeouts, and the occasional approver going on vacation.
Building that on a stateless cloud runtime is harder than it looks. Here is how we do it.
Every running workflow is a tree of step records in our database. A worker picks up the next step that is ready, executes it, writes the result, and exits. The same worker, or a different one, will pick up the next step seconds or hours later. There is no in-memory state. The workflow is the database.
This is the same pattern Temporal and Inngest use. We built ours because we wanted to integrate it tightly with the model layer, the eval bus, and the audit log, and because we wanted the steps to be human-readable.
When a step needs human approval, we do not block. We write the request to a queue, notify the approver, and the workflow goes idle. The worker is freed for other workflows. When the approver acts, we enqueue the next step. If the approver is out, the SLA fires and routes to the deputy.
From the agent's perspective, the human pause is indistinguishable from a long model call. The replay log shows it as one step, with the approver's identity and decision recorded.
We run chaos drills in staging weekly. The drill kills a random worker mid-step. The expectation is that the workflow resumes correctly when a new worker picks it up. Anything that violates that expectation is a P0 bug, not an edge case. This is the only way to be honest with customers about what days-long runs actually mean.