There's a number going around dev.to this week. Gartner says 40% of enterprise apps will ship a task-specific AI agent by the end of 2026. Last year it was under 5%.
Every deck quotes it. Every thread argues about it. Fine.
I run engineering at a UK payments company. We're FCA-authorised, SOC2, the whole regulated stack. On the side I build an open-source agent framework called Bodhiorchard, where a dozen agents do real work on a real codebase. So I've shipped the thing the slide is describing. And I can tell you the 40% isn't the hard part.
The hard part is everything under the slide. And the biggest piece of it is money.
The demo is not the deployment
An agent demo is easy. You give it a prompt, it writes some code or drafts a report, everyone claps.
Then you try to put it near a live system and the questions start. What can this thing actually call? What happens when it's confidently wrong? Who gets paged?
None of that shows up in a projection. All of it shows up in production.
The real boundary isn't "no money." It's a signed mandate.
The reflex guardrail is to forbid the scary thing. Don't let the agent move money. Read-only, propose-only, a human clicks the button.
That reflex is already history. Agents are going to move money, because paying is half of what it means to finish a task. An agent that can research a supplier, compare options and fill a cart, then stops and waits for a human to tap "confirm," isn't an agent. It's an intern with a shopping list.
This is the part of the 40% that actually rewires the economy. Not agents writing code. Agents that transact. The moment an agent can pay, it stops being an assistant and becomes an economic actor, and the rails for that are being built right now.
That's what we're building at Atoa: a regulated bank rail for AI agents. An agent settles a payment bank to bank, over an FCA-authorised rail, with a signed record on every move. Built for the protocols this is standardising on, AP2 for mandates, x402 for pay-per-request, MCP as the interface. So "never let it touch money" was never going to be our answer. The answer is where the authority lives.
An agent's permission to spend can't be a line in a system prompt that a clever input talks its way around. It has to be a signed, scoped mandate: explicit about how much, to whom, within what limits, and verifiable on its own. Every payment gets a real-time affordability check. Every payment leaves a signed, provable record, who authorised it, what the funds check returned, where it settled.
That's the shift worth internalising. The boundary moved from "can the agent act?" to "is the agent's authority explicit, scoped, and provable?" Money moving for an autonomous agent needs more oversight, not less. So you make the authority a hard artifact and the audit trail non-optional, and then you let it pay.
Context in, not hope in
Here's a real one from Bodhiorchard.
An agent was asked to produce a payout report. Left to its own reading of the task, it started building a brand new service to generate that report. The report already existed. It was about to rebuild something we already had, in a slightly different shape, as new surface area to maintain.
The fix wasn't a smarter prompt. It was context. We feed agents structured context through MCP before they write a line, what we call a BUD in Bodhiorchard. Once the agent could see the existing report and the decisions behind it, it did the sane thing. It extended what was there instead of spawning a duplicate.
That's the difference between an agent that helps and one that quietly grows your tech debt. Not intelligence. Context.
Deterministic checks come before the probabilistic step
An agent's output is a guess. A good guess, often. Still a guess.
So the guess doesn't get to be the last word. Before anything an agent produces goes near a real code path, it runs the checks a human would have to pass. Types. Schema validation. The test suite. The design-pattern lints that encode decisions no off-the-shelf linter ships with. In the payments flow, the affordability check plays the same role: a deterministic gate the probabilistic step has to clear before anything settles.
If that deterministic layer isn't there first, you haven't deployed an agent. You've deployed a very fast intern with commit access and no code review.
Someone owns the failure
This is the part nobody wants on the slide, because it's a headcount question, not a technology one.
When an agent fails, it usually doesn't crash. It fails plausibly. The report looks right. The code compiles. The number is just wrong. That kind of failure needs a human owner who knows the domain well enough to smell it, and a record clean enough to trace it back.
My mental model: an agent is an army of near-zero-mistake juniors. That's a gift to a senior engineer and a trap for a team without one. Enabling seniors with agents is the right move. Replacing seniors with agents is how you find out what plausible failure costs.
So
Yes, 40% of apps will probably have an agent by December. The slide will be right.
But the agent isn't the work. The scoped mandate, the context feed, the deterministic gate, the human who owns the failure. That's the work. That's the 60% under the waterline.
And the biggest piece of that iceberg is payments. The agent economy doesn't start when models get smarter. It starts when agents can pay, safely, over rails that were built for them. That's not a 2030 story. It's live now, and we're building one of the rails.
If you're shipping an agent this year, which of those four do you already have, and which are you hoping the model handles for you?
Top comments (5)
The line that lands hardest for me is "where the authority lives." A permission encoded in a system prompt is just a suggestion an adversarial input can renegotiate — the whole point of a signed mandate is that the authority is checkable without trusting the agent that's holding it. That's the real reframe: stop trying to make the model well-behaved and make the rail refuse anything outside a scoped grant.
The piece I'd push on is the same one that bites human-approved flows: a mandate is signed at authorization time, but settlement happens later, and the world drifts in between (funds moved, limit already consumed by a parallel task, supplier changed). A signed record proves who authorized what, but you still need a real-time affordability + idempotency check at the moment of settlement or the signature just certifies a decision made against stale facts. Sounds like your affordability-check-per-payment does exactly that — is the mandate itself re-validated at settlement, or only the funds position? The double-spend case across two concurrent agents sharing one mandate is where I'd expect the sharp edges.
You've put your finger on the exact seam. The signature certifies intent at T0. Settlement happens at T1, and everything that matters can move in between. So we re-validate at settlement, not just the funds position. The mandate gets re-checked against current limits and current affordability, because a signature against stale facts is worse than no signature. It reads as authority. On the double-spend across two agents sharing one mandate: that's the case that actually bites. We treat the mandate as a resource with a version, and settlement takes an optimistic lock on it. Two concurrent settlements against the same version, one wins, the other retries against the new state or fails cleanly. The idempotency key is per-intent, not per-attempt, so a retry can't quietly become a second debit. The sharp edge you don't see coming is the gap between "funds reserved" and "mandate consumed" — those two have to be one atomic step, or you leak holds.
The "context in, not hope in" section is the part that stuck with me. The failure mode you describe an agent rebuilding a payout report that already existed because it never saw the decisions behind the original isn't a modeling problem, it's a memory problem. The agent had no way to know why the existing report was shaped the way it was, so it defaulted to building new surface area instead of extending what was there.
That's the piece I'd push on a bit further than the post does: the BUD you feed an agent before it writes code is only as good as what your team actually captured as a decision versus what's tribal knowledge in someone's head. Most teams don't have a system of record for the why behind a choice just the code (the what) and maybe a Slack thread that's already scrolled off. I've been working on this exact gap at Decispher (durable, queryable decision context that agents and humans both draw from before acting) precisely because "the agent guessed wrong" so often traces back to "the context it needed was never written down anywhere machine-readable."
Fully agree on the deterministic-gate point too same principle applies upstream of the gate: garbage or missing context in, plausible-looking failure out, regardless of how good your test suite is downstream.
You've named the thing that makes or breaks it. A BUD is only worth what actually got written down as a decision, and most of the "why" behind a shape lives in someone's head or a Slack thread that's already scrolled off. That's the real gap. The model was never going to infer intent nobody recorded.
The uncomfortable part I hit building this: capturing the why can't be a separate chore, or it just doesn't happen. The decision has to get written at the moment it's made, as a side effect of the work, not in a docs sprint three weeks later that everyone skips. When I lean on a BUD, the honest failure mode isn't the agent misreading it. It's that the decision was real but nobody ever turned it into a record, so there was nothing to read.
On the queryable-decision-context idea, the problem is real and it's the whole reason I bother with structured context at all. The bar I'd hold any of it to is who writes the entry, and when. If it depends on a human remembering to log the why after the fact, you're back to the Slack thread. The interesting version is the one where capture is a byproduct of shipping. How are you getting the decision in without asking people to do extra work they'll quietly stop doing?
Yes, you answered this in the Mac Mini post before I asked it. "Captured from hooks, not typed into a board" is the whole thing.
One thing I'm curious about when a BUD closes, how often does what you learned in it actually reach someone working on a different BUD months later?