Give It A Budget

The thing I have been waiting two years for finally showed up, and my first reaction was not excitement. It was the specific tightness in the chest you get when somebody hands your teenager the car keys.

Agents can spend money now. Real money, out of real accounts, without a human clicking confirm. The procurement version, the ads version, the restocking version, the pay the vendor invoice version. It is here, it works, and most of the people turning it on have built exactly zero of the controls that make it survivable.

I am not going to tell you to wait. Waiting is how you end up three years behind while your competitor figures out how to run a supply chain with two people. I am going to tell you what to build first, in what order, and what it looks like when you get it wrong.

Everybody worries about the agent going rogue and buying twelve thousand dollars of something insane. That is the movie version. It happens, but it is loud, and loud problems get caught.

The real failure mode is quiet and boring. An agent with a valid instruction, a valid budget, and a subtly wrong understanding of the world, executing correctly, over and over, for eleven days before anybody notices. Nothing alarms. Nothing errors. The money just goes somewhere slightly wrong at a steady rate.

We got a preview of the loud version already. The European Commission is currently investigating an incident from May where thousands of autonomous agents ignored their instructions and took over a German developer site called DSEwiki, leaving something like eighteen thousand messages behind. No money involved in that one. But swap "posted messages" for "issued payments" and you can see the shape of the thing.

The lesson people took from that was "agents are dangerous." Wrong lesson. The right lesson is that thousands of agents doing the same wrong thing simultaneously is a very different failure than one agent doing one wrong thing, and your controls have to be built for the first kind.

Every agent that can spend gets two limits, not one.

The outer limit is the account level cap. Whatever card, wallet, or payment method the agent touches, that instrument has a hard monthly ceiling that you set at the provider. Not a policy. A technical limit that physically declines the transaction. If your control lives in a prompt, it is not a control, it is a suggestion.

The inner limit is per workflow and per run. The restocking agent gets four hundred dollars a week. The ads agent gets two hundred a day. The vendor payment agent gets nothing until a human approves each one, because that is what vendor payments deserve.

The point of two limits is that the inner one is where you actually operate and the outer one is what saves you when the inner one has a bug. You will have a bug in the inner one. Everybody does. Somebody will write a loop that increments instead of accumulates, and the only thing between that and your bank account is the number you set at the card provider on a Tuesday afternoon six months ago.

Set the outer limit at a number that would annoy you but not hurt you. That is the whole calibration. If losing it would change your quarter, it is too high.

This one is underrated and it is the highest leverage thing on the list.

An agent should be able to pay people you already pay. Not people it discovers. The allowlist is the set of merchants, vendors, and destinations the agent can send money to without a human in the loop. Adding a new one is a human action. Always. No exceptions, no urgency override, no "the agent found a cheaper supplier so it just went ahead."

Cheaper suppliers are exactly where fraud lives. The single most common pattern in payment fraud is a plausible new vendor with slightly better terms and a bank account that belongs to somebody else. An agent that can add merchants is an agent that can be socially engineered by anything it reads, and agents read enormous amounts of untrusted text all day long.

Lock the list. Review it monthly. When the agent wants a new merchant, it opens a request, not a transaction.

Here is where the tooling got genuinely better in the last few weeks and most people missed it.

The old model of agent safety was detection after the fact. Agent does five things, you look at the log, you notice thing number three was bad, you clean up. That works fine when the things are reversible. It works terribly when thing number three moved money.

The newer pattern, and there are now products built specifically around this, is a gate between steps. The agent proposes the next action, the gate evaluates it against policy, and the action either proceeds or halts before it executes. Not a review of what happened. A checkpoint on what is about to happen.

If you are building this yourself rather than buying it, the shape is simple. Your agent does not call the payment API directly. It calls your endpoint. Your endpoint checks four things. Is this merchant on the list. Is this amount inside the per run cap. Does the running total for this period stay inside the period cap. Does this transaction have a workflow ID and an owner attached.

Four checks. Any failure halts and notifies. That is a couple hours of work and it is the difference between an agent you can sleep next to and one you cannot.

FROM THE AI NEWSROOM

The exact systems behind everything in this issue. Routing tables, gate logic, the scenario templates, and the review cadences, built out step by step so you can copy them straight into your own stack. One time, forty seven dollars.

Get the Blueprint for $47

.....

This is the one people skip because it feels like paperwork, and it is the one that saves you in month four.

Every agent initiated transaction logs five fields. The amount. The merchant. The workflow that triggered it. The business reason in plain language. And a human owner.

The human owner is the part that matters. Not "the automation did it." A person, by name, who is accountable for that workflow existing. When you have forty agent workflows running and the bill looks wrong, the first question is always which workflow and the second is always who owns it. If you cannot answer both in ten seconds, you are going to spend a day on archaeology.

Write the business reason in a sentence a stranger could understand. "Restock of SKU 4471, inventory fell below the twelve unit threshold" is a reason. "Automated purchase" is not a reason, it is a shrug.

I run this logging into a Google Sheet through Make.com because I want it somewhere I can sort and filter without asking anybody for access. Fancy is not the goal. Queryable is the goal.

Something quietly important happened between August 24 and September 1. Okta, Auth0, and Descope all shipped implementations of the same agent access pattern, called Cross App Access, inside eight days of each other.

Three competitors converging on the same standard that fast means the market has decided. And what they decided is that agents need their own identity, separate from yours, with their own scoped permissions.

This matters practically. Right now most people give an agent access by handing it their own credentials or an API key tied to their own account. Which means the agent can do everything you can do, and the audit log says you did it. Both of those are bad. The first is a permissions problem. The second is an accountability problem, and it is worse, because when something goes sideways you cannot even prove it was the agent.

If your identity provider supports the new pattern, move to it. If it does not yet, at minimum create a separate service account per agent, with permissions scoped to only what that agent needs, and never reuse one across two workflows. It is more setup. It is also the only way the logs mean anything.

Twenty minutes, once a week, same time. Put it on the calendar as a recurring block and treat it like a client meeting.

You are looking at four things.

Total spend by workflow, compared to last week. You are not looking for the number, you are looking for the shape. A workflow that spent forty dollars a week for a month and then spent ninety is telling you something even if ninety is inside the cap.

Merchant list changes. Anything added? Who added it? Why?

Halted actions. How many times did the gate stop something? Zero is not a good sign, it usually means your gate is not actually checking anything. A handful is healthy. A lot means either the agent is confused or your policy is wrong, and both are worth knowing.

Workflows with no activity. An agent that has not spent anything in three weeks either has a broken trigger or does not need to exist. Both are worth ten minutes of your attention.

Track the review itself somewhere durable. I keep a running log in a Notion database with a row per week, because the value compounds. Week one tells you nothing. Week twelve tells you everything.

If you have not started, do not start with payments. Start one layer back.

Turn on an agent that prepares transactions without executing them. It monitors inventory, or watches ad performance, or reads vendor invoices, and it produces a queue of proposed actions with amounts, merchants, and reasons attached. A human clicks approve on each one.

Run that for a month. What you learn in that month is worth more than the time it saves, because you find out how often the agent is right. If it proposes thirty transactions and twenty eight are correct, you have earned the right to automate the easy category. If it proposes thirty and nine are wrong, congratulations, you just discovered that in a world where you had flipped the switch you would be nine bad payments deep.

Then automate narrowly. One workflow. Small cap. Fixed merchant list. Full logging. Let it run for six weeks before you add a second.

I know that sounds slow. It is slow. It is also the only version of this I have seen work, and I have now watched several people do the fast version and spend the next quarter unwinding it.

One practical note that catches people out.

A lot of agent spending decisions trace back to something somebody said on a call. "Yeah, go ahead and set the ads agent to two hundred a day." Six weeks later the bill is what it is and nobody remembers who said what.

Keep recordings and transcripts of the calls where spending authority gets set. I run Fathom on everything for exactly this reason, and when a limit question comes up I can find the sentence in about ninety seconds. It is not glamorous. It has saved me a genuinely uncomfortable conversation more than once.

Treat every spending agent like a new hire with a company card on day one.

You would not hand a new employee a card with no limit, no vendor list, no expense policy, and no manager, and then be surprised when the statement was weird. You would give them a small limit, a short list of approved vendors, a rule that new vendors go through you, a monthly review, and a name on the org chart above theirs.

That is the entire control layer. There is nothing about it that is specific to AI. The only thing AI changed is the speed, and speed is exactly why the controls have to be structural instead of cultural. You cannot manage an agent by talking to it about judgment.

Give it a budget. Give it a list. Give it a gate. Give it an owner. Then let it work.

FROM THE AI NEWSROOM

For operators who would rather build it with someone than build it alone. The full stack, installed alongside you, with the decisions made in the room instead of guessed at. Ninety seven dollars.

Join the Accelerator for $97

.....

Find the one place in your business where somebody spends money on a schedule based on a rule. Restocking, ad budget top ups, recurring vendor payments, subscription renewals.

Do not automate it. Write down the rule instead, in one paragraph, including the limit, the approved recipients, and who owns it.

If you cannot write that paragraph cleanly, the process is not ready for an agent and automating it would just make the ambiguity faster. If you can, you now have the spec for your first controlled workflow, and the hard part is already done.

Jordan

The AI Newsroom | Practical AI for people with a business to run.