For the last two years, the question business leaders asked about AI agents was simple: what can it do? Watch the demo, marvel at the multi-step task, sign the pilot budget. That question is no longer enough. As agents move from chat windows into systems that browse, click, spend money, and run unattended for hours, the real question has shifted to where and how. This week's product news from Cloudflare, Google, and Amazon shows three different vendors converging on the same problem: agents need infrastructure, not just intelligence. If you're evaluating agent tools for your organization, the buying decision now looks a lot more like choosing cloud infrastructure than choosing software.
The Demo Phase Is Ending
A year ago, most agent products were judged on capability alone: could it write the code, book the flight, draft the report. Capability still matters, but it's table stakes. What separates a usable production agent from an expensive proof of concept is everything underneath the capability: what environment it runs in, what it's allowed to touch, how long its work persists, who's watching it, and what happens when it fails.
Cloudflare's August 6 announcement of Kitesurf, a browser built specifically for agents, is a clear signal of this shift. Cloudflare's argument is straightforward: Chromium was built for humans, and agents often don't need a full human-grade browser to take a screenshot or pull text off a page. Kitesurf runs inside V8 isolates on Cloudflare Workers, using Rust and Wasm alongside Durable Objects and sandboxed outbound workers, aiming to be lighter and more contained than a full browser instance. Whether or not you ever touch Kitesurf directly, the underlying point applies broadly: someone has to decide what environment an agent's actions run in, and that decision has real cost and security consequences.
Runtime and Access Are Now Buying Criteria
Ask a vendor "what can your agent do" and you'll get an impressive answer. Ask "where does it run, and what can it reach" and you'll learn a lot more about whether it's ready for your business.
Google's July update to Gemini's Managed Agents, which we covered in detail separately, points at the same shift from a different angle. Instead of a purpose-built browser, Google is adding environment hooks, scheduled triggers, and an Environments API for managing sandboxes, alongside budget controls that cap what an agent can spend. That's a vendor telling you, implicitly, that customers were already asking: what happens if this thing runs longer than expected, hits an API it shouldn't, or racks up a bill nobody approved.
Amazon appears to be circling the same territory. A recent AWS Bedrock post referenced "runtime instances" for persistent compute on AgentCore, aimed at production agents. We couldn't fully verify the details of that specific post during this review, so treat it as an early signal rather than a settled fact. But the direction lines up with what Cloudflare and Google are building: persistent, governed compute purpose-built for agents that stay running rather than agents that answer once and disappear.
Persistence and Permissions Change the Risk Profile
An agent that answers a question in a chat window and forgets everything afterward carries a certain kind of risk: mostly about the answer being wrong. An agent that persists across sessions, holds credentials, and keeps working in the background carries a different kind of risk entirely. It can act on stale information. It can retain access longer than it should. It can be the entry point for a mistake that compounds over hours instead of seconds.
That's why the infrastructure questions matter more than the intelligence questions once an agent moves past a single reply. Where does its memory live? Who can see what it did last week? If a permission was granted for one task, does it expire when that task ends? These aren't hypothetical governance concerns. They're the same questions any organization already asks about a new employee's system access, applied to software that now works unsupervised.
Observability and Cost Control Are the New Uptime
For traditional software, uptime and latency were the metrics that mattered to IT. For agents, the equivalent metrics are observability and cost control: can you see what the agent did, and can you cap what it's allowed to spend doing it.
Budget controls, in particular, are becoming a standard feature rather than a nice-to-have, precisely because agents can take far more actions per dollar than a human operator, and each of those actions can carry its own compute or API cost. An agent that loops on a task, calls a tool repeatedly, or spins up browser sessions in a retry cycle can burn through a budget quickly if nothing is capping it. Vendors adding scheduled triggers and spend limits aren't adding a luxury feature. They're patching a gap that showed up the moment agents started running without a human watching every step.
The Decision Rule Worth Remembering
Here's a simple rule for any team evaluating an agent tool: if the agent can act outside the chat window, meaning it can browse, call APIs, spend money, or persist across sessions, the infrastructure questions come before the rollout, not after. If it only answers questions inside a conversation, the bar is lower. The moment it can click, buy, schedule, or remember, you're no longer evaluating a chatbot. You're evaluating a piece of production infrastructure, and it deserves the same scrutiny you'd give any other system with access to your data and your accounts.
If this post has you thinking beyond agent demos and into the systems around them, IBM RAG and Agentic AI Professional Certificate is a practical next step. It covers RAG, agentic workflows, and the technical foundations behind agents that need tools, context, and governance around the model.*
Closing Takeaway
Model quality still matters, but it no longer decides whether an agent is safe to deploy. Infrastructure does. Before adopting or expanding agent use in your organization, run through these checks:
- Ask where it runs. Sandboxed, isolated environment, or something closer to a full unrestricted browser or shell? The answer changes both cost and risk.
- Ask what it can access and for how long. Confirm permissions are scoped to the task and expire when the task ends, not left standing indefinitely.
- Ask how spend is capped. Look for budget limits, rate limits, or spend alerts built into the product, not bolted on by your finance team after the fact.
- Ask what happens on failure. A well-built agent fails gracefully and logs what it did. A poorly built one keeps trying, silently, until someone notices the bill or the mess.
Treat these as pilot criteria, not post-incident cleanup. The vendors are already building for this world. Your evaluation process should catch up.
Sources
- Cloudflare, "Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers," Aug. 6, 2026
- Google, "Google AI updates, July 2026"
- The AI Navigator, "Google's Gemini Managed Agents just got more governable"