Gemini Spark AI Agent heeft een wallet nodig, geen kaart
Google heeft Gemini Spark aangekondigd op 19 mei 2026: een 24/7 agentische assistent die je Gmail leest, reacties opstelt, dingen boekt, en doorgaat met werken nadat je de laptop hebt dichtgeklapt. Het idee is een altijd-actieve agentische assistent die de saaie helft van je inbox afhandelt terwijl jij slaapt.
Verborgen onder de Gmail-demo's ligt een probleem dat niemand op het podium hardop wilde zeggen. Op het moment dat een agent handelt zonder dat jij erbij zit, vallen alle aannames waarop kaartbetalingen zijn gebouwd uit elkaar. Geen mens om op "goedkeuren" te tikken. Geen telefoon voor de 3-D Secure-code. Geen kaart aanwezig, geen kaarthouder aanwezig, geen sessie.
Dit is wat mij betreft het echte verhaal van de Gemini 3.5-lancering, en het heeft bijna niets met e-mail te maken.
Waarom een altijd-actieve agentische assistent jouw kaart niet kan gebruiken
Kaartnetwerken gaan uit van een persoon. De hele antifraudestack, CVV, 3-D Secure, het sms-code-berichtje, de snelheidscontroles, bestaat om te bevestigen dat er een mens achter de transactie zit. Spark is precies het tegenovergestelde. Het is een proces in Google's cloud dat om 3 uur 's nachts wakker wordt om een geannuleerde vlucht opnieuw te boeken.
Laat een autonome agent los op Visa's rails en je loopt al snel tegen een muur aan:
- Kaart-niet-aanwezig-transacties vanaf een datacenter-IP worden gemarkeerd of geweigerd.
- 3-D Secure-uitdagingen gaan naar een mens die ligt te slapen.
- De aansprakelijkheid voor chargebacks valt op de merchant voor een aankoop die geen mens heeft goedgekeurd.
- Er is geen nette manier om een agent een bestedingslimiet van 40 dollar te geven die dagelijks reset en niet leeg kan worden getrokken.
Google's eigen AI Ultra-positionering leunt precies om die reden op abonnementsbundeling, omdat per-actie-betalingen nog onopgelost zijn. Je betaalt Google een vast maandbedrag, Google absorbeert de kosten van de agent, en niemand hoeft uit te zoeken hoe de agent iets betaalt buiten Google's ommuurde tuin. Dat werkt totdat de agent iets buiten dat ecosysteem moet kopen.
De vraagkant is er eindelijk
Twee jaar lang bouwde de agent-payments gemeenschap rails voor een klant die niet bestond. Ik schreef over deze kloof in AI Agent Payments: Anvita, x402, and Who Owns the Rail, de technologie was klaar, de autonome betalers nog niet.
Spark verandert de berekening. Google staat op het punt tientallen miljoenen altijd-actieve agents te lanceren die, uiteindelijk, transacties moeten kunnen uitvoeren. Dat is de vraag waar de rails op wachtten.
De stack die is ontstaan is saai op de goede manier:
- x402 herleeft de slapende HTTP 402 "Payment Required"-statuscode zodat een server een prijs kan opgeven en een agent die inline kan betalen, in stablecoins, binnen één request.
- AWS AgentCore heeft een betalingspad toegevoegd zodat agents die in Amazon's cloud draaien kunnen afrekenen zonder dat een mens elke betaling hoeft goed te keuren.
- Pay.sh en vergelijkbare tools wikkelen USDC-op-Base in iets wat een agent kan aanroepen als elke andere API.
De rode draad: USDC op Base. Goedkope finaliteit, fracties van een cent aan kosten, en een stablecoin die een bedrijfskas daadwerkelijk kan aanhouden zonder dat de compliance-afdeling een kort geding aanspant.
Waarom USDC op Base, specifiek
Agentbetalingen zijn microbetalingen. Een agent betaalt misschien $0,003 om een weer-API te raadplegen of $2 voor een dataset. Ethereum mainnet-gas zou de betaling zelf overschaduwen. Base verwerkte dit cycle meer dan $1 miljard aan dagelijks DEX-volume, en de kosten liggen in fracties van een cent, het enige kostenregime waarin microbetalingen op machinesnelheid zinvol zijn.
Stablecoins zijn belangrijker dan de keten. Een agent kan geen volatiel actief aanhouden; een koersschommeling van 4% tussen het autoriseren en afrekenen van een betaling is onwerkbaar. USDC is dollar-gedenomineerd, inwisselbaar en uitgegeven door een gereguleerde partij. Nadat de GENIUS Act AML-regelgeving stablecoin-uitgevers onder een bankachtig toezichtregime heeft gebracht, kan een CFO USDC op de balans zetten op een manier die met een ongedekt token nooit mogelijk was.
Die regelgevingszekerheid is de sleutel, niet de doorvoercapaciteit. Ik heb institutionele deals zien mislukken op precies deze vraag: "wie is aansprakelijk, en staat de uitgevende instelling onder toezicht."
Het moeilijke deel zijn niet de betalingen. Het is de zeggenschap
Een agent een portemonnee geven is de makkelijke 20%. De overige 80% is governance:
- Bestedingslimieten die standhouden. Een agentportemonnee heeft een harde grens nodig die on-chain wordt afgedwongen, niet een zachte limiet in applicatiecode die een prompt-injectie kan omzeilen.
- Herroepbare delegatie. Je machtigt de agent voor het herbestellen van boodschappen, niet voor het verplaatsen van je spaargeld. Die afbakening moet cryptografisch zijn, niet een selectievakje.
- Controleerbaarheid. Elke agentbetaling moet herleidbaar zijn tot een beleid dat een mens heeft vastgesteld. "De AI heeft het zo besloten" is geen antwoord dat een toezichthouder accepteert.
Hier wordt het risico van prompt-injectie concreet. We hebben al gezien wat één gelekt sleutel doet, zie de Polymarket-exploit. Stel je nu voor dat die sleutel zit in een agent die de hele dag onvertrouwde e-mail leest en geld kan uitgeven. Het aanvalsoppervlak is de gehele inbox.
Wat ik als volgende in de gaten zou houden
Google stopt dit jaar geen USDC in Spark. De eerste versie zal alles via Google Pay en Google's eigen facturering laten lopen, omdat dat beheersbaar is en omdat Google liever de infrastructuur bezit dan huurt.
Maar de agent die om 3 uur 's nachts je vlucht boekt, wil uiteindelijk betalen aan een leverancier waarmee Google geen factureringsrelatie heeft. Wanneer dat moment komt, is de goedkoopste route een stablecoin-betaling via een open protocol, niet een op maat gemaakte kaartintegratie per handelaar. De infrastructuur die wint is die welke een agent kan aanroepen zonder toestemming te vragen aan een betalingsgigant.
De portemonnee komt eraan voor de agent. De enige open vraag is of het een gesloten grootboek binnen Google wordt of een open grootboek waar iedereen op kan bouwen. Mijn gok is op open, om dezelfde reden dat het web AOL versloeg.