Cloudflare Agents and the handoff between agents

A purchase request arrives. One agent reads the document, another checks the supplier, and a third summarizes what is missing before payment. Each may perform its own task correctly. Yet the purchasing specialist still cannot answer a basic question: who owns this request now, and what evidence did the last agent use? Splitting work across agents distributes effort. It does not automatically create an accountable process.

The open source Cloudflare Agents SDK provides a way to build persistent agent instances on Durable Objects. An instance has its own addressable identity, storage, and lifecycle. The toolkit also supplies building blocks for real-time connections, scheduling, tools, and multi-step work. Think is a separate, more opinionated layer for the model-and-tools loop. The SDK provides a runtime and components; Think helps shape a particular kind of agent. Neither should be mistaken for an organization’s purchasing policy.

Earlier articles looked at surviving interruptions. Here the question is more mundane and often more troublesome: what crosses the boundary when one agent hands a task to another?

Separate runtime state from shared work state

Per-instance storage is useful. A purchasing agent’s internal context need not mingle with a supplier verification agent’s session. But separation of storage does not explain how their conclusions become one decision. If the budget is in one instance, the supplier status in another, and the approval in a third system, a shared work identifier becomes essential.

Call a request request_431. Carry that identifier through each handoff. The handoff should say more than “checked”: it should identify the document revision used, when the supplier record was read, the actual result, and any unresolved question. The next agent gets a limited set of facts rather than a copy of the previous agent’s entire conversation. That is easier to inspect and reduces the chance of distributing sensitive material to systems that do not need it.

Cloudflare’s agent documentation distinguishes the stateful Agent class from Workflows for long-running, explicit processes that are not necessarily chats. This distinction helps when agents work on different parts of a purchase. Each agent may keep its own context, while a separate process record states which step is complete and which step waits for action. The team’s actual application architecture decides where that shared record lives.

A handoff is not a chat transcript

Imagine the first agent extracts an amount from an uploaded document. The second verifies the supplier. If the first writes “the amount is 40,000” and the document changes, the second cannot safely treat that sentence as current evidence. The handoff needs the source document’s identifier and revision, and a way to mark fields as missing or disputed. Without those details, the next agent should stop at “insufficient information,” not fill gaps with a plausible guess.

Two records help. One tracks technical execution: which tool was called, whether a response arrived, and whether it is safe to retry. The other tracks the business request: received, document inspected, supplier check pending, human approval required, or finished. The latter should be legible to the colleague who takes over. A transcript of internal agent messages might help debugging, but it is not a substitute for a concise, inspectable decision record.

Cloudflare documents agent tools for invoking chat-capable sub-agents as tools. This can be useful for a bounded research or summarization task. It does not turn a sub-agent’s answer into proof that a purchase was approved or entered in the accounting system. Permission to read supplier data and permission to write a purchase order are different grants. The application has to enforce those boundaries even if all the agents are implemented with the same SDK.

When is the job actually accepted?

A supplier agent may return “record matches.” That is one finding, not the outcome of the purchase request. Budget, contractual exceptions, and approval thresholds are different questions. If a person has final authority, the process must not quietly mark a request as complete when the agent produces a favorable summary. Pending approval is a real state. When the approval arrives, the process may need to check the supplier and document again, because either may have changed while the request waited.

Cloudflare Workflows can support long-running steps and pauses for human input. That infrastructure helps keep a process moving across waits, but it does not define which employee can approve which amount. If the approval rule changes, the team needs to review code, process conditions, and the organizational delegation together. Changing only one layer can leave different systems working from incompatible definitions of authority.

A more practical measure of success than the number of collaborating agents is whether someone can answer four questions from the work record at any point: who owns this request, what was last verified, what happens next, and which person resolves a disputed outcome? Without these answers, adding agents mostly adds handoff points that are hard to see.

Test a small handoff first

A pilot need not start with a large agent team. Pick one request type. Let one agent read input and a second perform a narrow verification; do not give either permission to write to the financial system. Define a shared request ID, required fields for a handoff, and the point where a person can intervene. Then test a missing document and an outdated supplier record on purpose. Do the agents surface uncertainty, or do they repeat each other’s assumptions as facts?

The expected artifact is not a polished chat transcript. It is a work record that another person can take over: source references for decisions, an explicit pending state, and a safe way to retry without creating a second purchase. If the human operator has to open several agent sessions to discover what happened, the boundaries between agents have been designed for the software rather than the work. A useful harness makes those boundaries tractable, but the team still has to decide what crosses them.

Cloudflare Agents provides flexible building blocks for agent state and communication. Ownership of cross-agent work belongs to a different layer. agentic-organization addresses that organizational layer as a self-hosted, file-based platform for managing AI agents as first-class members of an organizational chart.