Capability Ships First. The Controls Arrive Later.

Two announcements landed in the same window this week. AWS made agent payments generally available, so agents can now buy things on their own. Cloudflare put controls over what agents are allowed to modify into private beta. Generally available versus private beta. That ordering is not a conspiracy and it is not unusual, but it is the single most useful thing to notice about adopting AI right now.

The normal order of things

This is not an AI problem. It is what every technology cycle does.

Capability is what gets bought, so it gets built and marketed first. Controls are hard to demo, nobody puts them on a landing page, and they generally arrive after enough customers have had a bad enough experience to make them a purchasing requirement. Email had attachments long before it had decent filtering. Cloud storage had sharing long before it had sane permissions. Phones went into workplaces years before anyone could manage them properly.

Reading it as a pattern rather than an outrage is what lets you plan. Vendors are responding to what customers pay for, and right now customers are paying for capability.

Read and write are different decisions

The Cloudflare piece points at something worth separating out, because most setups collapse it into one choice.

Those are three different risks with three different recovery costs, and a lot of integrations hand over all three at once because that is the default and it is faster to set up. Granting read without write, where the tool allows it, is one of the cheapest risk reductions available.

If you adopt early, you are the control layer

This is the practical consequence. Adopt something before its governance features exist and the governance is whatever you build around it.

That is workable and it is not exotic. A separate account with the shortest useful permission list. A hard spending cap set at the payment method, not inside the tool. A log you look at weekly rather than one that exists in case of an audit. We set the fuller version out in the three boxes to put an agent in, and on the money side specifically, turning on the spend controls that already exist takes an afternoon.

What does not work is assuming the product handles it because it would be odd if it did not.

Waiting is a real option

There is a reflex in this market that waiting means falling behind. Sometimes. Often it just means letting other people find the failure modes.

The question to ask is whether a given capability is a convenience or a genuine advantage for your business. If an agent paying for API calls on its own saves your team a bit of friction, waiting two quarters for the controls to mature costs you very little. If it unlocks something your competitors cannot do, adopt it, but adopt it narrowly and with your own limits around it.

The expensive middle path is adopting broadly while assuming somebody else is handling the safety, which is how businesses end up unable to say what their agents have actually been doing.

The question worth asking every vendor

What can this not do, and how do I make that list shorter?

A serious vendor answers directly. They will tell you which limits exist now, which are coming, and which are not planned. A weaker one redirects to what the product can do, which is itself an answer. Push for specifics: can I cap spending, restrict which systems it touches, make it read-only, and see everything it did afterwards. Four questions, one minute, and if the answers are vague you have learned that the control layer is yours to build. Better to know that before you turn it on than after.

Frequently Asked Questions