Scheduling the waiting work with Cloudflare Agents

A contract draft reaches the legal team. An agent has marked missing clauses and set a reminder for a response. Three days pass without an answer. The scheduled job might have fired exactly as planned. But does the same person still own the contract? Has the draft changed? Who should receive the reminder now? Scheduling an agent’s wake-up is not the same as managing a waiting task inside a company.

Cloudflare’s open source Agents SDK provides a runtime for addressable, stateful agents built on Durable Objects. When referring to the Cloudflare agent toolchain, sometimes called “Cloudflare OS,” I do not mean a separate operating system product. The SDK supplies identity, persistent state, connections, and scheduling. The loop in which a model chooses tools and uses their results can be built separately or provided by a harness. Neither the runtime nor that loop defines an organization’s approval calendar on its own.

Waiting needs an explicit state

In the contract example, finishing the review does not finish the job. A person needs to respond. Recording only “reminder scheduled” misses most of the information needed to act later. The work record should identify the draft version under review, the person or role expected to decide, the deadline, and who takes over if it passes. Without that state, an agent waking on Monday might read the last chat message and send a persuasive but obsolete reminder to the wrong colleague.

Cloudflare’s guide to long-running agents makes a useful distinction. A long-lived agent is not a continuously running process. It has a durable identity and stored state, wakes when needed, does work, and becomes idle again. State, SQL data, and schedules can survive hibernation; variables in process memory and open requests cannot be treated the same way. “Continue in three days” therefore belongs in a durable work record, not just in the memory of a running function.

An instance might represent a contract, a team, or a user. That choice changes what must be recorded. If one user agent handles all the user’s contracts, every reminder needs an unambiguous contract reference. If each contract has its own agent instance, the isolation is clearer, but someone must still assemble a team-wide queue and handle ownership changes. The SDK helps address instances by identity. It does not know which colleague is responsible for a particular agreement.

There are two clocks

The technical clock tells an agent when to wake. The business clock says which decision is due and when the evidence behind it expires. Suppose a lawyer edits the draft on Friday. A reminder scheduled earlier may run on Monday against the wrong version. The schedule still exists, but the reason for the reminder has changed. When the agent wakes, it should reread the work record: Is the decision still pending? Is the reviewed document version current? Could the response have arrived through another channel?

The Agents API reference documents scheduling and state methods. These primitives can bring work back to a named agent at a later time. Deadlines, working hours, delegation, and approval authority are application policies. A timer firing must not be interpreted as “legal rejected the contract.” It can establish only that no verified decision was recorded by the stated time. Turning silence into an adverse decision would require an explicit business rule, not a convenient inference by the model.

A small record can carry the necessary fields: work ID, document version, responsible role, decision deadline, last checked time, and next action. At the scheduled time the agent checks the source again. If an answer exists, it does not send a reminder. If the document changed, it closes the old review request and asks a person to inspect the new version. If no answer exists, it notifies the owner; if escalation is required, it follows a predefined delegation rule. This is a safer starting point than letting a model improvise who has authority to approve.

Retrying delivery is not redoing a decision

A reminder service may accept a message and then lose the connection before returning a response. The agent cannot safely infer from a missing response whether the notification was delivered. Recoverable execution does not make a side effect in an external system occur exactly once. A stable operation key derived from the work ID and reminder type helps distinguish retries when the receiving service supports it. Otherwise the team needs to read the delivery record or flag the outcome for human review.

Cloudflare’s fiber documentation describes runFiber() for recovering interrupted agent work and stash() for preserving intermediate results. Workflows provide another route for independent, multi-step processes. With either approach, record “the agent woke” separately from “the business decision changed.” The earlier article on handoffs between agents examined what context crosses an agent boundary. A delayed wake-up raises the same question across time: if the owner changes while work waits, the next scheduled action must be interpreted against the new responsibility, not the old chat context.

A narrow test before automation

Start with one kind of contract. Let an agent review a draft and create a “waiting for human response” state without granting final approval. Schedule a short check in a test environment. Then deliberately test three cases: an answer arrives before the deadline, the document changes during the wait, and delivery of a reminder remains uncertain. Can an operator see both the last confirmed state and the person responsible for the next move from one work record?

This test is not about making the reminder fast. It is about avoiding false certainty. “Notification failed” and “no decision has been made” are different events. “Waiting for approval” and “deadline passed” are also different states. When operators can tell them apart, they can investigate a delayed task without letting the agent quietly decide on someone’s behalf. A changed deadline policy should trigger a review of pending records as well as the scheduling code: old jobs may still be waiting under the previous assumptions.

Cloudflare Agents offers a technical foundation for waking a named agent and retaining its state while it waits. Who owns the work and who takes over when time runs out belong to an organizational layer. agentic-organization focuses on that layer as a self-hosted, file-based platform for managing AI agents as first-class members of an organizational chart.