De Verkeerde Standaarden: Een Manifest voor AI-agents

Door Phan Phan (12 augustus 2026)

Zie je de overeenkomsten in de interfaces van AI-agents die verschillende bedrijven aanbieden? Er zijn chatsessies, modelselecties, tooninstellingen, MCP-verbindingen, vaardigheden en geheugens. Ze stellen de "industriestandaarden" vast, en iedereen die nu een nieuwe AI-agent bouwt voor zichzelf of voor hun bedrijf, volgt diezelfde standaard.

Of je het nu beseft of niet: deze standaarden zijn slecht, en ik zal je vertellen waarom.

Configuraties zijn vaak een beleefde manier om onzekerheid te verzenden

Wanneer engineers een CLI (command-line interface) bouwen met verschillende vlaggen, of een product met diverse instellingen, komt dat meestal omdat ze niet precies weten wat de gebruiker wil. Daarom bieden ze een keuze: een instelling. Hiermee verschuiven ze de rol van "beslisser" subtiel naar jou.

Bij het gebruik van huidige standaard AI-chatinterfaces roept dat veel vragen op:

• Waar heb ik X besproken?
• Moet ik dit gesprek nu inkorten omdat het contextvenster bijna vol is, of open ik een nieuw gesprek?
• Welk ander model moet ik gebruiken?
• Met welke connectoren moet ik verbinden?

Je moet voor elk van deze punten een beslissing nemen. In feite word je gedwongen om in "engineering-taal" te spreken.

Een van de beste eerste indrukken van iOS (vergeleken met Android) is dat iPhones altijd klaar voor gebruik zijn. Natuurlijk heb je beperkte keuzes en zit je "locked in", maar de waarheid is dat de meerderheid van de gebruikers niet veel aanpassingen nodig heeft om het product te laten werken. Je pakt de telefoon op en gebruikt hem; het werkt gewoon. Wat kan handiger zijn?

Om eerlijk te zijn: beide benaderingen bestaan omdat er mensen zijn die vrijheid van keuze willen en meer configuraties wensen. Maar als je een bedrijf bent dat honderden of duizenden werknemers wil stimuleren om AI beter te adopteren, dan moet je de "iPhone-versie" bouwen. Deze is immers geoptimaliseerd voor massale adoptie. Je wilt de meerderheid van de gebruikers niet opofferen voor het luxegevoel van een paar power users.

Je moet breken met deze verkeerde standaarden (The Wrong Defaults).

Doe het juiste

Ik ben van jongs af aan geleerd: als je gelooft dat je het juiste doet, ook al zegt iedereen het tegenovergestelde, vertrouw dan op je intuïtie. Hier is mijn visie.

Als je kijkt naar het huidige landschap van AI voor bedrijven, zie je dat organisaties (groot en klein) wanhopig zijn om AI te implementeren uit angst om achter te blijven. Ze kopen licenties van AI-bedrijven en bouwen vervolgens hun eigen AI-agents volgens de industriestandaarden van diezelfde bedrijven. Het is een eindeloze cyclus waarbij alleen de AI-leveranciers winnen, terwijl de eindgebruikers degene zijn die lijden.

Eén gesprek is voldoende voor de AI-agent

Op dezelfde manier als dat je praat met vrienden of collega's: je hebt één lang chatverloop per persoon. Je opent de chat en begint te typen. Zo zou het moeten werken. Laat je niet hersenspoelen door de standaard en bouw geen interface met meerdere sessies. Als jij als bouwer van een AI-agent het contextbudget of het probleem van AI-hallucinaties niet kunt oplossen, is dat jouw verantwoordelijkheid. Leg dat niet bij de gebruikers en verwacht dan dat zij je tool "adopteren".

Spoiler alert: dit kan door simpelweg te observeren hoe het menselijk geheugen werkt. Ons brein heeft ook een soort "contextbudget", alleen veel groter. Wij vergeten ook dingen. Pas dat oordeel toe op je AI, en je zult je eigen oplossingen vinden.

Integreer AI-agents direct in je chatplatform

Of je nu Slack, Teams of een andere applicatie gebruikt: het kopiëren en plakken van chats tussen AI-agents en deze platforms is absurd. Het is een volstrekt onlogische standaard.

Je chatplatform bevat al context: gesprekken met collega's, beslissingen in groepschats, gedeelde bestanden en uitgewisselde links. Waarom zou je de gebruiker dwingen die context te verlaten, een andere tool te openen, daar een vraag te plakken, een antwoord te krijgen en dat vervolgens weer terug te kopiëren?

Stel je een wereld voor waarin je AI-agent direct in dezelfde chat leeft. Je praat ertegen zoals je tegen een collega praat. Je collega kan zien wat de agent zegt, en de agent kan zien wat je collega zei. Geen contextverlies, geen copy-paste en geen schakelen tussen tabbladen. Dat klinkt als sciencefiction, maar dat is het niet.

Eén AI-agent is genoeg

De AI-industrie wil dat je zoveel mogelijk AI-agents bouwt; dat is hoe zij geld verdienen. Ze bouwen platforms voor bedrijven, zodat die bedrijven weer platforms kunnen bouwen voor hun werknemers, om vervolgens gespecialiseerde, persoonlijke assistent-agents te maken.

Je loopt hiermee recht in de val: je verbruikt tokens om agents te bouwen en vervolgens tokens om ze te gebruiken. Als je bedrijf bovendien twee verschillende AI-leveranciers betaalt, worden de kosten vervijfvoudigd.

De vraag is: waarom zou je zoveel verschillende agents willen? Men beweert dat gespecialiseerde agents slimmer zijn, minder hallucineren en betrouwbaarder zijn. Maar klopt dat? Wat als je slechts één general-purpose agent bouwt die per gebruiker kan worden aangepast op basis van persoonlijkheid en rol? Wat als je een "leeg vat" bouwt dat verschillende vaardigheden kan laden, afhankelijk van de vraag?

Dit optimaliseert niet alleen de kosten voor bouw en beheer, maar maakt het ook veel eenvoudiger om governance en beveiliging toe te passen op de infrastructuur. Elke werknemer heeft direct zijn eigen persoonlijke assistent. Eén pijl, meerdere doelen.

Geef de AI-agent generieke tools

Om agents slimmer te maken, koppel je ze aan extra API's en systemen. Dat klinkt simpel, maar er is een addertje onder het gras. Als je verbindt met Jira via jira-cli, Confluence via confluence-cli en Google via google-cli, hoeveel van dit soort CLI's ga je dan ondersteunen? Elke nieuwe integratie vereist de inzet van een engineer. En noem deze CLI-instellingen nooit tegen de eindgebruiker; dat is een vreemde taal voor hen.

Het antwoord is simpeler: hoe werken die CLI's met de API's? Via TCP/HTTP-aanroepen. De gemeenschappelijke deler is een generieke tool om data via HTTP te verzenden. Linux heeft hiervoor een zeer krachtig programma: curl.

Met curl kan je AI-agent natuurlijk elke API bereiken. De agent hoeft alleen te weten waar hij moet verbinden, hoe hij moet authenticeren en wat het doel is, wat je in een eenvoudige tekstinstructie kunt beschrijven. Bovendien weten LLM-modellen veel over publieke API-documentatie (zoals Atlassian of MS Graph API), waardoor je die details niet eens hoeft te herhalen in de instructies.

Hoewel AI-code-editors MCP- of Connector-configuraties hebben, zijn dat andere producten met andere doelen. Onthoud: jouw doel is adoptie. Eén klik minder betekent tien potentiële gebruikers meer.

Kennisbanken zijn overschat

Vanuit een bedrijfsperspectief is het logisch dat LLM-modellen beschikken over de kennis van de organisatie. Een veelgehoord advies is om een knowledge-base (KB) laag te bouwen waaruit de LLM betrouwbaar data kan trekken met exacte citaten en bronverwijzingen (RAG).

Wie dit zelf implementeert, merkt echter dat het bouwen en onderhouden van zo'n KB niet triviaal is. Het is een enorme component die constante monitoring, data-ingestie en updates vereist om conflicten te voorkomen en de juiste ranking te behouden.

Daartegenover staat dat modellen steeds beter worden in zelfredeneren (self-reasoning). In plaats van te vertrouwen op gecompliceerde RAG-pipelines, kun je de modellen "rommelige" data uit verschillende bronnen geven met een duidelijke instructie. De resultaten zijn verrassend accuraat en je verwijdert hiermee een massief engineering-onderdeel. Je moet zelf de balans vinden tussen complexiteit, optimalisatie en gebruikerservaring.

Fine-tuning is ook overschat

Een andere manier om bedrijfskennis in LLM-modellen te brengen is fine-tuning. Maar continu leren is moeilijk; het is lastig om nieuwe kennis toe te voegen zonder dat dit ten koste gaat van de basisprestaties. Bovendien kost deze experimenteerdrift bedrijven een fortuin.

Een alternatieve aanpak, terwijl we wachten tot fine-tuning verbetert, is het vertrouwen op live data via API-aanroepen (via skills of tools). Ja, dezelfde vraag van twee verschillende gebruikers zal dezelfde API-aanroep triggeren, wat inefficiënt lijkt. Maar accuratesse gaat boven optimalisatie die tot foute antwoorden leidt. Het opbouwen van vertrouwen bij de gebruiker is niet onderhandelbaar.

***

De industrie profiteert van complexiteit en zal dit niet voor je oplossen. Je kunt er zelf voor kiezen om de standaarden te doorbreken en met vertrouwen te bouwen, of je kunt de massa volgen en hopen dat mensen je tool toch nuttig vinden. De keuze is aan jou.