Waarom de meeste agentic-pilots niet schalen.
Hoe een pilot eruitziet die werkte
Kies een klein team. Kies een use case waar de gebruiker op het team zit. Draai de pilot vier weken met engineers in de loop. Lever iets dat werkt. Het team is trots, de demo is goed, het slidedeck schrijft zichzelf bijna.
Dit is de makkelijke 20 procent. De pilot werkte omdat de engineers de gebruikers waren en de engineers ook de operators. Als de engineers de kamer verlaten en de pilot een uitrol wordt, breken er drie dingen.
Faalmodus 1: de platform-substraat was niet echt
De pilot draaide in een sandbox-account met hardcoded API-keys, een side-cluster, en een Streamlit-interface. Het architectuurdiagram toonde Lambda en S3 omdat dat op een slide past; de echte code draaide op een laptop en een Vercel-preview.
Bij uitrol stelt het platformteam de basis-vragen. Waar leven de secrets? Hoe authenticeert de service tegen de databron? Waar gaan de logs heen? Wie wordt gepaged als het breekt? Niets in de pilot beantwoordde deze vragen omdat de pilot dat niet hoefde.
Fix het tijdens de pilot, niet erna. Bouw de pilot op dezelfde landing zone als alles anders. Gebruik dezelfde identiteit, dezelfde observability, hetzelfde paging-pad. De pilot is langzamer te shippen; de uitrol is sneller omdat er geen architecturale vertaling is.
Faalmodus 2: er was geen kwaliteitsignaal
De pilot werd geëvalueerd door engineers die naar de output keken. De output zag er meestal plausibel uit, soms gek, nooit rampzalig. Het team noemde het een succes.
Bij uitrol is de gebruikersbasis niet meer het engineeringteam. De gebruikersbasis kent het systeem niet goed genoeg om gekke output te spotten. Kwaliteitsregressies stapelen stilletjes op. Tegen de tijd dat iemand het merkt, is het dashboard dood omdat niemand keek.
Fix het met een geschreven evaluatieset. Twintig echte inputs, twintig verwachte outputs (of verwachte output-klassen wanneer het antwoord open is), en een CI-stap die de evaluatie draait op elke wijziging. Kwaliteitsregressie vangt zichzelf, op dezelfde manier als een unit test, met dezelfde saaie cadans.
"De pilot werkte omdat de engineers de gebruikers waren en de engineers ook de operators. Als ze de kamer verlaten, breken er drie dingen."
Sebastiaan van Parijs / Founder
Faalmodus 3: niemand schreef de faalmodus op
Elke AI-feature heeft een faalklasse die uniek voor hem is. RAG over policy-documenten faalt als de chunking-strategie de relevante clausule mist. Agentic workflows falen als het model de verkeerde tool kiest. Samenvatten faalt als de input vooral ruis is.
De pilot schreef zijn faalklasse niet op. Dus bij uitrol, wanneer een gebruiker tegen de fout aanloopt, weet niemand of het een bekende issue is, een regressie of een nieuw probleem. Het team triageert telkens vanaf nul. Tegen maand drie is het team uitgeput.
Fix het tijdens de pilot door de faalklasse te benoemen. Eén paragraaf in het runbook: dit verwachten we dat breekt, dit doen we als het breekt, dit is de fallback. Toekomstige fouten passen in het bestaande runbook of triggeren een runbook-update. Hoe dan ook, het team start niet bij nul.
Hoe een pilot eruitziet die schaalt
Zelfde platform-substraat als de rest van de services. Identiteit, secrets, observability, paging vanaf dag één. Een geschreven evaluatieset met een CI-gate. Een benoemde faalklasse met een geschreven runbook-entry. Kostenattributie op hetzelfde dashboard als de andere services van het team.
Het is langzamer om de eerste pilot zo te shippen. De tweede pilot is sneller. De vijfde pilot is veel sneller. Tegen de tijd dat het team pilots maandelijks levert, is de substraat het AI-platform van het bedrijf, is de evaluatie-harness gedeeld, en componeren de runbooks.
Dit is de saaie vorm. Hij demonstreert niet zo goed. Hij is wat schaalt.