If two AI agents receive a refund request from the same customer at the same time, which one knows whether the request has already been approved? And who is actually allowed to issue the payment?
Cloudflare Durable Objects can provide a central place to store state and receive requests from multiple AI agents to change it. In a business process, we can write rules that require every agent to pass the same authorization and case-specific checks before proceeding. Reading, summarizing, and proposing an action remain the LLM's jobs.
That refund question interests me because it points to a possible business coordination layer for an AI system. This article describes a design I think is worth trying. It does not report results from a system already in production.
What Durable Objects can coordinate among agents
Each Durable Object has a unique identifier that requests can be directed to, and its own durable storage. Stored data remains available when an instance starts again. Data kept only in memory may disappear when the object stops running.
Each object's storage is strongly consistent and supports transactions within that object. I would define the boundary around a business case, such as one refund request, so all agents refer to the same case state. There is no need to put an organization's entire workload into one object.
Source: Durable Objects: compute, storage, and coordination
Several agents can help with one refund request
Imagine one refund request. One agent summarizes the customer's case, another checks the conditions, and a third prepares a response. They may finish at different times, but all three need to know which stage this request has reached, who has approved it, and what actions remain possible.
When an agent wants to change the state, it sends a request to that case's Durable Object, perhaps from "pending review" to "awaiting approval." The system checks permissions and conditions before accepting the change, then records the result in durable storage.
An agent's recommendation to issue a refund is not an approval. Approval must still follow the written rules and, where required, come from a person. The illustration therefore separates the approval point from the external system that actually makes the payment.
I think this could be useful to a business because it could answer when an agent's proposal was accepted, why, and by whom. But those records have to be deliberately designed and stored. They do not appear in full simply because the system uses Durable Objects.
Single-threaded execution and transactions still have limits
Each object runs on a single thread, but another task can proceed while one awaits an external service. State checks and transitions still need careful design. Do not assume every asynchronous request runs to completion before the next begins.
This matters especially when issuing payments. A write in the object and a payment through an external system are not part of the same transaction. If the network fails after a request is sent, we may not yet know whether the payment succeeded.
We need a request identifier for detecting repeats, such as an idempotency key where the provider supports one, and a process for reconciling amounts and actual status. Retrying while the first outcome is unknown can create a duplicate. Durable Objects do not, by themselves, guarantee that an external payment happens exactly once.
Sources: Durable Objects: compute, storage, and coordination · SQLite-backed Durable Object Storage
Agents SDK, Workflows, and Alarms serve different jobs
Cloudflare Agents SDK already uses Durable Objects as a foundation, giving an agent an identity and persistent state. Coordinating a business case as described here adds a choice of boundaries and rules suited to that work.
A process that waits for approval or runs over several steps may use Workflows to retain progress and retry failed steps. For example, it can start the next step after approval arrives. Recording workflow progress still does not put an external transaction inside the same transaction boundary.
Alarms can wake an object to check a request when it comes due. Alarm delivery is at least once, so an alarm may run more than once. Work triggered by it must tolerate a repeat without creating a duplicate result.
Sources: Cloudflare Agents SDK: Agent class internals · Using Agents with Workflows · Durable Objects Alarms
Start with one case whose state is clear and whose duplication matters
If I were to try this design, I would start with one process whose states can be described clearly, whose permission to change each state is known, and whose human approval points are explicit. A customer request or purchase order approval could fit. I would test simultaneous requests, repeats, and incomplete responses from external systems.
The test should show whether the team can follow a case after something goes wrong, identify which state changes the system accepted, and check the result with the external system. That evidence would help decide whether the experiment is ready to expand into production.
If you could choose one process in your organization, which one involves several people or agents and often leaves everyone asking, "Who has done what so far?"
Questions about Durable Objects in business processes
Do Durable Objects do the thinking for an LLM?
In this design, Durable Objects store case state and check requests to change it against written rules. The LLM reads, summarizes, and proposes an action. A proposal still has to pass the business system's conditions and approval permissions.
Do Durable Objects immediately prevent duplicate refunds?
No, not automatically. A transaction inside the object does not cover an external payment system. The design must check state, handle repeat requests with an idempotency key where the provider supports one, and verify the outcome when it is unclear whether a payment succeeded.
