Cloudflare introduced its Agents SDK for stateful agent applications on Workers

Cloudflare dated the SDK introduction to February 25^{[source 1]}

On February 25, 2025, Cloudflare published a changelog entry introducing its Agents SDK. The entry pointed developers to a chat-based agent starter for Workers and named tool calling, state synchronization and a React front end. This is an SDK and starter announcement, not evidence that a deployed agent has a complete product design. A starter can accelerate the first interaction while leaving application data boundaries, identity, retention and operational failure handling to its implementer.

Synchronized state described an application concern rather than a correctness guarantee^{[source 1][source 2]}

Stateful agent software needs a clear answer to what belongs to a session, what survives a reconnect and what can be shared across clients. Cloudflare’s introduction made state synchronization part of the SDK story, which is useful because conversational interfaces otherwise often hide state changes behind a transcript. The announcement does not prove ordering, conflict resolution or recovery behavior for a particular application. Those properties depend on the state model, client lifecycle and the authority granted to an agent tool.

Tool calling and later MCP support remained separate capability records^{[source 1][source 2]}

The February starter named tool calling, while Cloudflare’s April Developer Week update later described Agents SDK support for MCP clients and related server capabilities. These are related but distinct events. A tool interface can expose a narrow read operation or a consequential external action; MCP compatibility does not decide which one it should be. The later announcement is used only for its later context and is not projected back into February as an original SDK feature.

The event was a framework introduction, not an autonomous-operation claim^{[source 1][source 2]}

Cloudflare’s February record supports the conclusion that it introduced an Agents SDK and a Workers starter path for chat applications with state and tools. It does not establish current package APIs, an availability guarantee, a particular billing outcome or a claim that durable state automatically makes an agent safe. This historical account does not duplicate the separate MCP, A2A or AgentCore stories elsewhere in the archive. It keeps the event to the SDK introduction and its stated building blocks. An implementation still has to decide when a state update is visible to a user, how concurrent tool results are reconciled and what happens when a client reconnects after an external action has started. It must also decide which state belongs in a durable object and which must stay outside the agent’s context, especially where a history could contain sensitive inputs or authority decisions.

The front end may display a coherent conversation while an underlying action has failed, so user-visible status must be tied to durable completion evidence. A session transcript alone cannot prove whether a tool completed, retried or was rejected by an external system.