O Agente de IA Gemini Spark Precisa de uma Carteira, Não de um Cartão
Google announced Gemini Spark on May 19, 2026: a 24/7 agentic assistant that reads your Gmail, drafts replies, books things, and keeps working after you close the laptop. The pitch is an always-on agentic assistant that handles the boring half of your inbox while you sleep.
Buried under the Gmail demos is a problem nobody on stage wanted to say out loud. The moment an agent acts without you sitting there, every assumption baked into card payments falls apart. No human to tap "approve." No phone to receive the 3-D Secure code. No card present, no cardholder present, no session.
I think this is the real story of the Gemini 3.5 launch, and it has almost nothing to do with email.
Why an always-on agentic assistant can't use your card
Card rails assume a person. The whole anti-fraud stack, CVV, 3-D Secure, the little SMS code, the velocity checks, exists to confirm a human is behind the transaction. Spark is the opposite of that. It's a process in Google's cloud that wakes up at 3am to rebook a cancelled flight.
Run an autonomous agent against Visa's rails and you hit a wall fast:
- Card-not-present transactions from a datacenter IP get flagged or declined.
- 3-D Secure challenges go to a human who is asleep.
- Chargeback liability lands on the merchant for a purchase no human authorized.
- There's no clean way to give an agent a $40 spending cap that resets daily and can't be drained.
Google's own AI Ultra positioning leans on subscription bundling precisely because per-action payments are unsolved. You pay Google a flat monthly fee, Google eats the agent's costs, and nobody has to figure out how the agent pays a third party. That works until the agent needs to buy something outside Google's walled garden.
The demand side finally showed up
For two years the agent-payments crowd built rails for a customer that didn't exist. I wrote about this gap in AI Agent Payments: Anvita, x402, and Who Owns the Rail, the tech was ready, the autonomous spenders weren't.
Spark changes the math. Google is about to ship tens of millions of always-on agents that will, eventually, need to transact. That's the demand the rails were waiting for.
The stack that's emerged is boring in the right way:
- x402 revives the dormant HTTP 402 "Payment Required" status code so a server can quote a price and an agent can pay it inline, in stablecoins, over a single request.
- AWS AgentCore added a payments path so agents running in Amazon's cloud can settle without a human approving each charge.
- Pay.sh and similar tools wrap USDC-on-Base into something an agent can call like any other API.
The common thread: USDC on Base. Cheap finality, sub-cent fees, and a stablecoin that a corporate treasury can actually hold without a compliance team filing a restraining order.
Why USDC on Base, specifically
Agent payments are micropayments. An agent might pay $0.003 to query a weather API or $2 to buy a data set. Ethereum mainnet gas would dwarf the payment itself. Base settled over $1B in daily DEX volume this cycle, and its fees sit in fractions of a cent, which is the only fee regime where machine-speed micropayments make sense.
Stablecoins matter more than the chain. An agent can't hold a volatile asset; a 4% price swing between authorizing and settling a payment is a non-starter. USDC is dollar-denominated, redeemable, and issued by a regulated entity. After the GENIUS Act AML rulemaking pulled stablecoin issuers into a bank-like supervision regime, a CFO can sign off on holding USDC in a way they never could with an unbacked token.
That regulatory clarity is the unlock, not the throughput. I've watched institutional deals die over exactly this question: "who's liable, and is the issuer supervised."
The hard part isn't payments. It's authority
Giving an agent a wallet is the easy 20%. The other 80% is governance:
- Spending limits that hold. An agent wallet needs a hard cap enforced on-chain, not a soft limit in application code that a prompt injection can talk its way past.
- Revocable delegation. You authorize the agent for grocery reorders, not for moving your savings. That scoping has to be cryptographic, not a checkbox.
- Auditability. Every agent payment needs to be attributable to a policy a human set. "The AI decided to" is not an answer a regulator accepts.
This is where the prompt-injection risk gets real. We've already seen what a single leaked key does, see the Polymarket exploit. Now imagine that key sits in an agent that reads untrusted email all day and can spend money. The attack surface is the entire inbox.
What I'd watch next
Google won't put USDC in Spark this year. The first version will route everything through Google Pay and Google's own billing, because that's controllable and because Google would rather own the rail than rent it.
But the agent that books your flight at 3am will eventually want to pay a vendor Google doesn't have a billing relationship with. When that happens, the cheapest path is a stablecoin payment over an open protocol, not a bespoke card integration per merchant. The rail that wins is the one an agent can call without asking permission from a payments giant.
The wallet is coming for the agent. The only open question is whether it's a closed ledger inside Google or an open one anybody can build against. My bet is on open, for the same reason the web beat AOL.