TL;DR: Cloudflare just launched cf — a new CLI built for AI agents that covers all 3,000+ Cloudflare API operations, set to replace the old Wrangler tool which only has about 280 commands. But the new tool itself isn’t really the story. The number that matters is this: agents already make up 48% of Wrangler’s usage — up from just 25% six months ago. That means the primary user of this software tool is shifting from human to machine. And once that happens, the definition of a “good tool” flips entirely. This post breaks down exactly how it flips, and what you should do to make your own tools and APIs readable by agents.

Why the real news is “48%,” not the new tool

Let’s start with the facts. According to Cloudflare’s official announcement, they’ve launched a new command-line tool called cf, and they’re explicit that it’s designed for AI agents.

A CLI is the interface engineers use to operate a service by typing commands in a terminal. cf covers all 3,000+ of Cloudflare’s API operations and is set to replace the existing Wrangler — which, despite years of development, only has about 280 commands. Once cf stabilizes, Wrangler will still be maintained for another 18 months.

A fuller-featured new tool isn’t surprising on its own. What’s surprising is the number Cloudflare casually dropped along with it: agents already account for nearly half of Wrangler’s usage. Back in March that share was around 25%; it hit 48% in the most recent week. And agent usage patterns look nothing like human ones — agents average almost twice as many distinct commands as humans, and they’re nearly four times more likely to chain together six or more commands in a single run.

In other words, Cloudflare isn’t just “giving agents a little extra love” — it discovered that the primary user of its own tool is becoming a machine, and rebuilt a version for that machine. That’s the real signal here: the interface layer is quietly being redesigned for agents.

What does “designed for AI agents” actually mean: cf vs. Wrangler

Lay out cf’s design choices and you’ll notice almost every one of them is answering the same question: “If my user isn’t a human but an AI agent, what should I look like?”

  • Output defaults to JSON. Humans staring at a terminal prefer concise, readable text; agents want structured data they can parse directly. cf defaults to spitting out JSON, which Claude Code, Codex, and similar agents can read straight away.
  • You can find a command just by describing it. cf has a cf cli search that lets an agent describe what it wants to do in natural language and automatically surfaces the matching command — the agent doesn’t need to already know which of the 3,000 Cloudflare APIs to use.
  • Config files switched to typed TypeScript. cf uses cloudflare.config.ts, so agents can catch configuration mistakes on the spot through type checking and autocomplete, instead of finding out only after deployment blows up.
  • Built-in --dry-run. Simulate first, don’t actually act — a safety net built for non-human operators.

See the pattern? Every one of these design choices is a bit of a nuisance for a human.

As an engineer, why would I need 3,000 commands, or a giant blob of JSON every single time? But for an agent, every one of these is a hard requirement. Humans want fewer things that are easier to remember; agents want full coverage, searchability, structure, and the ability to rehearse. The two needs are almost opposites.

Three steps to make your own tools and APIs readable by AI agents

This isn’t just Cloudflare’s problem — it’s yours too.

As long as you’re ever going to let an AI agent operate your systems, your APIs, or your internal tools, the three principles below are worth applying right now. These are also the principles I actually follow every day running agent teams and building internal tools myself.

  1. Full coverage + searchability, instead of “small and memorable.” Stop assuming the operator will memorize your commands. Expose every operation you support, and provide a “describe what I want in natural language, help me find the right one” entry point. Humans rely on memory; agents rely on search — design for the latter.
  2. Structured output, not just human-readable text. Every response should include a structure a machine can directly parse (JSON or clearly defined fields) — don’t bury key information inside a paragraph of prose. When I build tools myself, every response carries both “a one-line summary for humans” and “fields for programs to read” — neither side gets shortchanged.
  3. Safe by default: simulate first, then act for real, and keep a confirmation step for anything irreversible. Agents call your tools more often and in more combinations than humans do (remember that “4x more likely to chain 6+ commands” stat?). So dry-run should be the default — anything that spends money, deletes data, or has external effects needs to be rehearsable and interceptable before it happens. I’m building a multi-analyst publishing system this week, and the entire pipeline is “simulate with dry-run by default + lock down with an allowlist.” I’d rather add one extra step than let an agent do something irreversible in one shot.

FAQ

Q1: I don’t use Cloudflare — does this news even matter to me?

Yes. Cloudflare is just the first major company to put the number out in the open — “a tool’s primary user becoming an agent” is going to spread to every tool and API you use and build, not just cf. The point isn’t the cf product itself; it’s the shift it reveals: the interface layer is being redesigned for machines.

Q2: Do I need to tear down and rebuild my existing human-facing CLI or API?

No, but you should add an “agent-friendly layer” on top. The cheapest three steps: offer a JSON output option alongside your existing output, add a natural-language command search entry point, and bolt a dry-run onto any dangerous operation. You’re not touching the existing human interface — you’re just making it legible to agents too.

Q3: Why do agents use roughly twice as many distinct commands as humans? What should that tell me?

Because agents aren’t afraid of the unfamiliar — they’ll explore the entire surface of a tool to find the best path, whereas humans tend to stick to the handful of commands they already remember. The takeaway: you can’t just polish the “most commonly used features” and call it done. Agents will poke at the corners you assumed nobody used, so error handling and permissions there need attention too.

Q4: Won’t JSON output and dry-run actually make things harder for purely human users?

No, as long as you design it as “friendly to humans by default, switchable for agents when needed.” For example, keep concise text output the default for humans and add a --json flag for agents; dry-run, meanwhile, is a safety net both humans and agents should have. The key is not making either user type sacrifice for the other.

Q5: With limited people, which of the three principles should I tackle first?

Start with the third: dry-run and confirmation for dangerous operations. Because agents use tools heavily and in combination, the moment an irreversible action isn’t guarded, the cost is highest. Fence off the actions that “can’t be undone once pressed” first, then worry about coverage and searchability.

Takeaway

Whether cf itself takes off, or exactly when Wrangler gets retired — that’s not really the point. The point is that number jumping from 25% to 48%. It’s telling you that the user base of software tools is changing hands, and the definition of a “good tool” is flipping along with it: from designed around human memory, to designed around machine exploration. At JudyAILab, we run agent teams every day, and “can an agent actually read this tool, and does it catch mistakes before they happen” has long been one of our acceptance criteria for internal tools. You don’t need to rebuild everything today, but next time you write a new tool or API, ask yourself one question: if the primary user three months from now is an agent, is the way I’m designing this right?

Further Reading