# AI agent vs chatbot verschil: When infrastructure matters URL: https://notificationharbor.com/nl/journal/ai-agent-vs-chatbot-verschil Type: blog Locale: nl Published: 2026-07-14 Updated: 2026-07-15 --- > Een chatbot en een AI agent beantwoorden dezelfde vraag op verschillende manieren. Voor een emailstack hangt het verschil af van één ding: kan het systeem teruggschrijven naar je infrastructuur? ## AI agent vs chatbot verschil: When infrastructure matters Een chatbot en een AI agent beantwoorden dezelfde vraag op verschillende manieren. Vraag beide om een re-engagement email te schrijven: een chatbot geeft je een onderwerpregel en body copy van één LLM call. Een AI agent doet meer: het checkt de send history in je ESP, beslist op timing en kanaal, schrijft de record terug naar Postgres, en rapporteert wat er gebeurde. Het agent-vs-chatbot onderscheid dat voor een emailstack telt heeft niets met woordenschat te maken. Het gaat erom of het systeem kan handelen op je infrastructuur, of alleen beschrijven wat je volgende stap zou moeten zijn. Vendors hebben alle reden om die lijn te vervagen: "agent" heeft dit jaar een betere prijs dan "chatbot". ## De agent vs chatbot splitsing komt neer op één ding: schrijft het terug? Elke vendor pitch dit jaar gebruikt "agent" en "chatbot" uitwisselbaar. Het zijn niet dezelfde systemen. Een chatbot, zelfs een die op een frontier model draait, antwoordt met tekst: een suggestie, een concept, een samenvatting uit een kennisbank. Het schrijft nooit naar je database. Een AI agent draait in een lus. Het leest de staat, beslist op een actie, roept een tool aan, checkt het resultaat, en beslist of het opnieuw moet handelen. Die lus is het hele onderscheid. Alles daaronder, persoonlijkheid, reactiesnelheid, hoe goed de copy klinkt, verandert niet in welke categorie een tool thuishoort. Als je al een wrapper rond je ESP hebt gebouwd die send timing van een webhook payload beslist, heb je iets gebouwd dat meer op een agent lijkt dan de meeste producten die dit jaar zo worden vermarkted. "Agent" verkoopt beter dan "workflow engine met een LLM stap", zelfs als de tweede zin nauwkeuriger is, en die prijs-incentive is het waard om in gedachten te houden elke keer als een vendor het woord in een demo gebruikt. Vier criteria, chatbot versus agent, naast elkaar: - **Systemen die worden aangeraakt.** Chatbot: 0-1, leest context, geen write. Agent: 2+, leest en schrijft. - **Standaard latency.** Chatbot: 1-3s, één model call. Agent: 3-15s+, meerdere tool calls. - **Faalwijze.** Chatbot: foute of generieke copy. Agent: stil besluit, gedeeltelijke write. - **Write access.** Chatbot: geen. Agent: beperkt, gedefinieerd per tool. - **Geschikt voor.** Chatbot: onderwerpsregels, eenmalige composition. Agent: send-time besluiten, throttling, escalatie. ## Hoe de reasoning loop eruitziet op een lifecycle trigger Verwijder de buzzwords en de loop die onderzoekers "observe-reason-act-evaluate" noemen ziet er schoon uit op een lifecycle trigger. Hier is hoe het eruitziet op een echt activatiepad, in de volgorde waarin een agent het werkelijk zou uitvoeren. Eerst: observeren. Een Postgres CDC stream of een Segment webhook vuurt af als een trial user een usage threshold kruist. De agent ontvangt de event plus elke context waar het toegang tot heeft: plan tier, eerdere sends, dagen sinds signup. Twee: redeneren. Het model beslist wat de event betekent en of iets moet gebeuren. Heeft deze user een nudge nodig, of hebben ze er al een drie dagen geleden gehad? Is email het juiste kanaal, of heeft dit account alleen ooit geconverteerd vanuit in-app prompts? Derde: handelen. Als een send gerechtvaardigd is, roept de agent een functie aan, zoiets als een template tegen een berekende send time in de wachtrij zetten in plaats van een onmiddellijke blast. De functie voert uit tegen de ESP's API en de record wordt geschreven. Vierde: evalueren. De agent bevestigt dat de send klaar is, logt het resultaat, en beslist of de lus klaar is of dat een vervolgstap nog verschuldigd is: een Slack ping naar de growth lead, een CRM field update. Niets hiervan vereist een volledig autonoom systeem dat het hele send pipeline babysit. De meeste productie deployments limiteren de agent tot één smal besluit, timing en kanaal voor een enkel trigger type, en laten alles anders als deterministische code. Dat is geen compromis. Het is de juiste hoeveelheid autonomie voor een baan die meestal geen oordelen nodig heeft. Teams die een general-purpose agent het hele pipeline overhandigen besteden meestal meer tijd aan debuggen waarom een send niet afvuurde dan ze sparen doordat ze het bouwen. ![Close-up van een hand die een mechanisch relais paneel aanpast, industriële metafoor voor geautomatiseerde routing en triggers](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-07/9f5a57-inline1.webp) ## De meeste tools die als "AI email agent" worden verkocht zijn één LLM call in een trenchcoat Gartner's beoordeling van de bredere agentic AI markt is blunt: het bedrijf voorspelt dat [meer dan 40% van agentic AI projecten tegen het einde van 2027 geannuleerd zullen worden](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027), grotendeels omdat de systemen nooit de tool access of data architectuur hadden om autonoom te handelen. Email tooling is niet uitgesloten van dat patroon. Open de feature pagina van de meeste "AI email agent" producten die dit jaar vermarkted worden en je vindt één LLM call: plak je brand voice in, krijg drie onderwerpregel varianten terug. Dat is een chatbot met een goede prompt template. Het is handig. Het is niet een agent, en het noemen van agent stelt de verkeerde verwachting voor wat het hulpmiddel onbewaakt zal doen. Dit is geen marketing feature. Het is een infrastructuur constraint. Een agent heeft een gedefinieerd tool schema nodig, write access naar de systemen waar het op zou moeten handelen, en een manier om te evalueren of zijn actie succesvol was. Sla een van die drie over en je hebt een chatbot met een ambitieus label gebouwd, niet een systeem waar je zonder menselijke review elk output zou vertrouwen op live sends. De gevestigde ESPs zijn, tot hun eer, grotendeels eerlijk over waar ze zitten hierop. Klaviyo en Customer.io zenden LLM-ondersteunde copy generatie, eenmalige, chatbot-vormig, en claimen niet dat het autonoom handelt. Mailchimp's en Brevo's send-time features liggen dichter bij statistische modellen dan LLM agents, wat een verdedigbare engineering keuze is gegeven de taak. Resend vermarktet helemaal geen "AI agent", wat, gezien hoeveel van deze categorie agent-washing is, leest als terughoudendheid in plaats van een gat. De chat-to-workflow interface van Copy.ai is een nuttig voorbeeld van de middengrond. Op de entry tier is het nog fundamenteel een chatbot: één prompt, één output. De workflow credits die multi-stap automatisering ontgrendelen verschijnen alleen zodra een team betaalt voor de Growth tier en hoger, wat een eerlijke afspiegeling is van waar de echte engineering cost zit. ## Plain-English campaign composition is een chatbot probleem, geen agent probleem Een send in plain English samenstellen, schrijf een re-engagement email voor users die niet hebben ingelogd in 14 dagen, houd het onder 120 woorden, match onze tone, is een eenmalige taak. Het model leest instructies, genereert copy, klaar. Die in agent infrastructuur wikkelen voegt latency en kost toe zonder nauwkeurigheid toe te voegen. Dit is de meest voorkomende plaats waar teams te veel engineering. Een composition tool heeft één LLM call nodig en een goed geschreven system prompt. Het heeft geen geheugen in sessies, geen tool-calling loop, en geen write access naar je ESP. Bewaar de agent architectuur voor taken die werkelijk meerdere stappen vereisen en een besluit over of je wil handelen. ChatGPT's Agent mode is een goed voorbeeld van hoe wazig dit in één product kan worden. Het chat oppervlak is nog steeds een eenmalige chatbot voor de meeste verzoeken; Agent mode is erbovenop gelaagd voor de subset van taken die multi-stap browsing of file work nodig hebben. De meeste teams die campaign copy samenstellen hoeven nooit het chatbot deel van dat product te verlaten. De test die we zouden toepassen: vermenigvuldig de complexiteit van het verzoek met het aantal systemen dat het aanraakt met of een actie zonder mens in de lus moet gebeuren. Laag op alle drie, een chatbot-stijl call is het juiste en goedkopere hulpmiddel. Hoog op een van hen, je hebt de lus nodig. ## Send-time optimization en throttling is waar de agent loop zijn kost rechtvaardigt Per-recipient send-time optimization is het duidelijkste geval voor een echte agent loop in een email stack. Het systeem moet het historische open pattern van een recipient lezen, de huidige domein reputatie en warmup stage checken, besluiten op een send window, en bevestigen dat de send klaar is voordat naar de volgende recipient in de batch gaat. Dat zijn vier systemen die één besluit aanraken: het engagement geschiedenis van de recipient, de warmup status van het domein, de ESP's rate limits, en het resultaat van de send zelf. Een enkele LLM call kan al die staat niet vasthouden en erop handelen. Het moet de lus hebben, en het moet tool access naar de warmup automation die sends pauzeer wanneer reputatie daalt. Een growth lead die lifecycle email op een 40k-user base draait vertelde ons dat de switch van een vaste negen-a.m. send naar een per-recipient window drie weken duurde om in productie op te vertrouwen, grotendeels doorgebracht met het kijken of de throttle logic onder een spam-rate spike vast hield in plaats van het afstellen van de copy. Dat is de echte engineering cost van de lus: niet de model call, het vertrouwen dat de write-back correct gedraagt onder een slechte week. Lindy is een nuttig referentiepunt hier, niet omdat het specifiek voor lifecycle email gebouwd is, maar omdat zijn inbox-triage en follow-up loop dezelfde vorm is: lees staat, beslis, handel, bevestig, herhaal, beperkt tot een smalle terugkerende baan in plaats van een general-purpose assistent. Manus neemt de general-purpose versie van dezelfde lus en wijst het op open-ended taken, browsing, file generatie, multi-stap onderzoek, in plaats van één smal terugkerend besluit. Het is een nuttig referentiepunt voor het beperken van hoeveel autonomie je werkelijk wil in een productie send pipeline versus hoeveel een demo je wil laten overhandigen. Nieuwe product was gebouwd voor lifecycle email. Het architectuur patroon is het punt, niet het product. ![Wide shot van een leeg engineering kantoor in het schemerdonker met monitors gloeiend, bureaustoel aan, lege stoel](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-07/4e1ca6-inline2.webp) ## Wat de loop werkelijk kost, per send Elke tool call in de lus is een netwerkronde plus token kost. Een chatbot-stijl composition call draait één tot drie seconden en één model invocation. Een agent loop die drie tool calls maakt om warmup status te checken, een window te besluiten, en delivery te bevestigen draait langer, en elke stap is een plek waar de chain kan falen. Op het trace niveau, hier is wat werkelijk verschijnt als teams loop-gebaseerde send-time besluiten aan een lifecycle flow toevoegen: latency per besluit gaat van low-second naar multi-second, en de faalwijze verandert van "foute copy" naar "stil besluit, geen send gebeurde." Geen van beide is gratis, maar ze zijn verschillende operationele problemen en ze hebben verschillende monitoring, verschillende alerting, en verschillende on-call runbooks nodig. De [ReAct paper](https://arxiv.org/abs/2210.03629) die deze lus zijn naam gaf stelde dat de tradeoff het waard is specifiek als een taak externe informatie mid-reasoning nodig heeft, niet voor taken die het model al van zijn eigen context kan beantwoorden. Een onderwerpregel heeft geen externe informatie nodig. Een send-time besluit wel. Dat is de lijn die het waard is om te trekken voordat je beide bouwt. Weggewogen tegen headcount, de berekening begunstigt nog steeds de lus voor alles echt multi-stap: een mens die elk send-time besluit herziet schaalt niet voorbij een paar honderd users per dag, en de lus, eenmaal vertrouwd, wel. De fout is diezelfde wiskunde op eenmalige composition toepassen, waar menselijke review nooit het bottleneck was om te beginnen. ![Eenvoudig architectuur diagram contrast een enkel lineair flow tegen een circulaire multi-stap loop met pijlen, abstract minimalistisch stijl, geen leesbare tekst](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-07/bdbb4b-inline3.webp) ## Wat we werkelijk zouden bouwen Begin met de chatbot-vormige versie van elke nieuwe email mogelijkheid. Één LLM call, één duidelijke input, één output, herzien door een mens voordat het een live send aanraakt. Als die versie Ships en het team houdt niet op met het bereiken van zijn limiet, meestal een taak die data van meer dan één systeem nodig heeft of een besluit dat zonder toezicht moet gebeuren, dat is het signaal om de lus te bouwen. De meeste lifecycle stacks hebben geen general-purpose agent nodig die het hele pipeline babysit. Ze hebben twee of drie smal bereikende lussen, send-time besluiten, throttle-and-pause logica, misschien escalatie routing, zittend naast veel deterministische code die helemaal geen LLM nodig heeft. De AI agent vs chatbot vraag is niet werkelijk over welke het best is. Het gaat over het aanpassen van de architectuur aan hoeveel systemen een besluit werkelijk aanraakt, en eerlijk zijn over welke je werkelijk hebt gebouwd voordat je het Ships. ## FAQ ### Wat is het verschil tussen een AI agent en een chatbot? De kernverschil is write-access. Een chatbot leest je input en geeft een antwoord terug. Een AI agent leest de staat van je systemen, beslist op actie, schrijft records terug, en verifieert. Een agent is eigenlijk een chatbot in een lus. ### Waarom zou je een agent nodig hebben voor email? Voor taken die meerdere systemen aanraken en zelf moeten beslissen zonder menselijke controle. Send-time optimisatie, throttling op basis van reputatie, en escalatie routing zijn echte agent-werk. Onderwerpsregels schrijven is niet. ### Zijn alle 'AI email agents' echte agents? Nee. Veel producten die als agents worden vermarkted zijn eigenlijk chatbots: één LLM call, geen write access. Ze genereren suggesties, maar raken je infrastructuur niet aan. Gartner voorspelt dat meer dan 40% van agentic AI projecten tegen 2027 geannuleerd zullen worden, veel vanwege dit exact probleem. ### Hoe meet je of je een agent of chatbot nodig hebt? Pas deze test toe: vermenigvuldig (taak complexiteit) × (aantal systemen) × (moet onbewaakt handelen). Laag op alles = chatbot. Hoog op een = agent. Subject lines schrijven is chatbot werk. Send-time per user is agent werk. ### Wat zijn de verborgen kosten van een agent loop? Latency: chatbot is 1-3s, agent is 3-15s+. Faalwijze verandert van "foute copy" naar "stil, geen send". Je nodig veel betere observability. Voor eenmalige compositie is het niet de moeite waard. ### Kunnen de grote ESPs (Klaviyo, Mailchimp) agent-achtige send-time optimisatie doen? Klaviyo en Customer.io doen LLM-assisted copy gen (chatbot). Mailchimp en Brevo gebruiken statistische modellen, niet LLM. Niemand noemt het 'agent' omdat het niet werkelijk één echte multi-stap lus is. ### Hoe scoop je de autonomie van een agent in productie? Start smal: één trigger type, één besluit (timing of channel). Laat de rest deterministische code. Een agent die het hele pipeline bestuurt is over-engineered. Meeste teams hebben 2-3 smal bereikende lussen, niet één general-purpose agent nodig.