Een agent vindt je product, maar kan niet afrekenen

Een agent kan je productfeed perfect lezen en toch bij je betaalformulier stranden. Ik vind een webshop pas agentklaar als iedere keuze, foutmelding en bevestiging in de checkout herkenbaar is voor software die de pagina bedient. Vindbaarheid zonder bedienbaarheid is een etalage achter glas.

Een gebeurtenis is nog geen aankoop

Op 4 november kondigde Microsoft Clarity taaktests aan waarmee een winkel kan nagaan of ondersteunde browseragents een taak voltooien, hoelang die duurt, hoeveel interacties die vraagt en waar de route stokt. Dat is nuttige informatie. Een team kan hiermee een agent de winkelroute laten proberen voordat een echte klant op die hobbel botst.

De cijfers die Clarity daarvoor publiceerde vragen wel om een precieze lezing. In een analyse van 5,23 miljoen agentisch geclassificeerde sessies op 230.511 projecten, gemeten van 13 augustus tot en met 9 september 2026, bevatte 25,21 procent, of 306.621 sessies, een checkout-gebeurtenis. De dataset bevat sessies van agents uit de ecosystemen van OpenAI, Google en Anthropic, maar Clarity kan een overdracht van agent naar mens niet uit de sessie halen. De gebeurtenissen zijn losse aantallen over verschillende websites en sectoren, geen opeenvolgende stappen in één verkooptrechter.

Daarom is de checkout-gebeurtenis een signaal van activiteit, geen bevestigde bestelling. Een sessie kan tot checkout reiken en daar alsnog stoppen, of de koper kan het overnemen. Microsoft zegt zelf dat de meting geen autonome taakvoltooiing bewijst. Een gebeurtenis met de naam Checkout is dus geen kassabon.

Dat onderscheid is belangrijk voor teams die over een agentkanaal willen rapporteren. Als een dashboard een checkout-gebeurtenis laat zien, weet je dat een bepaalde regel in de site of meetcode is geraakt. Je weet daarmee niet of de agent een bezorgoptie begreep, een fout herstelde, toestemming kreeg, een betaling afrondde of een orderrecord ontstond.

Clarity’s taaktest geeft een tweede soort bewijs: kon een gesimuleerde agent de beschreven taak uitvoeren? Ook dat is nog geen gerealiseerde verkoop. Een geslaagde simulatie zegt dat de taak onder de testvoorwaarden slaagde; het orderrecord blijft nodig om te zien of de winkel een bestelling heeft vastgelegd en of de betaling de juiste status bereikte.

Stopt de test, dan is dat een aanleiding om de route te bekijken, geen volledige verklaring op zichzelf. Taakgedrag en orderadministratie beantwoorden verschillende vragen.

Vindbaarheid houdt op bij de bediening

Ik zie in discussies over agentgereedheid vaak één grote sprong: van productinformatie naar aankoop. Die twee horen bij elkaar, maar ze zijn niet dezelfde technische laag. De productfeed, betaalroute en gestructureerde gegevens zorgen dat een agent weet wat je verkoopt en hoe een transactie kan lopen. De productkeuze zelf begint bij machineleesbare prijs-, voorraad- en retourgegevens. Zodra de agent de browsercheckout bedient, moet hij ook kunnen onderscheiden wat een knop doet en wat er na een invoer verandert.

Chrome for Developers beschrijft waarom die overgang telt. De browser bouwt uit de pagina een toegankelijkheidsboom: een gestructureerde weergave van elementen, hun rollen en namen. Chrome zegt dat agents interactieve elementen in die boom herkennen. In de experimentele Lighthouse-categorie voor agentisch browsen behandelt Chrome de boom als het belangrijkste gegevensmodel voor agentnavigatie en controleert het namen, rollen, ouder-kindrelaties en zichtbaarheid van bediening.

Dat is een andere vraag dan of de productfeed geldig is. Een zoekmachine of winkelagent kan prima begrijpen dat een product op voorraad is voor € 79,95. Dat vertelt nog niet welke van drie radioknoppen de juiste bezorgmethode is, of de knop met het winkelwagenpictogram een product toevoegt, of de knop “Doorgaan” naar betaling gaat. Een bezoeker kan die bedoeling uit kleur, positie en omliggende tekst halen. Software die de browser bedient, heeft baat bij dezelfde bedoeling in de semantiek van het element.

Een checkout moet zijn eigen keuzes uitleggen

Stel dat een koper een jas heeft gekozen en de agent bij de adresstap aankomt. De pagina toont een postcodeveld, drie bezorgopties en een knop om verder te gaan. Voor de mens is de route misschien vanzelfsprekend. Voor de agent moeten de naam en rol van elk invoerveld en elke keuze duidelijk maken wat er wordt gevraagd en wat selecteerbaar is. “Postcode” zegt meer dan een placeholder die verdwijnt zodra iemand begint te typen. “Afhalen bij winkel” beschrijft de optie; een radioknoprol vertelt dat de keuze tussen alternatieven ligt.

Hetzelfde geldt voor knoppen. Een rij van drie knoppen met alleen het woord “Kies” is visueel misschien nog te begrijpen doordat ze naast drie vervoerders staan. In de toegankelijkheidsboom zijn drie identieke acties veel lastiger uit elkaar te houden. Een naam als “Kies afhalen bij winkel” maakt de handeling expliciet. Dat is geen speciaal trucje voor kunstmatige intelligentie. Het is een contract tussen het scherm en de software die het bedient.

Chrome’s documentatie over toegankelijkheid voor agents maakt het praktische risico concreet: een ontbrekend knoplabel kan zowel iemand met een visuele beperking als een agent verhinderen een taak te voltooien. Die overlap is nuttig. Een interface die voor de ene partij alleen werkt dankzij visuele nabijheid of een verborgen aanname, is afhankelijk van context die niet voor iedere gebruiker beschikbaar is. Daarom is het zinvoller om de checkout als een reeks begrijpelijke beslissingen te zien dan als een plaatje waarop een agent toevallig kan klikken.

De fout en de bevestiging horen bij de taak

De lastigste checkout is vaak niet de route waarop alles goed gaat. Neem een ongeldig of leeg postcodeveld. De pagina kan het rood kleuren, maar als er geen tekst staat die de fout benoemt en duidelijk maakt bij welk veld die hoort, kan de koper de oorzaak missen. Voor een agent wordt herstel dan giswerk: welk gegeven moet veranderen, en waar moet de aandacht naartoe?

De W3C-richtlijn voor foutidentificatie zegt dat een automatisch gevonden invoerfout het betreffende onderdeel moet identificeren en de fout in tekst moet beschrijven. De richtlijn voor statusmeldingen vraagt dat relevante veranderingen, zoals het resultaat van een handeling, programmatisch herkenbaar zijn wanneer ze geen focus krijgen. De toegankelijkheidsaudit van een webshop benoemt de checkout als een plek die teams bij hun beoordeling soms overslaan. Een bruikbare foutstatus vertelt ook de agent wat er net misging.

De laatste stap vraagt om dezelfde precisie. “Bestelling wordt verwerkt” betekent iets anders dan “Je bestelling is geplaatst”. Een bevestiging moet overeenkomen met de werkelijke status van de transactie, niet met het feit dat iemand op een knop klikte. Als het scherm na een actie stil blijft, kan de agent niet betrouwbaar bepalen of hij moet wachten, de koper moet inschakelen of de handeling opnieuw moet proberen. Dat is mijn gevolgtrekking uit de manier waarop statusberichten werken, geen gemeten omzetverlies. Maar het verschil tussen een verwerkte betaling en een echte orderbevestiging is voor elke winkel operationeel belangrijk, ook zonder agent.

Om eerlijk te zijn: niet elke agent leest de boom

Om eerlijk te zijn: een toegankelijkheidsboom is niet de enige manier waarop software een checkout kan bedienen. Een agent kan via een specifieke browserkoppeling of een expliciete toolinterface met de winkel communiceren. Shopify’s WebMCP-tools laten een browseragent de actieve checkout lezen en bijwerken, en de order pas na bevestiging door de koper indienen; de koper blijft de laatste stap goedkeuren. Als verificatie via 3D Secure nodig is, geeft Shopify de bediening terug aan de koper. In zo’n geval hoeft de agent niet ieder schermonderdeel zelf te interpreteren.

Chrome noemt zijn eigen agentische Lighthouse-controles experimenteel en zegt dat ze geen definitieve score opleveren. Ik ken geen openbare onderbouwing dat alleen betere labels aantoonbaar meer orders opleveren.

Dat tegenargument klopt, maar het maakt de checkoutboom niet overbodig. Een gespecialiseerde koppeling werkt alleen waar die bestaat en waar de specifieke winkelroute wordt ondersteund. De gewone browsercheckout blijft het vangnet voor een agent die geen passende tool heeft, voor een mens die moet overnemen en voor ondersteunende technologie. Een goede toolinterface en een begrijpelijke pagina vullen elkaar aan: de eerste maakt bepaalde handelingen expliciet, de tweede houdt de rest van de ervaring leesbaar en herstelbaar. Dat Shopify tools naast de bestaande checkout gebruikt, onderstreept juist dat de zichtbare orderstatus en toestemming van de koper niet verdwijnen.

Ik zou daarom geen groot traject starten op basis van een voorspelling over hoeveel agenten er straks kopen. De Clarity-cijfers geven geen omzetraming en Chrome’s experiment is geen certificaat. Maar een webshopteam kan wel een concretere vraag stellen dan “komen agents langs?”: kan een browseragent de keuzes herkennen, een fout begrijpen en na een betaling vaststellen wat de winkel werkelijk heeft bevestigd? Het antwoord daarop is ook voor mensen relevant: dezelfde basisproblemen kunnen menselijke kopers raken wanneer een checkout labels of terugkoppeling mist.

Leesbaarheid is onderdeel van de verkoop

Een productfeed kan een agent naar de juiste jas leiden. Een betaalroute kan de transactie technisch verwerken. Toch ontstaat de bestelling pas als elke stap ertussen te begrijpen is: welke waarde hoort in welk veld, welke keuze is gemaakt, waarom werd iets afgewezen en of de order nu echt vaststaat. Dat is precies wat een toegankelijke bediening aan de pagina toevoegt.

De agentische checkout is nog in beweging, en de openbare cijfers zeggen nog niet hoeveel omzet hieruit volgt. Juist daarom moet ik voorzichtig zijn met grote claims over een nieuwe verkoopstroom. Wel is er al een duidelijke kwaliteitslat: maak de interactie leesbaar voor de software die de browser bedient, en meet bevestigde orders apart van pogingen en gebeurtenissen.

Een webshop wordt niet agentklaar wanneer een agent hem kan vinden. Hij wordt agentklaar wanneer elke keuze leesbaar is, elke fout begrijpelijk terugkomt en een bestelling pas als voltooid geldt wanneer die echt bevestigd is. Dat is geen extra laag voor software. Het is de kwaliteit van het verkoopproces zelf.