Agent-native systemen

Wat is een agent-native systeem?

Een agent-native systeem is zo gebouwd dat software het kan lezen en er acties in kan uitvoeren, en niet alleen een mens die op een scherm klikt. Het scherm blijft bestaan en je collega's blijven het gebruiken. Het verschil is dat alles wat via het scherm kan, ook bestaat als iets dat een machine kan aanroepen: onder namen die een release overleven, met output die een programma kan uitlezen, en met een login van de agent zelf.

Het is een eigenschap van een interface, geen productcategorie. Hetzelfde boekhoudpakket kan agent-native zijn om facturen te lezen, omdat daar een gedocumenteerde API voor bestaat, en volledig dicht zijn om ze goed te keuren, omdat goedkeuren enkel als knop bestaat. Waar het scherm er eerst was en de API er later is bijgeplakt, groeien de twee uit elkaar en krijgt de agent de helft die niemand onderhoudt.

Vijf dingen die een systeem bruikbaar maken voor een agent

1. Een ingang die niet het scherm is. Een gedocumenteerde API, een commandline-tool, een bestand in een afgesproken formaat. De namen van de operaties en de velden overleven een release, zodat code van vorig kwartaal blijft draaien.

2. Output die een programma kan uitlezen. Een JSON-object met een op voorhand aangekondigde vorm, geen lap tekst en geen PDF. MCP laat een tool een outputSchema publiceren en verplicht de server om resultaten terug te geven die daarmee overeenkomen. Een agent die een zin moet lezen om een cijfer te vinden, leest ooit het verkeerde cijfer.

3. Foutmeldingen die zeggen wat je in de plaats moet doen. De MCP-specificatie maakt een onderscheid tussen een verkeerd opgebouwd verzoek en een mislukte uitvoering, en zegt dat zo'n uitvoeringsfout "actionable feedback" moet bevatten waarmee het model zichzelf kan corrigeren en opnieuw kan proberen met aangepaste parameters. Het voorbeeld in de spec zelf is Invalid departure date: must be in the future. Daar kan een agent iets mee. Met Error 500 niet.

4. Operaties die je veilig opnieuw kan proberen. Verbindingen vallen weg en agents proberen opnieuw. Stripe lost dat op met een idempotency key: de client stuurt een unieke sleutel mee, Stripe bewaart het resultaat van de eerste oproep onder die sleutel, en een herhaling met dezelfde sleutel geeft dat bewaarde resultaat terug in plaats van een tweede object aan te maken. Zonder zoiets wordt een weggevallen verbinding een dubbele betaling.

5. Rechten die van de agent zijn. Google omschrijft een service account als een speciaal soort account dat gebruikt wordt door een toepassing of een workload in plaats van door een persoon, met niet meer rechten dan het nodig heeft. Microsoft trekt datzelfde idee door naar agents met Entra Agent ID: elke agent krijgt een eigen identiteit in de directory en een sponsor, de mens die er verantwoordelijk voor is. De winst is saai en groot: je ziet wat de agent gedaan heeft, en je kan hem intrekken zonder een collega buiten te sluiten.

Dezelfde klus via een API en via het scherm

Een leverancier stuurt een maandstaat, en er moeten 40 facturen in je boekhoudpakket op betaald gezet worden, met de betalingsreferentie erbij.

Via een API vraagt de agent in een gefilterde oproep de openstaande facturen van die leverancier op, en stuurt daarna 40 aanpassingen, elk met een idempotency key. Elk antwoord komt gestructureerd terug, dus de agent weet per factuur of het gelukt is. Eentje was vorige week al afgepunt, en de API zegt dat met naam en reden, dus die slaat hij over en zet hij in het rapport. Dat is enkele seconden werk en 41 oproepen. De fout die hier kan sluipen is snelheid: staat de filter verkeerd, dan zitten alle 40 records fout nog voor iemand het merkt. Daarvoor bestaan een testrun, een plafond op het aantal records per run, en een mens die de batch aftekent.

Via het scherm zoekt de agent de leverancier op, opent een factuur, klikt op Betaald, typt de referentie, bewaart, gaat terug, en herhaalt dat 40 keer. Elke stap is een screenshot en een modeloproep, en daarom reken je bij computer use in minuten en in kost per stap, niet in API-oproepen. Hij heeft ook een echte gebruikerssessie nodig, dus het auditlog zegt dat een collega dat allemaal gedaan heeft. De fout komt hier van de leverancier: een release verhuist Betaald naar een uitklapmenu, en de knop naast degene die de agent zocht is Betwist.

Dat is de eerlijke vergelijking tussen de twee: wat er gebeurt als de leverancier iets wijzigt. Bij een API komt die wijziging met een versie. Stripe brengt brekende wijzigingen uit als grote versies met een naam, houdt de maandelijkse releases achterwaarts compatibel, en laat je vastklikken op de versie waarop je gebouwd hebt met een Stripe-Version header. Een scherm heeft geen versie om op vast te klikken en geen changelog voor een knop.

Een API-wijziging komt met een versienummer en een datum. Een schermwijziging komt op een dinsdag, en het eerste wat ze je vertelt is een verkeerd resultaat.

Wat een leverancier bovenop een API moet leggen

Een API hebben is het toegangsticket. Drie dingen bepalen daarna of een agent er nuttig werk mee doet.

Een machineleesbare beschrijving van de operaties. OpenAPI is de gangbare vorm, en versie 3.2.0 uit september 2025 zegt het doel gewoon: mensen en computers moeten kunnen ontdekken en begrijpen wat een dienst kan zonder de broncode, extra documentatie of het netwerkverkeer te moeten bekijken.

Een granulariteit die overeenkomt met een handeling uit het bedrijf. De engineeringrichtlijnen van Anthropic over het schrijven van tools voor agents zijn daar duidelijk in: bouw een schedule_event in plaats van de agent list_users, list_events en create_event aan elkaar te laten knopen. Een API endpoint per endpoint omzetten naar tools is de fout, want elke extra heen-en-weer kost context die de agent niet over heeft.

Paginering en limieten waar je op kan rekenen. Cursors in plaats van offsets, een melding bij afkappen die zegt hoe je gerichter zoekt, en een limiet op het aantal oproepen die gedocumenteerd is in plaats van ontdekt.

De standaardvorm voor dat laatste stuk is in 2026 MCP, een open protocol op JSON-RPC 2.0 waar een server resources aanbiedt voor data, prompts voor sjablonen en tools die een model kan uitvoeren, huidige revisie 2026-07-28. Je krijgt ontdekking, schema's, het onderscheid tussen fouttypes en paginering in dezelfde vorm bij elke leverancier. Je krijgt er geen goed systeem onder, en de specificatie zegt zelf dat MCP die veiligheidsprincipes niet kan afdwingen op protocolniveau, dus toestemming en toegangscontrole blijven jouw werk. Stripe toont het samengestelde geheel: naast de REST-API staan een MCP-server, onderhouden agent skills, en een commando stripe agent setup dat de coding agents op je machine configureert.

Wat dit betekent als je software koopt in plaats van bouwt

De meeste bedrijven ontwerpen nooit zelf een agent-native systeem. Ze kopen er een, of net niet. De vraag valt samen in vier dingen die je aan een leverancier stelt voor je tekent.

• Kan dit aangestuurd worden zonder menselijke sessie, en waarmee: een API, een CLI, een ondersteunde MCP-server, of niets?

• Zit dat in de licentie die we nu voorgelegd krijgen, of in een hoger pakket of een prijs per oproep?

• Welke operaties mogen we schrijven, en niet alleen lezen? Leestoegang is gewoon. In schrijftoegang zit de automatisatie.

• Kunnen we een aparte identiteit aanmaken met eigen rechten en een eigen limiet, of moet de agent inloggen als een van onze mensen?

Zet de antwoorden in het contract en niet in het verslag. De systemen waar je bestellingen, je uren en je facturen in zitten, bepalen het plafond van wat je kan automatiseren. Een proces dat vier systemen raakt waarvan er drie enkel via een mens bereikbaar zijn, blijft een proces met een mens erin, welke tooling je er ook bovenop koopt.

Waar moet je op letten bij agent-native systemen

Een API maakt een product nog niet agent-native. Ongedocumenteerde endpoints, een oproep per veld, error 500 op een verkeerde datum en geen testomgeving: daar loopt een agent op vast. Vraag om de referentiedocumentatie en een sandbox voor je de featurelijst van de leverancier gelooft.

Elke deur die je voor een agent opent, is een deur. Een breder oppervlak voor jouw agent is een breder oppervlak voor een gekaapte agent, en instructies verstopt in een binnenkomende mail of een leveranciersdocument zijn de gewone manier waarop dat gebeurt. Wat een tool zelf over zichzelf zegt is trouwens geen bewijs: MCP-clients moeten die beschrijvingen als onbetrouwbaar behandelen tenzij ze van een vertrouwde server komen, en daar staat tool poisoning op.

Dit gaat over systemen, niet over je bedrijf. Of de software van je leveranciers door een machine bestuurd kan worden, is een andere vraag dan of jouw organisatie een AI-native bedrijf is. Een klassiek bedrijf met agent-native systemen automatiseert meer dan een ambitieus bedrijf met dichtgetimmerde software.