De volgende gebruiker van uw software is een AI-agent. Is uw architectuur daarop voorbereid?

Stel u een AI-agent voor die een geschil over een klantfactuur afhandelt. De agent leest de klacht, controleert de accountgeschiedenis en stelt vast dat een tegoed gerechtvaardigd is. Dat alles binnen enkele seconden.

Indrukwekkend. Vraag de agent nu om het tegoed daadwerkelijk toe te kennen.

De klantovereenkomst staat in een ander systeem. De goedkeuringsregels zitten diep verborgen in de programmacode van de applicatie. De factureringstool verwacht dat iemand door meerdere schermen klikt.

De agent begrijpt wat er moet gebeuren, maar de architectuur laat hem de taak niet afronden.

Dat is het probleem waarmee naar verwachting steeds meer bedrijven te maken krijgen nu agentische AI in productie wordt genomen. Vreemd genoeg heeft de belemmering die de agent ervan weerhoudt de taak af te ronden nauwelijks iets te maken met zijn intelligentie.

Jarenlang hebben we bedrijfssoftware gemoderniseerd voor de mensen die ermee werken. Nu moeten we die moderniseren voor de agenten die er steeds vaker mee aan de slag gaan.

De gebruikersinterface was nooit het hele product

Denk aan de manier waarop bedrijfssoftware tegenwoordig werkt. Mensen openen applicaties, navigeren door dashboards, nemen beslissingen en verplaatsen werk van het ene systeem naar het andere. Via de gebruikersinterface werken ze met het bedrijf.

Een agent heeft die schermen niet per se nodig. Hij kan informatie ophalen en acties starten via API’s, MCP-servers (Model Context Protocol) en andere programmeerbare interfaces. Dat is een onderdeel van de verschuiving naar een headless-architectuur.

Maar headless betekent niet dat de applicatie verdwijnt. De gegevens, bedrijfsregels, toegangsrechten en nalevingsvereisten blijven belangrijk. Ik zou zelfs zeggen dat ze nog belangrijker worden.

Jarenlang bouwden softwareleveranciers hun concurrentievoordeel op basis van verfijnde gebruikersinterfaces, gebruikersgewoonten en de kosten van het omscholen van medewerkers. Dat voordeel neemt af wanneer agenten meer werk uitvoeren zonder de gebruikersinterface van de applicatie te openen. Wat meer waarde krijgt, is het onderliggende registratiesysteem: betrouwbare gegevens, gevalideerde domeinlogica, operationele beheersing en controleerbare transacties.

Dat heeft ook commerciële gevolgen: tegen 2030 kan tot 234 miljard dollar aan uitgaven voor bedrijfsapplicaties blootstaan aan de ontwrichting door agentische AI. Het gaat om uitgaven die gevaar lopen te worden ontwricht, niet om uitgaven die gegarandeerd verdwijnen. En wanneer agenten werk overnemen dat mensen voorheen in dashboards uitvoerden, kan de prijs per gebruiker steeds vaker plaatsmaken voor modellen op basis van gebruik, acties of resultaten.

Voor softwareleveranciers is dat een uitdaging voor hun bedrijfsmodel. Voor bedrijven die op hun applicaties vertrouwen, is het een architectuurvraagstuk.

We hebben onderdelen gemoderniseerd, maar niet het werkproces

De meeste bedrijven zijn al jaren bezig met modernisering. Het ene team werkt verouderde applicaties bij. Een ander brengt versnipperde gegevens samen op een modern platform. Een derde bouwt integraties of vernieuwt simpelweg de gebruikersinterface.

Elk project kan afzonderlijk slagen. De problemen beginnen wanneer een agent een werkproces moet uitvoeren dat al die onderdelen omvat.

U kunt een agent nauwkeurige klantgegevens geven, maar wat gebeurt er vervolgens als de applicatie die ermee aan de slag moet belangrijke regels verborgen houdt in verouderde programmacode? U kunt ook een overzichtelijke API beschikbaar stellen, terwijl de gegevens erachter inconsistent blijven. De agent kan actie ondernemen, maar kunt u erop vertrouwen dat de beslissing klopt?

In beide gevallen hebben we delen van de technologie gemoderniseerd, maar niet het werk zelf.

Het maakt agentische AI niet uit welk moderniseringsproject is geslaagd. Het gaat erom of het volledige werkproces werkt.

Zo ziet dat er in de praktijk uit. Een klant wilde offertes voor complexe motorreparaties sneller opstellen. Contracten bepalen daarbij welke onderdelen gerepareerd, vervangen of gereviseerd mogen worden. Voor elke offerte was dagen, soms weken, handmatig onderzoek nodig in contracten en onderhoudshandleidingen. De klant had zijn gegevensplatform al gemoderniseerd, maar de offertes kwamen niet sneller tot stand, omdat de gegevens nooit het knelpunt waren. Het knelpunt was het onderzoek. We hebben dat werkproces opnieuw opgebouwd rond een reeks onderzoeksagenten, de onderzoekstijd met 80% teruggebracht en ervoor gezorgd dat offertes in een heel ander tempo konden worden opgesteld.

Daarom kunnen de modernisering van applicaties en die van gegevens niet als twee onafhankelijke trajecten worden gepland. De architectuur moet het volledige bedrijfsresultaat ondersteunen.

Een API maakt een systeem nog niet klaar voor agenten

Het is verleidelijk te denken dat de oplossing eenvoudig is: stel de eindpunten beschikbaar, koppel de agent en klaar.

Was het maar zo eenvoudig.

Informatie ophalen is één ding. Een tegoed toekennen, een financieel gegeven bijwerken of een vervangend onderdeel bestellen is iets heel anders. Dan hebben we het over uitvoering, niet alleen over toegang.

Daarvoor gebruik ik de term besturingsvlak voor agenten: de afgebakende, beheerde interface waarmee agenten gegevens uit registratiesystemen kunnen lezen en ernaar kunnen schrijven.

API’s en MCP-servers kunnen agents toegang geven tot tools en gegevens. Maar MCP dwingt je bedrijfsregels niet automatisch af en bepaalt niet wie bevoegd is om te handelen. Die controles moeten nog steeds worden ingebouwd in de onderliggende systemen en workflows.

Kan de agent gezaghebbende gegevens ophalen? Zijn de bedrijfsregels expliciet en worden ze consequent toegepast? Kan de agent een handeling aanbevelen, maar alleen de handelingen uitvoeren waartoe hij bevoegd is? Kunnen we, als er iets misgaat, de handeling traceren, de uitzondering afhandelen en de handeling waar mogelijk ongedaan maken?

Dit zijn geen problemen die een beter model vanzelf oplost. Het zijn vraagstukken rond workflows, applicatieontwerp, gegevensarchitectuur, integratie en governance. En ze moeten in samenhang worden aangepakt.

Begin bij het werk, niet bij de technologie

Waar begin je dan?

Ik zou niet beginnen met elke applicatie headless te maken of elke beschikbare API beschikbaar te stellen. Ik zou beginnen met één betekenisvolle bedrijfsworkflow.

Breng die van begin tot eind in kaart. In welke systemen staan de gegevens? Waar bevindt zich de bedrijfslogica? Op welke gegevens kan de agent vertrouwen? Voor welke beslissingen is menselijke goedkeuring nodig? Wat gebeurt er als een systeem halverwege uitvalt? Hoe wordt de governance gewaarborgd?

Zo ontdek je waar de belangrijkste hiaten zitten. Dat vormt je moderniseringsroutekaart: een gecoördineerde backlog voor applicaties, gegevens, integraties en beheersmaatregelen, gericht op een bedrijfsresultaat in plaats van op losstaande technologieprojecten.

Meet de voortgang ook op die manier. Niet aan de hand van het aantal API’s dat je beschikbaar hebt gemaakt of de hoeveelheid gegevens die je hebt gemigreerd, maar aan de hand van de vraag of de workflow betrouwbaar wordt afgerond, hoe uitzonderingen worden afgehandeld en of de bedrijfsresultaten verbeteren.

Het doel is niet om alles autonoom te laten verlopen. Het gaat om betrouwbare en vertrouwde uitvoering, met menselijk oordeel waar dat thuishoort.

De echte omslag gaat verder dan een architectuur zonder gebruikersinterface

Wat mij enthousiast maakt, is niet het verdwijnen van dashboards. Het gaat erom dat mensen niet langer handmatig werk tussen losgekoppelde systemen hoeven over te dragen om hun taak uit te voeren.

Maar zover komen we niet door een agent boven op een architectuur te plaatsen die daar nooit voor is ontworpen.

De volgende generatie bedrijfssoftware wordt niet alleen bepaald door wat mensen ermee kunnen zien. Bepalend is ook wat agents er betrouwbaar en verantwoord mee kunnen doen.