Almost every agent demonstration has the same shape. Someone types a request, the agent reasons for a few seconds, calls two or three tools and returns a result. The whole thing fits inside one session, one process and one minute.
Very little important work in an organisation has that shape. A site transfer waits for two managers to agree. A leave correction waits for payroll's monthly cut-off. A supplier query waits for the supplier. A procurement request waits for budget approval, then for a quote, then for a second approval because the quote came in higher than expected. The work is not hard in any single step. It is long, and most of its elapsed time is spent waiting.
That difference matters more than any model choice. An agent that holds its progress only in the memory of a running process cannot own work that outlives the process. It will lose its place the first time a server restarts, a deployment rolls out or a timeout fires. It will then either start again and repeat actions it already took, or quietly drop the request. Neither is acceptable for something an employee is relying on.
CloudNala's position is straightforward: before an agent is allowed to own a process that spans hours or days, its state must be durable, identifiable and resumable, in the same way a workflow engine's state is. If that is not in place, the agent should start the process and hand it to a system that can hold it, not pretend to own it.
This series, The Agentic Enterprise, is about moving from chat-shaped agents to governed systems that do real work across an organisation. It starts here because durable state is the first place where a convincing demo and a production capability part ways.
The running example
Karoo Mills is fictional, and its systems and figures are illustrative. It is a Bloemfontein food manufacturer with about 6,000 staff across nine sites: mills, bakeries, a distribution centre and a head office. Most production staff do not sit at a desk. HR service has historically run on a phone line, a shared mailbox and a walk-in office at each site.
Karoo Mills is building an HR service agent that employees reach on WhatsApp, Microsoft Teams and the HR portal. It answers policy questions, lets employees see their own leave and payslip information, and helps with changes such as leave corrections, banking detail updates and site transfers.
The first two jobs are conversational. The third is not. A site transfer, for example, needs the employee's request, approval from the current site manager, acceptance from the receiving site manager, a check against the receiving site's headcount plan, and an update to payroll before the 20th of the month so the employee is paid from the right cost centre. In practice that takes between two days and two weeks.
What goes wrong when state lives in memory
The first version of the Karoo agent was built the way most prototypes are. Each conversation ran in a process that kept the conversation history and the agent's working notes in memory. When the agent needed a manager's approval, it sent the request and waited for a reply.
Then three ordinary things happened in the first week of the pilot:
- The platform team deployed a fix on a Tuesday afternoon. Every running agent process restarted.
- A manager took four days to respond. The agent's session timed out after 24 hours.
- An employee sent a follow-up message on WhatsApp ("any news?"), which arrived as a new conversation with no link to the first.
In each case the agent lost its place. Worse, in one case it did not know it had lost its place. A fresh run picked up the employee's follow-up, could not see that an approval request had already been sent, and sent a second one. The manager received two identical requests and approved both. The transfer was recorded twice in the case system.
None of this was a model failure. The model did exactly what it was asked. The failure was architectural: a long-running business process had been given a short-lived home.
Durable state, in plain terms
Durable state means the agent's progress is written somewhere that survives the process. When the process stops, for whatever reason, a new process can read that record and continue from the same point, with the same facts, under the same rules.
Four ideas make this work.
A thread identity. Every piece of work gets a stable identifier from the moment it starts: one transfer request, one ID. Every message, tool call, approval and decision attaches to that ID. When the employee writes "any news?" a day later, the channel adapter resolves it to the open thread rather than starting a new one. Without a thread identity, there is nothing to resume.
Checkpoints. At meaningful points, the agent writes its state to durable storage: which step it has reached, what it has learned, what it has done and what it is waiting for. A checkpoint after each tool call is common; the important rule is that a checkpoint is written before the agent starts waiting, not after.
Resume, not replay. When a run continues, it continues from the last checkpoint. It does not rerun the conversation from the beginning and hope the model makes the same choices. A replay can take a different path. A resume cannot.
Idempotent actions. Some steps will inevitably run twice, because a process can fail after sending an approval request but before recording that it sent one. Each side-effecting action therefore carries an idempotency key derived from the thread and the step. If the same request arrives twice, the receiving system recognises the key and does nothing the second time.
These are not new ideas. Workflow engines, message queues and payment systems have relied on them for decades. What is new is that agent frameworks have started to offer them as built-in features, and teams are discovering they need them the moment an agent is allowed to wait.
What the checkpoint should contain
A checkpoint is easy to get wrong in both directions. Store too little and the resumed run has to ask the employee again. Store everything, including the full transcript and every intermediate reasoning step, and the checkpoint becomes a growing pile of personal information with no clear retention rule.
Karoo's architects treated the checkpoint as a business record and asked what someone would need when the run resumes or is audited.
Two of those fields are easy to miss.
The prompt and workflow version matters because instructions change. If the HR policy prompt is updated on Wednesday, a transfer that started on Monday should either finish under Monday's rules or be explicitly migrated. Silently resuming under new rules can change a decision halfway through a case.
The tool results with timestamps matter because the world moves while the agent waits. The receiving site's headcount plan may have changed in the four days the manager took to reply. A resumed run should know that its earlier lookup is four days old and decide whether to refresh it before acting on it.
The checkpoint should not be confused with memory. Memory, in the sense covered in our Memory Is an Architecture Decision series, is about what an agent remembers across separate pieces of work. Durable state is about one piece of work surviving interruption. A transfer request's checkpoint should be retained for as long as the case record requires and no longer, under the same rules as the case. Treating it as a general memory store invites the problem described in Conversation history is not a memory strategy.
Waiting is a state, not a pause
The most useful shift for Karoo's team was to stop thinking of waiting as the agent "pausing". Waiting is a named state with an owner, a reason and a deadline.
When the agent sends the approval request to the current site manager, the thread moves to waiting for manager approval. The checkpoint records who is being waited on, since when, and what happens if nobody responds. Karoo's rule is illustrative but typical: a reminder after two working days, escalation to the site HR officer after four, and a message to the employee each time the status changes. The agent process does not need to be running during any of this. A scheduler or an incoming event wakes the thread when something happens.
This design makes three things possible that the in-memory version could not do:
- A person can step in. An HR officer can open the thread, see exactly where it stands, correct a fact (the receiving site was entered wrongly) and let the agent continue. The correction becomes part of the record.
- Runtime debugging becomes possible. When a thread misbehaves, the team can inspect the checkpoint history step by step instead of trying to reproduce a conversation that happened last week.
- Deployments stop being dangerous. A release no longer needs to wait for every conversation to finish. Running threads resume on the new code from their last checkpoint, under the workflow version they started with.
Should the agent own the process at all?
Durable state answers how an agent can survive a long process. It does not answer whether the agent should own it.
For Karoo, the honest answer differed by request type. A leave correction is short and well bounded: the agent can gather the facts, open a case, wait for the payroll clerk and report back. A site transfer has more rules, more people and more consequences. Karoo already had a case-management system with a transfer workflow, deadlines and audit trail. Rebuilding that workflow inside an agent would have duplicated rules that the HR operations team maintains and tests.
So the design settled on a split. The agent owns the conversation and the information gathering. It opens the transfer case in the case system with every required fact attached, and the case system owns the approvals, deadlines and payroll update. The agent's durable thread follows the case, reports status to the employee and answers questions, but it does not hold the authoritative state of the transfer. We described the same boundary for a bank in Where one agent stops and workflows begin.
That is not a retreat from agents. It is a rule worth applying broadly: the system that holds the authoritative state of a process should be the one designed to hold it. Sometimes that is an agent runtime with durable execution. Often it is an existing workflow or case system that the agent drives through a well-defined interface.
A practical test before an agent owns a process
Before Karoo allows any agent to own a process that waits for people or deadlines, the architecture review asks seven questions. They work for any organisation.
| Question | What a good answer looks like |
|---|---|
| Does every request get a thread ID at the start? | Yes, and every channel resolves follow-ups to it |
| Is a checkpoint written before every wait? | Yes, including what is awaited, from whom, and the deadline |
| What happens if the process restarts mid-step? | The step resumes from the checkpoint; side effects are idempotent |
| Which prompt and workflow version applies on resume? | The version recorded at the start, unless explicitly migrated |
| Can a person inspect and correct a running thread? | Yes, with the correction recorded |
| How long is checkpoint data kept, and why? | Tied to the case record's retention rule, not indefinite |
| Is there a better system of record for this process? | Considered, and the decision written down |
If the team cannot answer these, the agent is not ready to own the process. It can still help: gather facts, open the case and report status. That is often most of the value anyway.
What this means for the rest of the series
Durable state is the floor, not the ceiling. Once an agent can survive a long process, the next questions are about how work is divided and who answers for it. Part 2 looks at multi-agent designs and why delegating from one agent to another moves work without moving responsibility. Part 3 returns to Karoo's HR agent to show how much of it is integration rather than intelligence. Parts 4 and 5 step back to the organisation's AI capability map and the toolkit that supports it.
For a broader view of what makes an agent production-ready, see Agentic AI beyond the demo, and for the loop inside a single run, The AI agent loop.
Next: Part 2, Delegation does not remove accountability. All parts are on the series page.
How CloudNala can help
We review agent designs before they are trusted with long-running work: where state lives, how threads are identified across channels, what a checkpoint holds, how side effects are made idempotent, and whether an existing workflow or case system should own the process instead. The output is a short architecture decision record and a list of changes to make before the pilot widens, so the first restart or slow approval does not become the first incident.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Agentic AI Architecture Review or write to us at consult@cloudnala.co.za