Agent of automatisering: hoe kies je het juiste?

Voor wie? Developers en teams die LLM-gebaseerde systemen bouwen en moeten beslissen wat ze eigenlijk bouwen: een agent, een workflow, of een combinatie van beide.

Kort: Een agent en een geautomatiseerde workflow lossen andere problemen op. Veel teams grijpen standaard naar een agent terwijl een workflow volstaat — en betalen de prijs in complexiteit, kosten en onvoorspelbaar gedrag. Dit artikel geeft je drie vragen om het onderscheid te maken. Dezelfde beslissingslogica werkt door in de tweedaagse workshop voor developers.

Ergens halverwege een project besluit iemand: “We bouwen hiervoor een AI-agent.” Het klinkt goed. Agents zijn flexibel, intelligent, kunnen omgaan met onverwachte invoer. Waarom zou je minder doen?

Maar twee maanden later draait er een systeem dat elke stap opnieuw evalueert terwijl dat niet nodig is, dat inconsistente beslissingen neemt op plekken waar determinisme goedkoop en afdoende is, en dat moeilijk te debuggen is omdat er geen vaste stroom meer is. De agent beheert de gehele pipeline — ook de stappen die gewoon een if-statement nodig hadden.

Het omgekeerde is ook een probleem. Een team bouwt een geautomatiseerde workflow voor een taak die te variabel is voor deterministische stappen. De workflow breekt op randgevallen. Er komen steeds meer conditionele takken bij. Uiteindelijk is het een fragiel stelsel van speciale gevallen dat bij elke nieuwe invoervorm opnieuw onderhoud vraagt.

Beide fouten komen voort uit hetzelfde gebrek: geen helder criterium om te kiezen.

Twee patronen, twee sterktes

Een geautomatiseerde workflow voert vaste stappen uit in een vaste volgorde. Gegeven invoer X, altijd uitvoer Y. Elke stap is deterministisch. Denk aan een ETL-pipeline, een formulier dat een e-mail triggert, een if-this-then-that-keten.

De kracht van een workflow: voorspelbaar, goedkoop, testbaar, makkelijk te debuggen. Als er iets misgaat, is de fout zichtbaar en de oorzaak traceerbaar. De zwakte: breekt zodra de invoer buiten de verwachte grenzen valt.

Een agent gebruikt een taalmodel om bij elke stap te beslissen wat de volgende stap is. De stappen liggen niet vast — ze worden bepaald op basis van de huidige situatie. De kracht: kan omgaan met variabele invoer, onvoorziene situaties, ambiguïteit. De zwakte: minder voorspelbaar, duurder per taak, moeilijker te debuggen omdat er geen vaste stroom is om tegen te redeneren.

Het zijn niet twee gradaties van hetzelfde. Het zijn twee architectuurpatronen die andere problemen oplossen.

Drie vragen om het te beslissen

1. Is het pad deterministisch?

Kun je alle stappen en vertakkingen op voorhand vastleggen — ook voor randgevallen?

Als ja: een workflow volstaat. Je hoeft geen taalmodel in te schakelen om te beslissen wat de volgende stap is als je dat van tevoren al weet.

Als nee — als het pad afhangt van context die je op bouwmoment nog niet kent — dan overweeg je een agent.

2. Is de invoer gestructureerd en afgebakend?

Verwerkt het systeem altijd gestructureerde data: JSON, CSV, database-records met een vastgelegd schema?

Als ja: een workflow volstaat. Deterministische code kan gestructureerde data verwerken zonder een LLM nodig te hebben.

Als nee — vrije tekst, gebruikersinvoer, externe documenten, e-mails, PDF’s met variabele lay-out — dan heeft een stap een agent nodig om die invoer te interpreteren.

3. Is een stille fout acceptabel?

Wat gebeurt er als het systeem een onverwachte situatie tegenkomt?

Bij een workflow breekt de pipeline. De fout is zichtbaar, herstelbaar, en het systeem staat stil totdat iemand de oorzaak aanpakt. Dat is vervelend, maar eerlijk.

Bij een agent neemt het model een beslissing. Mogelijk de juiste. Mogelijk niet. Maar de agent markeert dit niet als fout — de output ziet er gewoon uit. Als de gevolgen van een stille verkeerde beslissing niet acceptabel zijn, kies dan voor automatisering met expliciete foutafhandeling, ook als dat meer boilerplate kost.

Hybride architectuur: de pragmatische keuze

De meeste productiesystemen die goed werken combineren beide patronen: een deterministische workflow als ruggengraat, met agents op de specifieke stappen die variabele invoer verwerken.

Een documentverwerkingspipeline als voorbeeld:

• Stap 1 — PDF ontvangen en opslaan. Deterministische bestandsoperatie. Geen agent nodig.
• Stap 2 — Sleuteldata extraheren uit de PDF. Vrije tekst, variabele lay-out. Hier heeft de stap een agent nodig.
• Stap 3 — Geëxtraheerde data valideren tegen een schema. Deterministisch. Geen agent nodig.
• Stap 4 — Opslaan in database. Deterministisch. Geen agent nodig.

Alleen stap 2 rechtvaardigt een LLM-aanroep. De rest is gewone code. De agent-complexiteit is afgebakend tot de stap die hem werkelijk nodig heeft. De rest van het systeem blijft voorspelbaar en goedkoop.

Dit is ook de kostendimensie: een LLM-aanroep kost een veelvoud van een deterministische berekening. Voor een systeem dat duizend keer per dag draait, is het verschil materieel. De richtlijn is simpel — gebruik een agent alleen voor de stappen die het vereisen.

De meest gemaakte fout

“We bouwen een AI-agent die onze gehele workflow beheert.”

Het klinkt ambitieus, maar het is een architectuurkeuze die je systeem onnodig kwetsbaar maakt. De agent neemt beslissingen op elke stap, ook waar dat niet nodig is. Elke stap wordt duurder, minder voorspelbaar, en moeilijker te testen.

De betere aanpak: begin met een deterministische workflow. Identificeer de stappen die werkelijk te variabel zijn voor vaste logica. Vervang precies die stappen door een agent. De rest blijft gewone code.

Het resultaat is een systeem waarvan je de agent-stappen kunt isoleren, testen en vervangen zonder de rest aan te raken — en waarvan de deterministische stappen zich gedragen zoals je verwacht.

Het agent-of-workflow-beslissingsproces is een van de eerste architectuurvragen die je stelt in de tweedaagse workshop voor developers. Je werkt er hands-on door: een systeem ontleden, de juiste stappen identificeren, en de hybride architectuur opzetten die past bij de invoer en de foutvereisten van je specifieke use case.