Cloudflare's New Agents SDK Drop Puts Skills, Cron, and Durable Reasoning in Your Worker. Here's What a Solo Builder Should Adopt and What to Skip.
Cloudflare just shipped another Agents SDK update, and the additions to @cloudflare/think read like a checklist of things solo builders normally bolt together by hand: on-demand Agent Skills, declarative scheduled tasks, a chat messenger starting with Telegram, and durable reasoning steps inside Workflows. Stack that on top of what they shipped during Agents Week back in April (sandbox execution, private networking, and sandbox tunnels that expose a container service through a public preview URL) and the shape of the bet becomes obvious. Cloudflare wants to be the default runtime for agents, and for a one-person team that's an appealing pitch, because the alternative is you maintaining all of this plumbing yourself.
But "Cloudflare will host your whole agent" is not automatically a yes. Some of these primitives genuinely delete work you shouldn't be doing. Others quietly weld your product to one vendor's proprietary model of how agents should run, and the exit cost is real. So here's how I'd triage it, primitive by primitive, as someone who has to live with the maintenance and the lock-in alone.
Adopt without hesitation: scheduling and sandboxes
Declarative scheduled tasks are the easiest yes on the list. Every solo builder eventually needs cron (a daily digest, a cleanup job, a polling loop) and the homegrown version is always worse than you want it to be. You stand up a separate machine or a third-party scheduler, you wire up secrets, you build retry logic, you discover six weeks later that a job silently stopped firing. Declarative scheduling that lives next to your agent code, in the same deployment, removes a whole category of "why didn't that run" debugging. The lock-in here is shallow: a cron expression and a handler function port to any other runtime in an afternoon. Take it.
Sandbox execution and tunnels are the second easy yes, with a small asterisk. If your agent runs untrusted or generated code, and increasingly they do, you need isolation, and rolling your own container sandbox with safe teardown is genuinely hard to get right. Cloudflare's version handles the lifecycle, and sandbox.destroy() tears down the tunnel and its DNS record alongside the container so you don't leave dangling endpoints behind. The tunnels in particular are a real convenience: a zero-config quick tunnel on a trycloudflare.com URL for throwaway previews, or a named persistent tunnel when you need a stable hostname. The asterisk is that this only pays off if you're already on Workers. If you're not, adopting sandboxes is also adopting the platform, which is a bigger decision than the feature.
Adopt carefully: Agent Skills and the Telegram messenger
On-demand Agent Skills are useful and slightly seductive. The pattern, load a capability into the agent only when it's needed instead of stuffing every tool into the context up front, is good engineering, and it's the kind of thing that's annoying to build yourself. Use it. Just keep your skills defined as plain functions with clean inputs and outputs, so the skill is yours and only the loading mechanism is Cloudflare's. If you let the framework's abstractions leak into your actual business logic, you've turned a convenience into a dependency.
The Telegram messenger is a nice-to-have that I'd treat as exactly that. A built-in chat channel is a fast way to give your agent a front door, and Telegram is a sensible first one. But messaging integrations are commodity work (there are a dozen libraries that do this) so let it save you an afternoon, don't let it become the only way users can reach your agent. Channel logic is cheap to rebuild; design so it's swappable.
Think hard before adopting: durable reasoning in Workflows
This is the one to slow down on. Durable reasoning steps inside Workflows are the most powerful thing in the release and the most entangling. The pitch is that your agent's multi-step reasoning becomes durable: it survives restarts, resumes where it left off, doesn't lose state when something crashes mid-run. For long agentic jobs that is genuinely valuable, and building durable execution yourself is a serious undertaking.
The cost is that durable execution is where your application's core logic stops being portable. Scheduling is a cron string. A skill is a function. But once your agent's reasoning is expressed as a Cloudflare Workflow with durable steps and Cloudflare's checkpointing semantics, that flow is your product, and it's written in a dialect that doesn't run anywhere else. Moving off it isn't a config change. It's a rewrite of the part that's hardest to rewrite. That might be a price worth paying. Just pay it with your eyes open, knowing you're buying durability with portability, and not because it was bundled into the same changelog as a cron feature you wanted.
What I'd actually do
If you're already on Workers, take the scheduling, take the sandboxes and tunnels, take Agent Skills with your logic kept in plain functions, and treat the messenger as a freebie. That's most of the value with little of the lock-in, and it really does remove a weekend of glue code you have no business writing as a team of one.
Hold the line on durable-reasoning Workflows until you have a specific job that needs durability and you've decided that job is worth coupling to the platform. Don't let the convenience of the cheap primitives pull your core reasoning into the expensive-to-leave one. The skill here isn't picking a vendor. It's drawing the line between the plumbing you happily rent and the logic you insist on owning.
The honest counter-take: this caution can cost you. If you're genuinely all-in on Cloudflare (Workers, D1, R2, the whole stack) then refusing durable Workflows on portability grounds is fighting a war you've already conceded, and you're just leaving real reliability on the table to protect an exit you'll never take. For that builder, adopt all of it and move faster than the person hedging. Portability is insurance, and insurance is only worth its premium if there's a real chance you'll file a claim. Know which builder you are before you decide how much of this to swallow.
Author
Lukas
@lukcombinator