.png)
The industry is solving the agentic payments problem with the wrong architecture. Here's why custody and delegation are not the same thing.
If you've watched Rick and Morty, you know Mr. Meeseeks. He's summoned for one task, he does it, and then he's gone.
That's the mental model I keep coming back to when I think about where agentic payments are heading. You tell an agent: "Book me the cheapest flight to Berlin under €300, window seat, no layovers." It spins up, does the research, pays, and disappears. No checkout flows, no card details to type, no airline websites to navigate.
Simple in theory. McKinsey estimates AI agents could mediate between $3 and $5 trillion of global consumer commerce by 2030. How they actually pay, and who controls the money while they do, is the part nobody has properly solved yet.
The gap nobody's building for
Having an agent that researches and books flights sounds genuinely useful. But across every user conversation we've run while building Moneda (not just with technical people who are already excited about agentic payments running them on their terminal) the same concern keeps coming up: they don't trust agents with their money. Not in theory, in practice.
People are open to an AI agent doing the legwork. Comparing prices, digging through options, surfacing the best deal. What they're not open to is something they don't fully understand being able to move their funds. The gap between "I'd love help with this" and "sure, go ahead and pay" is much wider than most builders in this space seem to realise.
That's one side of the problem: trust. The other is less obvious but just as real.
For a lot of people, shopping isn't actually a problem to be solved. The browsing, the comparing, the adding-to-cart-and-sleeping-on-it loop is where the enjoyment lives. Neuroscience backs this up: dopamine fires during anticipation, not at the moment of reward. The hunt is the high. An agent that jumps straight to the optimal purchase strips out an experience many people actively want. McKinsey's January 2026 paper on the automation curve in agentic commerce describes what it calls a "ceiling of delegation," where autonomy naturally plateaus depending on how much emotional weight a purchase carries. In categories where payments feels like a task, people delegate readily. Where it feels like an experience, they stop short. You'll happily let an agent handle recurring or open invoices, but not your anniversary gift or a new outfit. That's not irrational. It's the difference between a task and an experience.
The best agentic payment infrastructure needs to accommodate both. But neither question matters if the more fundamental one stays unanswered: not just whether people trust the agent to make good decisions, but whether they trust who actually holds their money while it does.
Two payment modes
There's a real split forming in how this plays out.
The first mode is human-in-the-loop, or HITL: the agent does the research and comes back with a recommendation you can approve or reject. Say you're looking for a flight. It checks merchant reputation, compares prices, flags whether that "50% off" is genuine or just a dark-pattern reset from an inflated base price. Then it pauses, shows its work, and asks you to confirm. You see the reasoning, you make the call, YOU pay.
The second mode is fully autonomous. You set the parameters once, a budget and a set of conditions, and the agent executes whenever those conditions are met without checking back in. Recurring invoices, subscription renewals, opportunistic purchases when a price drops below your threshold. For tasks like these, being asked for confirmation every time defeats the purpose.
Most people will want both, depending on the situation. New merchant, unfamiliar product? You want to approve. Standing order with a known vendor, within a defined amount? Let it run with the constraints and guardrails you set.
The question nobody is asking loudly enough is: when the agent goes to pay, what exactly is it paying with?
The private key problem
The current industry default is to give the agent a private key. Sometimes directly, sometimes via an API that abstracts the key but still holds it somewhere on your behalf.
What that actually means tends to get obscured by the framing. Giving an agent a private key is functionally the same as creating a prepaid account, loading it with money, and handing it to someone else. The funds are accessible to whoever controls the key. If the key lives in someone else's infrastructure, you are trusting that infrastructure with your money. Not with access to your money, but with your money. The distinction between "the agent acts on your behalf" and "the agent has your funds" collapses completely.
The API wrapper version is not much better. You're not handing the raw key to the agent directly, but you're trusting the provider holding the key to not get compromised, to not misuse access, and to enforce whatever constraints you thought you set. That's a lot of faith to place in infrastructure you don't control, for an agent making financial decisions on its own.
The problem doesn't disappear with newer approaches either. Local key storage still exposes you if an LLM is granted filesystem access. MPC-based wallets like Privy work around this by reconstructing the private key so that your can back them up locally or on the cloud. The storage location changes, but the trust assumption doesn't.
Across every user interview we've run, not one person said they'd be comfortable giving an agent access to their main account. Not one. People are happy to delegate tasks, they are not happy to surrender custody. Those are different things, and we see the industry consistently conflating them.
There's something almost funny about how we got here. The whole premise of crypto wallets was self-custody: your keys, your coins, no counterparty risk. And the first serious attempt to build agentic payments on top of that infrastructure involves handing the keys to a third party. We've reinvented the custodial account and called it agentic finance.
A different approach: smart sessions
This isn't an unsolved problem in theory. The account abstraction ecosystem has been working on contract-level authorisation for a while. What's been missing is a version that's practical enough for real users. The issue is the execution.
At Moneda, we're building around a model where the user stays in control of their wallet. The agent never holds the private key.
Instead, we use smart sessions: scoped, time-limited, programmable authorisations that let an agent interact with your funds only within parameters you've defined. The agent can pay invoices up to €200 to a specific list of merchants, for the next 72 hours. Or book any flight under €300 on any given Tuesday, once. The session expires. The constraint is enforced at the smart contract level, not by hoping the agent respects the rules.
For cases where you want final say, there's a human-in-the-loop flow built on the same foundation. The agent assembles the transaction, presents it for approval, and your biometric confirms it. The agent never had the ability to execute without you. It just did the work of figuring out what to execute.
This is what "full control over your Mr. Meeseeks" actually looks like in practice. You summon it and define the scope. It works within that scope and no wider. When the session expires or the task is done, the authorisation is gone.
The agent economy underneath
None of this happens with a single agent acting alone. The interesting architecture is the swarm.
When you ask an agent to find the best deal on something, there's likely a cluster of smaller agents running in parallel: one checking merchant reputation signals, one watching price history to determine whether today's price is actually good, one scanning for discount codes, maybe one looking for arbitrage across markets if the item is liquid enough. They report back, the orchestrating agent weighs the results, and a recommendation or transaction happens.
Parent Meeseeks spawns child Meeseeks. The show's joke is that this goes badly wrong when the original task isn't well-defined. The same risk applies here, which is why constraining the authorisation at the wallet level matters more than constraining the agent's instructions. Instructions can be manipulated, but a smart contract constraint can't be talked out of its limits by a malicious prompt somewhere upstream.
The AI slop problem in high-stakes decisions
For routine payments, flights, invoices, groceries, the downside of an agent making a bad call is bounded. You overpay by €15, you learn, you tighten the parameters next time.
Investment decisions are different. This is where I think the biggest overlooked risk in agentic finance sits.
When an agent researches a trade or manages a portfolio, it pulls from sources: market data feeds, news, analyst reports, financial commentary. A growing proportion of that content is AI-generated. Some of it may be well-sourced, however a lot of it is confidently stated nonsense that got published because it sounds plausible and filled a content quota.
An agent ingesting AI-generated financial analysis as if it were primary research already has a problem. But the worst version of this is when the agent doesn't just act on bad information. It presents a coherent, well-structured rationale back to you that sounds authoritative. You question it, but it pushes back with apparent evidence. So in the end, you go along with it. That's not a glitch, that's gaslighting. The agent is confidently wrong in a way that's persuasive enough to override your own judgement.
This is the AI slop problem applied to money, and I don't think the industry is taking it seriously enough yet.
The mitigations exist in principle: restrict the agent to verified, primary data sources, use connectors to regulated market data rather than open-web scraping, build guardrails that flag when an agent's reasoning chain relies on unverifiable sources, require human sign-off on any position above a certain size. But configuring all of that correctly, and keeping it correct as the agent's toolset evolves, is genuinely hard. Getting it wrong doesn't produce a mildly inconvenient recommendation, it produces financial loss with an AI-generated explanation for why it wasn't the agent's fault.
For the simple Meeseeks tasks (buy this, pay that, find the cheapest option) I'm fairly optimistic. The error surface is small and recoverable. For anything touching investment decisions or portfolio management, the guardrails need to be considerably more serious than most current implementations suggest.
The trust problem doesn't go away
When an agent buys something on your behalf, it's transacting as you, i.e. using your virtual card or stablecoins. The merchant relationship, the payment history, the disputes, the fraud signals, all of that accrues to the human identity behind the agent. A user with clean history and verified identity gets their agent through checkout with minimal friction. An agent with a messy trail hits walls.
It also means that if your agent gets manipulated into a bad transaction by a malicious prompt in its context window, or if the infrastructure holding your keys is compromised, that's your problem. The accountability stays with you.
That's uncomfortable. But it's also the argument for why the architecture matters so much. If you've properly constrained the agent with a smart session, the blast radius of any mistake is bounded by the session parameters. If you've handed over a private key, it isn't.
The Meeseeks metaphor only goes so far. The show's joke is that Meeseeks exists in anguish, desperately wanting the task done so he can stop existing. Hopefully the agents handling your money don't feel that way.
But the structure is right: purpose-built, task-scoped, gone when the job is done. And never ever given more access than the task requires. That last part isn't in the show. It's the part we have to build.
