Waarom AI-agenten in productie falen

Kort antwoord: AI-agents falen in productie meestal door het systeem rond het model, niet door het model zelf. De gebruikelijke oorzaken zijn een scope die op de demo is afgestemd, geen echte integratie met de bronsystemen, generieke context, stille fouten die niemand kan traceren, geen feedbackloop, en niemand die de uitkomst of de kosten bezit. We liepen tegen de meeste van deze problemen aan bij het bouwen van onze eigen outbound-prospectingagent. Hieronder lees je hoe je die van jou diagnosticeert, en wat we veranderd hebben om de onze stand te laten houden.

Waarom falen AI-agents in productie?

Het faalpercentage is niet anekdotisch. Gartner voorspelt dat meer dan 40% van de agentic-AI-projecten eind 2027 is geannuleerd, met als redenen oplopende kosten, onduidelijke businesswaarde en onvoldoende risicobeheersing. S&P Global Market Intelligence zag dat 42% van de bedrijven in 2025 de meeste van hun AI-initiatieven staakte, tegenover 17% een jaar eerder, en dat organisaties 46% van de proof-of-concepts schrapten voordat ze in productie gingen. Het NANDA-onderzoek van MIT legt het kernprobleem bij integratie en leren, niet bij modelkwaliteit. We behandelen het bredere plaatje in AI-agents in 2026: wat werkt echt en waarom de meeste initiatieven vastliepen.

In onze ervaring vallen die cijfers uiteen in zes faalpatronen:

1. Demoscope versus productierealiteit. Het prototype draaide op schone voorbeelddata en één happy path. Echte records zijn rommelig, onvolledig en vol edge cases.
2. Geen echte integratie. De agent kan niet lezen van of schrijven naar het bronsysteem, waardoor de output doodloopt in een chatvenster in plaats van iets te veranderen.
3. Generieke context. Een slimme prompt moet kennis van jouw business vervangen. Zonder retrieval over je eigen data en resultaten klinken antwoorden plausibel, maar zijn ze onjuist.
4. Stille fouten. Een verkeerde tool-call, een lege retrieval of een verzonnen veld ziet eruit als een normaal antwoord, tenzij elke stap getraceerd wordt.
5. Geen feedbackloop. De agent leert nooit welke outputs werkten, waardoor de kwaliteit afneemt terwijl je data en markt verschuiven.
6. Geen eigenaar voor waarde of kosten. Niemand bezit de businessmetric, token- en API-kosten groeien, en het project wordt bij de volgende budgetreview geschrapt.

Hoe herken je welke van deze jouw agent breekt?

Koppel het symptoom aan de oorzaak voordat je het model of de prompt verandert:

• Werkte in de demo en faalt op echte records: scope en data. Test tegen een steekproef van echte historische cases, niet handmatig uitgekozen.
• Output ziet goed uit, maar niemand handelt erop: integratie. Schrijf resultaten terug naar het CRM of ticketingsysteem waar mensen al werken.
• Antwoorden zijn generiek of overtuigend verkeerd: context. Veranker de agent in retrieval over je eigen records en resultaten.
• Je kunt niet verklaren waarom hij iets deed: observability. Traceer input, tool-calls, retrievals en output voor elke run.
• Was goed bij lancering en werd slechter: feedback. Voer echte resultaten op een vaste cadans terug in ranking en prompts.
• Kosten lopen op en niemand kan zeggen wat het oplevert: ownership. Koppel de agent aan één meetbare uitkomst, zoals we uitleggen in wat nodig is om ROI te halen uit AI-agents.

Hoe hebben we een outbound-agent gebouwd die het houdt in productie?

Bij Tekunda wilden we meer dan een demo in een vergaderzaal: een agent die outbound prospecting over LinkedIn en Salesforce automatiseert, redeneert over echte context en calls boekt. Elke stap hieronder bestaat omdat een van de faalpatronen hierboven ons eerst trof.

1. Begin bij één begrensde taak

De agent bezit één workflow: van een LinkedIn-leadlijst tot een geboekte call. Een zoekresultaat of Sales Navigator-lijst gaat naar Linked Helper, dat connectieverzoeken automatiseert binnen LinkedIn's wekelijkse limieten, bedank-follow-ups en de sync naar Salesforce. Zodra een nieuwe connectie in het CRM landt, neemt de agent het over.

2. Verankeren in je eigen resultaten

De agent redeneert over historische leaddata, inclusief conversiegeschiedenis, succescriteria en segmentkenmerken, als retrievalcontext. We testten zowel vector stores als PostgreSQL-gebaseerde retrieval en kozen op basis van prestaties en kosten, met chunking en retrieval afgestemd op leadkwalificatie in plaats van generieke zoekopdrachten.

3. Orchestreren met echte tooling, niet één gigantische prompt

De logica draait in Langflow, ondersteund door eigen Python-flows en onze interne MCP-servers die API-calls, enrichment en promptuitvoering afhandelen. De flow is stateless en opgedeeld in kleine micro-flows die we hergebruiken over campagnes heen. Wanneer één agent er meerdere worden, wordt de overdracht het volgende breekpunt, daarom schreven we op wat agent-naar-agent-overdrachten in productie laat werken.

4. Elke beslissing verrijken, scoren en verklaren

• Elke lead wordt verrijkt met een geverifieerd zakelijk e-mailadres via Findymail.
• De agent haalt signalen zoals functiewijzigingen, funding en tech stack op uit publieke bronnen via OpenAI search of Perplexity.
• Hij scoort elke lead op 100 op basis van gelijkenis met eerdere wins en schrijft een uitleg bij elke score, zodat een mens de redenering kan controleren.
• Alleen leads die boven 50 scoren krijgen outreach.

5. Terugschrijven naar het bronsysteem

Voor kwalificerende leads stelt de agent een gepersonaliseerde e-mail op uit bedrijfsinformatie, rolsignalen en recente activiteit, met een call-to-action gemodelleerd op wat werkte bij eerdere wins. Elke e-mail wordt teruggeschreven naar Salesforce, zodat sales dezelfde record ziet waarop de agent handelde.

6. Alles observeren en wekelijks itereren

We traceren elke agentoutput in Langfuse en interne dashboards, met gestructureerde foutafhandeling, prompt diffing en outcome-analyse die in de flow zijn ingebouwd. Conversiesignalen voeden terug in de ranking- en promptlagen, en elke week verfijnen we prompts, trainen we embeddings opnieuw en stellen we scoring bij. Die loop is het verschil tussen een agent die afbreekt en een agent die verbetert.

Het resultaat: geen handmatige overdracht van uitnodiging tot geboekte call. LinkedIn beperkt de bovenkant van de funnel, maar enrichment, scoring en e-mailgeneratie daarachter schalen mee met de pipeline.

Wat moet er klaarstaan voordat een agent live gaat?

• Eén meetbare uitkomst en een aangewezen eigenaar daarvan.
• Lees- en schrijftoegang tot het bronsysteem, met de minimale rechten die de taak nodig heeft.
• Een evaluatieset van echte historische cases, uitgevoerd voor elke prompt- of modelwijziging.
• Tracing voor elke stap: input, tool-calls, retrievals en output.
• Een menselijk controlepunt overal waar een fout duur is, zoals een scoredrempel of een goedkeuringsstap.
• Een feedbackloop op een vaste cadans, met echte resultaten als input.
• Een kostenbudget per uitkomst, beoordeeld samen met de businessmetric.

Als je agent binnen Salesforce leeft, bepaal dan vroeg of je configureert of bouwt: onze gids Agentforce versus custom AI-agents loopt die keuze door. En als je een agent zoals deze wilt laten bouwen rond je eigen workflow, bekijk dan hoe wij AI-agents voor productie bouwen of praat met ons team.

FAQ

Waarom werken mijn AI-agents in testen maar falen ze in productie?

Testen draaien meestal op schone data en één happy path. Productie voegt rommelige records, echte integraties en edge cases toe, en zonder tracing blijven die fouten stil.

Hoeveel AI-agentprojecten falen?

Gartner voorspelt dat meer dan 40% van de agentic-AI-projecten eind 2027 is geannuleerd, en S&P Global zag dat 42% van de bedrijven in 2025 de meeste van hun AI-initiatieven staakte.

Hoe monitor je een AI-agent in productie?

Traceer elke run, inclusief tool-calls en retrievals, en volg promptwijzigingen tegen resultaten. Tools zoals Langfuse in combinatie met interne dashboards maken agentbeslissingen debugbaar.

Moeten we een AI-agent intern bouwen of met een partner?

Het NANDA-onderzoek van MIT rapporteerde dat oplossingen die van gespecialiseerde leveranciers zijn gekocht veel vaker slagen dan interne bouwtrajecten. Bouw intern als de workflow kernactiviteit is en je observability en iteratie kunt bemannen.