Het is dinsdagochtend en de operations lead van een logistiek bedrijf in Rotterdam met 40 man personeel staart naar drie browsertabs: een Gmail-inbox met 812 ongelezen threads, een Notion-wiki die niemand sinds Q3 heeft geopend, en een prijslijst in een Excel-bestand met de naam final_v7_USE_THIS_ONE.xlsx. Haar CEO heeft haar zojuist in de gang gevraagd welke AI-agent ze als eerste moeten bouwen.
Ze heeft geen strategiedeck nodig. Ze heeft een kaart nodig.
Na veertien agents in productie in de laatste twee jaar — voor advocatenkantoren, e-commercepartijen, een keten van dierenartsen, een paar B2B SaaS-bedrijven — zijn we gestopt met doen alsof elke agent maatwerk is. Dat is niet zo. Het meeste dat een mkb-bedrijf daadwerkelijk in productie draait, valt onder een van vier archetypes. Kies de verkeerde als eerste en je bent een kwartaal kwijt. Kies de juiste en je koopt er een medewerker mee terug.
Hier zijn ze, in de volgorde waarin de meeste teams ze zouden moeten bouwen.
De responder
De responder leest een inkomend bericht — e-mail, WhatsApp, webformulier, soms een telefoongesprek dat in real time wordt getranscribeerd — en antwoordt. Meer niet. Hij bepaalt geen strategie. Hij schrijft geen code. Hij schetst of verstuurt een antwoord dat klinkt als jouw bedrijf, met feiten die hij kan opzoeken.
Dit is het archetype dat de meeste mensen bedoelen als ze zeggen "AI-agent", en het is bijna altijd de juiste keuze om eerst te bouwen. Redenen:
- De input is afgebakend (één bericht).
- De output is afgebakend (één antwoord).
- De faalmodus is zichtbaar (een slechte concept-reply, die een mens opvangt voor verzending).
- De ROI is telbaar (minuten per bericht × berichten per dag).
Een responder die wel concepten maakt maar niet verstuurt, is een responder met zijwieltjes. Je draait hem drie weken met een mens die op "goedkeuren" klikt, je meet de edit distance tussen het concept en de verzonden versie, en als die onder een drempel zakt zet je autosend aan voor specifieke categorieën. Dat is het hele draaiboek.
Als je team verzuipt in een inbox, bouw dan eerst een responder. Al het andere is afleiding totdat die brand uit is.
Wanneer je dit niet moet kiezen
Als je inkomende volume laag is maar elk bericht veel impact heeft (bijvoorbeeld een advocatenkantoor met twee partners die tien aanvragen per dag van €20k per stuk afhandelen), dan is de responder verspilling. Dan automatiseer je precies het deel van het werk dat de partners zelf willen doen. Sla door naar de retriever.
De triager
De triager antwoordt niet. Hij leest, classificeert, routeert en labelt. Hij beslist: is dit een support ticket, een salesleed, een klacht, een recruiter-pitch of een factuur? Hij wijst een eigenaar toe. Hij voegt een prioriteit toe. Hij schrijft een samenvatting van één regel in het ticket.
Dit is de agent die de persoon redt die nu elke ochtend de eerste twee uur besteedt aan dingen sorteren. In onze ervaring bestaat die persoon bij elk bedrijf boven de 15 man, en het is meestal de meest overgekwalificeerde persoon om dat werk te doen.
Een triager is goedkoper en sneller te bouwen dan een responder omdat hij gestructureerde output produceert, geen proza. Hij is ook makkelijker te evalueren: je hebt een gelabelde ground truth (het sorteerwerk van het verleden door een mens) en je kunt accuracy direct uitrekenen.
def triage(message: str) -> dict:
prompt = build_prompt(message, categories=CATEGORIES)
result = llm.complete(prompt, schema=TriageSchema)
return {
"category": result.category,
"priority": result.priority,
"owner": route_table[result.category],
"summary": result.summary,
}
Koppel een triager aan een responder en je hebt iets wat in de buurt komt van een besturingssysteem voor je inbox: berichten komen binnen, worden gesorteerd, worden gedraft, en een mens doet de laatste klik. De meeste van onze email-agent implementaties zijn dit duo.
De retriever
De retriever is de agent die mensen meestal "een RAG-systeem" of "een chatbot over onze documenten" noemen. Iemand stelt een vraag, de agent kijkt in je wiki, je eerdere tickets, je contracten, je productcatalogus, en antwoordt met bronvermelding.
Het is het archetype dat in het begin het meest opwindend klinkt en het minst oplevert. Niet omdat de techniek niet werkt — dat doet ze — maar omdat de meeste mkb-bedrijven geen kennisbank hebben om uit te halen. De Notion-wiki is drie jaar verouderd. De SharePoint bevat vier versies van hetzelfde beleid. De Confluence is voor het laatst bijgewerkt door iemand die in 2022 is vertrokken.
Een retriever die bouwt op een rommelige kennisbank herhaalt met volle overtuiging het verkeerde document dat toevallig bovenaan komt. Ruim eerst de corpus op, bouw daarna de agent.
Bouw de retriever als tweede als je kennis op orde is, of na een documentatie-sprint van twee weken als dat niet zo is. Het betaalt zich terug bij onboarding, klantenservice en de "wat is ons beleid op X"-vragen die de Slack van een manager opvreten.
De operator
De operator doet dingen. Hij plant vergaderingen, werkt het CRM bij, regelt refunds, verzet leveringen, post in een Slack-kanaal, opent een Jira-ticket, draait een SQL-query en mailt het resultaat. Hij heeft handen.
Dit is het archetype dat iedereen als eerste wil bouwen en als laatste zou moeten bouwen. Niet omdat operators exotisch zijn — op zichzelf zijn ze het makkelijkst te doorgronden — maar omdat een operator die handelt op de verkeerde classificatie, of de verkeerde reply drafted, of het verkeerde feit ophaalt, elke fout van de andere drie versterkt. Je wil de responder, triager en retriever stabiel hebben voordat je een van hen schrijfrechten geeft op je productiesystemen.
Het bruikbare mentale model: de operator is de armen en benen. De andere drie zijn de zintuigen en het brein. Bouw eerst de zintuigen.
Voice als speciaal geval
Voice-agents — degenen die je telefoon opnemen — zijn een hybride van responder en operator, en verdienen een eigen behandeling. De korte versie: de voice-laag is klaar voor restaurantreserveringen, afsprakenplanning en triage op eerste lijn. Hij is niet klaar om je SaaS van €80k te verkopen. Weet waar op die lijn je bedrijf staat voordat je je erop vastlegt.
De volgorde om ze te bouwen
Voor de meeste bedrijven tussen €500k en €50M is de eerlijke volgorde:
- Triager op inkomende e-mail. Eén week. Goedkoopst, laagste risico, direct zichtbaar.
- Responder bovenop de triager, alleen concept. Twee tot vier weken. Zet categorieën op autosend naarmate het vertrouwen groeit.
- Retriever op je opgeschoonde interne documenten. Twee weken als het corpus netjes is, vier tot zes als het eerst een sprint nodig heeft.
- Operator als laatste, beperkt tot één workflow tegelijk. Begin met iets omkeerbaars (een CRM-update schrijven) voordat je iets destructiefs doet (een refund uitvoeren).
Deze volgorde valt toevallig ook samen met de risicocurve. De triager kan geen schade aanrichten. De responder wel, maar er zit een mens in de loop. De retriever kan misleiden, maar alleen als antwoord op een directe vraag. De operator kan stilletjes om 3 uur 's nachts een database slopen.
Een kanttekening over wiens data wat traint
De sluipende werkelijkheid op dit moment is dat veel SaaS-tools die je team gebruikt stilletjes hun voorwaarden aanpassen om standaard modellen te trainen op jouw content. Check het instellingenpaneel van alles waar je dit kwartaal voor betaalt; de toggle staat meestal al aan.
Voor een mkb-bedrijf is het praktische gevolg: het concurrentievoordeel van een agent zit niet in het model. Het zit in de data die je erin stopt en die niemand anders heeft — je eerdere e-mails, je ticketgeschiedenis, je gesprekstranscripties, je factuurpatronen. Bewaar die data op een plek die je zelf in de hand hebt, en geef bij het bouwen van agents de voorkeur aan architecturen waarbij de proprietary context aan jouw kant van de lijn blijft.
Hoe dit er in de praktijk uitziet
Toen we afgelopen najaar de email-agent stack bouwden voor een Nederlandse B2B-distributeur, liepen we er tegenaan dat de triager leveranciersfacturen steeds verkeerd classificeerde als klantklachten, omdat beide het woord "urgent" bevatten. Uiteindelijk hebben we dat opgelost door de triager een korte tool-call te geven om te checken of het afzenderdomein in de crediteurenlijst voorkwam voordat de categorie definitief werd — een fix van vijf regels die de accuracy van 82% naar 97% tilde, van de ene op de andere dag. Zo ziet een AI-agents-project er in werkelijkheid uit: geen moonshot, gewoon een eerlijke loop van classificeren, meten, bijwerken.
Voordat je iets bouwt: open een spreadsheet, zet de tien meest voorkomende inkomende berichten die je team afgelopen week afhandelde op een rij, en label elk bericht met triage, reply, lookup of action. Welke kolom het langst is, bepaalt welk archetype je als eerste bouwt. Dat is je kaart.
