De volgende ERP-gebruiker is misschien geen mens

Elk scherm is een gok over wie kijkt

Overweeg wat een ERP is vanuit het perspectief van de gebruiker. Achter het merk is het een set tabellen en regels: klanten, artikelen, bestellingen, facturen, voorraadbewegingen, en de beperkingen die ze consistent houden. Voor dat alles zit het deel waar het meeste geld aan is uitgegeven: enkele duizenden schermen die die tabellen aan een persoon presenteren, een paar velden tegelijk, in een volgorde die een persoon kan volgen, met labels die een persoon kan lezen en knoppen die een persoon kan vinden.

Elk van die schermen encodeert een gok over wie aan de andere kant zit. De gok is een persoon met een beperkt werkgeheugen, dus het formulier is opgesplitst in tabbladen. Een persoon die van links naar rechts leest, dus het belangrijke veld staat linksboven. Een persoon die ongeveer zeven dingen in gedachten kan houden, dus het dashboard heeft zes tegels. Een persoon die typfouten maakt, dus er is validatie bij indienen. Een persoon die moe wordt, dus het gebruikelijke pad heeft minder klikken. Dit alles is goed ontwerp voor de gebruiker die de ontwerper voor ogen had, en gedurende vier decennia was die gebruiker de enige die er was.

Het gevolg is dat de interface een verlieslatende weergave van het datamodel is voor één soort lezer. Het model weet dat een factuur regels heeft, een klant, een vervaldatum en een status; het scherm toont de regels op één tabblad, de klant op een ander, en de status als een kleur. Werk dat vijf records aanraakt, betekent vijf schermen, en de persoon draagt de draad tussen hen in zijn hoofd. Die draad is het grootste deel van wat een bedrijf zijn administratief personeel betaalt om vast te houden.

De nieuwe gebruiker heeft tools, geen handen

Een AI-agent die een bedrijfsysteem bedient, ontvangt niets van dat alles. Wat hij ontvangt, wanneer hij verbinding maakt via het Model Context Protocol, is het resultaat van een verzoek om tools op te sommen: voor elk een naam, een beschrijving geschreven voor een model om te lezen, een schema voor zijn invoer, en optioneel een annotatie die aangeeft of de tool alleen leest, of het iets kan vernietigen, en of het veilig is om het twee keer aan te roepen. De agent kiest een tool, roept deze aan met getypte argumenten, leest het resultaat en kiest opnieuw. De eigen samenvatting van het protocol is dat het een gestandaardiseerde manier is om AI-toepassingen met externe systemen te verbinden, zoals een gemeenschappelijke poort apparaten verbindt, en de grote klanten spreken het nu: Claude, ChatGPT, Cursor en VS Code onder anderen.

Kijk naar wat deze gebruiker niet nodig heeft. Het heeft de factuur niet gesplitst in tabbladen nodig, omdat het het hele record in één keer kan vasthouden. Het heeft het belangrijke veld linksboven niet nodig, omdat er geen links is. Het heeft geen zes tegels nodig, omdat het kan vragen om het aantal dat het wil. Het wordt niet moe, en er zijn geen klikken. Elke concessie die het scherm goed maakte voor een persoon, is voor deze gebruiker ofwel irrelevant of een obstakel.

En kijk naar wat het in plaats daarvan nodig heeft, wat het scherm nooit heeft geboden. Het heeft een nauwkeurige beschrijving van elke actie nodig, omdat de beschrijving het geheel van zijn begrip is. Het heeft een compleet schema nodig, omdat het geen voorbeeld kan zien. Het moet weten welke acties veilig opnieuw kunnen worden geprobeerd. Het heeft het resultaat nodig om te zeggen wat er is gebeurd en wat het mogelijk kan doen. Voor deze gebruiker is de documentatie de interface, en benoemen is ontwerp: één brede tool met een beschrijving van twee regels is een slechter product dan dezelfde capaciteit als drie tools met eenvoudige namen en eerlijke beschrijvingen, ongeacht hoe de schermen erboven eruitzien.

De omweg via het scherm zal niet lang duren

De eerste reactie op een nieuwe gebruiker is altijd om deze te kleden als de oude. Robotic process automation deed dit een decennium lang: een bot logt in met een serviceaccount en bestuurt de schermen alsof het handen had, waarbij het de knop vindt via zijn selector of zijn coördinaten. De huidige versie geeft een taalmodel een screenshot en een cursor. Het computergebruik van Anthropic doet precies dat, en de documentatie is zorgvuldig in het aangeven waar het thuishoort: het bestaat voor de gevallen waarin er geen strakkere interface beschikbaar is, het leidt je naar een browsertool wanneer het werk binnen een pagina blijft, en het vraagt om een persoon om alles met betekenisvolle gevolgen in de echte wereld, inclusief financiële transacties, te bevestigen.

Het kost veel om het kostuum te dragen. Een scherm doet geen beloftes aan een machine, dus elke wijziging die voor de persoon wordt aangebracht, breekt de automatisering die doet alsof het er een is. Elke laag tussen de agent en de actie, de screenshot, de gok welke pixel de knop is, de getypte tekst die al dan niet in het juiste veld is beland, is een plek om fout te zijn, en een model is al een plek om fout te zijn. Schermbesturing is de brug die je bouwt terwijl het systeem eronder niets beters heeft, en de leveranciers van de bots zeggen het zelf: ze beschrijven de robot nu als een uitvoeringslaag die een agent oproept voor de systemen die het nog nodig hebben.

Wat software moet worden

Als het argument tot nu toe standhoudt, volgt de vorm van agent-native software daaruit, en het is meer dan een API aan de zijkant. Vijf eigenschappen moeten tegelijkertijd waar zijn.

• Elke actie is een hulpmiddel. Niet de dozijn die de leverancier dacht dat veilig was, maar het hele oppervlak dat een persoon kan bereiken via de schermen: creëren, lezen, verplaatsen, goedkeuren, verzenden, reconciliëren. Alles minder, en de agent moet voor de rest terugvallen op het scherm.
• Elke oproep draagt een identiteit. De agent handelt als een specifieke persoon, via een normale aanmelding, en de tools die hem worden aangeboden, worden gefilterd op basis van de rol van die persoon voordat hij ze ooit ziet en opnieuw gecontroleerd wanneer ze worden uitgevoerd. Een agent met toegang tot het systeem is een ontwerpfout, geen functie.
• Het vraagt om ontwerp. Sommige acties worden uitgevoerd; sommige wachten op een persoon; sommige worden outright geweigerd. Het protocol zelf zegt dat er altijd een mens in de lus moet zijn die een tooloproep kan weigeren, en de belangrijkste klanten vragen standaard voordat er wordt geschreven. De software moet de categorieën expliciet maken in plaats van te hopen dat het model beleefd is.
• Uitgaven hebben een plafond. Waar de eigen redenering van het systeem geld kost, of waar een tool geld verbindt, is er een limiet per verbinding die het systeem afdwingt en waar het model niet omheen kan praten.
• De log is het product. Elke oproep, de invoer en het resultaat, onder de identiteit die het heeft gemaakt, is te herzien op dezelfde manier als de acties van een persoon. Voor een agent is het auditspoor hoe vertrouwen wordt opgebouwd, week na week.

Een zesde eigenschap is minder een vereiste dan een gevolg. Wanneer werk wordt gedaan met tools, wordt het record als een bijproduct bewaard: de agent die factureert, achtervolgt en reconciliëert, laat precies de factuur, de achtervolger en de reconciliatie achter die een persoon zou hebben getypt, zonder het typen. De schermen blijven bestaan, voor het bekijken, herzien en beslissen. Ze zijn niet langer de enige plek waar werk kan plaatsvinden.

De bezwaren die het overwegen waard zijn

De sterkste bezwaren erkennen dat agents het werk kunnen doen en wijzen erop dat ze het soms verkeerd doen, vol vertrouwen, bij een schrijfactie. Dit is waar, en de eerlijke documentatie zegt dat ook: ChatGPT behandelt elke tool zonder een alleen-lezen annotatie als een schrijfactie en vereist standaard bevestiging; Claude vraagt om goedkeuring voordat een tool van een aangepaste connector wordt ingeschakeld en waarschuwt dat een kwaadaardige server verborgen instructies kan bevatten. De klanten hebben gelijk om voorzichtig te zijn, en een bedrijf zou dat ook moeten zijn.

Maar let op waar de voorzichtigheid moet leven. Het kan niet in het model leven, dat is de partij die mogelijk fout is. Het moet in de software leven, wat precies is waar goede software het al heeft geplaatst voor menselijke gebruikers. Validatie, machtigingen, goedkeuringsdrempels, ongedaan maken, audit: elk van deze bestaat omdat de vorige gebruiker ook fouten maakte, vol vertrouwen, bij een schrijfactie. Agent-native software neemt die oude discipline serieus bij elke actie in plaats van bij de weinige die de schermontwerper zich herinnerde, en past het toe op een gebruiker die voor de lunch honderd tools zal aanroepen.

Een tweede bezwaar is determinisme. Sommige werkzaamheden moeten elke keer dezelfde output voor dezelfde input opleveren, bewijsbaar. Dat werk moet een vaste workflow blijven, en de agent moet de workflow als een tool aanroepen in plaats van deze te improviseren. Oordeel vervangt hier de regels niet; het systeem heeft beide nodig, blootgesteld aan een gebruiker die ze uit elkaar kan houden.

Wie bouwt het, en voor wie

De laatste consequentie is degene die de ondernemer zou moeten opmerken. Als de gebruiker van de software een agent kan zijn, kan de bouwer dat ook. Een ontwikkelaar beschrijft de app die ze willen aan een agent die ze al hebben, de agent bouwt deze met een set bouwtools, de ontwikkelaar valideert deze lokaal en publiceert deze, en vanaf de eerste dag is elke tool die de app levert beschikbaar voor elke andere agent op het platform. Het bedrijf dat het installeert leert zijn schermen niet; het personeel brengt de agent die ze al gebruiken en beschrijft de uitkomst. Dat is de regeling waar Sois omheen is gebouwd, hier aangeboden als een implementatie van het argument in plaats van als de conclusie.

De conclusie is eenvoudiger. Veertig jaar lang was de vraag die een softwareontwerper stelde wat de persoon aan de andere kant moet zien. De volgende gebruiker ziet dat niet. Het leest een contract en roept op wat het mag aanroepen, en dat zal het doen namens dezelfde mensen voor wie de schermen zijn gebouwd. Software die die gebruiker als een eersteklas burger behandelt, zal vloeiend worden bediend. Software die het scherm als enige toegang houdt, zal nog steeds worden bediend, door een sleutelgat, door een agent in een kostuum, totdat de eigenaren moe zijn van het kostuum en verhuizen.

Dit artikel wordt herzien wanneer de producten die het beschrijft veranderen. Volgende geplande herziening: 4 december 2026.