Build is the right answer under four conditions, and they're specific enough to check in an afternoon: agent spend confined to one runtime, endpoints you can name in advance, a volume where one person still reads every purchase, and an issuing setup you already run for another reason. Meet all four and a budget check in your own code will hold.
None of this argues you should buy on day one. It argues you should know which side of the line you're on, and put a date on checking again.
When is building the right answer?
Build when your agent spend is confined to one runtime, when the endpoints are ones you can name in advance, when the volume is low enough that a person reviews every purchase, or when you already run a card-issuing programme for another reason. Any one of those is a strong case. All four together and buying is paying someone to hold what you're already holding.
The unusual-requirement case is the one people underrate. If your approval path routes through a system nobody else integrates with, a product built for the common shape will fight you every time you change something.
What makes the answer flip to buy?
Four things push it: merchants your agents pick at runtime instead of from a list you wrote, an agent count past what one person can review each week, a spending record that has to hold up in front of someone outside engineering, and policy that changes on a budget cycle rather than a release cycle. Any two together and the build keeps growing after you thought it was done.
The merchant point breaks per-endpoint designs first. A control wired to the endpoints you predicted covers exactly those, and the purchase that costs you is at a merchant you'd never have listed. Authorization-time control versus reconciliation covers what changes when the check lands after the statement.
The record point arrives on someone else's schedule. A log your agent's service account can write to answers what your systems stored, which is a weaker claim than what happened.
Which criteria decide it?
Seven criteria carry the decision, and they fall into two groups. Five describe the shape of your agent spend: where it goes, how many agents make it, how often the policy changes, how unusual your requirement is, and whether you already run a card programme. Two describe who has to live with the result: who reads the spending record, and what the choice does to your PCI scope.
| Criterion | Points to build | Points to buy |
|---|---|---|
| Where agents spend | one runtime, a merchant list you can write on a page | merchants the agent finds on its own |
| How many agents | few enough that a person reviews every purchase | more than one person can read each week |
| Who reads the record | your own engineers | an auditor, an insurer, a customer's security team, your board |
| Card issuing | you already run a programme for another reason | you don't, and payments isn't your product |
| Policy change rate | limits move with a release | limits move with a budget |
| Requirement shape | unusual enough that no product covers it | amounts, categories, time windows, approvals |
| PCI scope | you're already in scope and staffed for it | new scope landing on a team that builds agents |
Score it honestly. Teams that come out split usually describe where they are now and where they'll be in two quarters.
What do you own if you build?
You own the policy store, the approval path, the spending record and its retention, the revocation runbook, and whoever gets paged when a payment control fails at 2am. None of that is the agent you set out to ship. The work continues after launch too: merchant data changes, cards expire, and a retired agent's access has to go with it.
PCI scope catches teams out. Handling card data inside your own systems rather than behind an issuer's boundary pulls new scope onto a team whose job is agents. What PCI DSS scope means for AI agent payments shows where that boundary sits.
Shatale ships the four pieces this decision circles: agent-scoped virtual cards, your policy enforced at the authorization moment, human approval workflows above the thresholds you set, and an immutable per-agent record of every decision. A purchase outside policy is blocked or escalated for approval while the merchant is still waiting. If you'd build all four anyway, the question is whether that's the best use of your next quarter.
When should you revisit this?
Put a date on it, because the answer expires. What's right at three agents in one runtime stops being right somewhere on the way to thirty, and nobody notices the crossing. Re-run the criteria when your agent count doubles, when an agent starts choosing its own merchants, when a policy change gets stuck behind a release, or when someone outside your team asks for the record.
It runs the other way too. Teams that bought early on a growth forecast sometimes stay at four agents and one vendor, and the honest move is to say so at renewal.
What to ask
- If we build this ourselves, which parts of your product are we rebuilding, and which would we still need from someone else?
- Where does our spending policy live, and can we change a limit without shipping code?
- At what point in the transaction is the policy evaluated, and is a purchase outside it blocked, escalated to a person, or logged for us later?
- What does buying from you do to our PCI scope compared with issuing ourselves?
- If we leave in a year, what comes with us, and in what format is the record handed back?
FAQ
Should I build or buy AI agent spend controls?
Build when your agent spend is confined to one runtime and goes to endpoints you can name in advance, at a volume one person can review. Buy when agents pick merchants at runtime, when there are more agents than one person can read each week, when the record has to satisfy someone outside engineering, or when limits have to change without a deploy.
What does it cost to build agent spend controls in-house?
Count the work you own rather than a licence line. You own the policy store, the approval path, the record and its retention, the revocation runbook, and whatever PCI scope you pull toward the team. Then add maintenance: merchant data changes, cards expire, and a retired agent's spending access has to go with it. That total grows with your agent count.
When is building the right choice?
When one of four things is true: your agent spend stays inside one runtime and a set of endpoints you control, your volume is low enough that a person reviews every purchase, you already run a card-issuing programme for another reason, or your requirement is unusual enough that no product covers it. Bending a product around a constraint it was never built for costs more than writing to the constraint.
Does buying mean giving up control over policy?
No. Limits, merchant categories, time windows and approval thresholds stay yours to set and change. What you hand over is the machinery that enforces them at the authorization moment and keeps the record afterwards. Ask any vendor where the policy lives and whether you can change a limit without a deploy. If the answer routes through their support team, you're evaluating a different product than the one you thought.
If your build case rests on a shared corporate card your agents already use, moving that to scoped delegation is the first thing to price. Early access is free for publishers.
Shatale is the control layer for AI-agent payments. Its authorization architecture is the subject of European patent application EP26194994.5 (filed; priority 28 July 2026).