# aiagentdevelopment.info — volledige tekst

> De volledige tekst van elke gids in deze taal, zodat een antwoordmachine de catalogus in één verzoek kan lezen. Niets hiervan ontbreekt op de zichtbare pagina’s.

## Een agentroadmap die echt productie haalt
https://aiagentdevelopment.info/nl/guides/roadmap-voor-agentontwikkeling
Bijgewerkt op 2026-08-05 · Kosten en business

- Vier fasen met geschreven uittredetests: scope, prototype, verharding, lancering.
- Verharding is de langste en meest onderbegrote fase.
- Lanceer beperkt en verbreed op cijfers, niet op de kalender.
- Na de lancering is het een dienst: eigenaar, groeiende evaluatie, herkwalificatie.

Het faalpatroon van agentprojecten is niet technisch. Het is een goed prototype in week drie, gevolgd door drie maanden ongerichte verbetering en een stille annulering omdat niemand kon zeggen of het klaar was.

Deze roadmap repareert dat met uittredetests. Elke fase heeft een voorwaarde die vóór de fase wordt opgeschreven en die wel of niet gehaald wordt.

### Fase 1 — Scope (1–2 weken)
Schrijf de taak op als één zin die iemand goed of fout kan rekenen. Noteer de tools met hun argumentschema's. Bepaal welke handelingen onomkeerbaar zijn. Verzamel twintig echte voorbeelden.
Uittredetest: een collega die niet bij de overleggen was leest de briefing en beoordeelt vijf voorbeeldruns correct.

### Fase 2 — Prototype (2–3 weken)
Bouw de kleinste lus die de taak doet met echte tools in een testomgeving. Draai uw twintig cases, bekijk elke storing en repareer het toolontwerp vóór de prompt.
Uittredetest: 60% van de twintig cases slaagt end-to-end, en naast elke storing staat een vastgestelde oorzaak.

### Fase 3 — Verharding (3–5 weken)
Hier zit het meeste echte werk en hier sterven onderbegrote projecten. Rechten op de identiteit van de eindgebruiker, poorten voor het onomkeerbare, argumentvalidatie, leesbare traces, monitoring, een evaluatieset gegroeid naar vijftig cases inclusief vijandige, en een degradatiemodus.
- Autorisatie serverzijde gecontroleerd bij elke toolaanroep.
- Menselijke poort vóór elke onomkeerbare handeling.
- Stappen- en uitgavenlimieten plus herhalingsdetectie.
- Traces met run-ID op elke aanroep en een bewust gekozen bewaartermijn.
- Vijandige cases in de evaluatie, gedraaid als elke andere test.
Uittredetest: 85% op de set, 100% op de weiger-subset en geen openstaande beveiligingsbevinding.

### Fase 4 — Lancering (2 weken, daarna doorlopend)
Start met een beperkt publiek. Lees dagelijks runs. Houd het escalatiepad zichtbaar en bemand. Verbreed als de cijfers twee weken standhouden, niet omdat de kalender het zegt.
| 1 | Alleen intern team | Traces, duidelijke storingen, toolfouten |
| 2 | 5% van echt verkeer | Escalatiepercentage, slaagpercentage |
| 3–4 | 25% | Kosten per taak, latency in de piek |
| 5+ | Volledig als de cijfers houden | Drift, nieuwe categorieën |

Q: Twaalf weken lijkt lang voor een demo van drie dagen.
A: De demo werkte echt. De resterende negen weken zijn rechten, evaluatie, monitoring en faalpaden.

Q: Mogen fasen overlappen?
A: Verharding mag tijdens het prototype beginnen, en zou dat voor rechten moeten. Start geen lancering vóór de verhardingstest is gehaald.

Q: En als het prototype de test niet haalt?
A: Kijk naar de genoteerde oorzaken. Zijn het toolontwerp en datatoegang, repareer die. Vraagt de taak een oordeel dat niemand kan definiëren, stop dan.

## AI-agenttoepassingen per sector: wat echt werkt
https://aiagentdevelopment.info/nl/guides/toepassingen-per-sector
Bijgewerkt op 2026-08-05 · Kosten en business

- Agents blijven waar de taak smal is, een administratiesysteem bestaat en risico's afgeschermd zijn.
- Interne afstemming, triage en concepten zijn de betrouwbaarste eerste successen.
- Projecten lopen vast op ontbrekende API's, definities of eigenaars — niet op modelgrenzen.
- Begin in gereguleerde sectoren aan de conceptkant en verbreed autonomie op bewijs.

Lijsten met toepassingen lezen meestal als verlanglijstjes. Deze komt uit wat daadwerkelijk in productie komt en daar blijft — een veel kortere en herhalender lijst dan de marketing suggereert.

Het patroon is consistent over sectoren. Een smalle taak met een heldere definitie van klaar, twee of drie tools tegen een echt administratiesysteem, en een mens vóór alles wat niet ongedaan te maken is.

### Wat werkt, per sector
| E-commerce | Orderstatus, retourrecht, adreswijziging | Order opzoeken, beleid, adres bijwerken | Terugbetalingen boven een grens |
| SaaS-support | Eerstelijnstriage met accountcontext | Account opzoeken, docs zoeken, ticket bijwerken | Planwijzigingen, credits |
| Finance operations | Facturen matchen met inkooporders | ERP lezen, document parsen, afwijking markeren | Elke betaling |
| Zorgadministratie | Afspraken plannen en herinneren | Agenda, patiëntdossier lezen | Alles klinisch |
| Recruitment | Screening op expliciete criteria, plannen | ATS lezen, agenda, mailconcept | Afwijzingen en aanbiedingen |
| Logistiek | Uitzonderingen bij vertraging | Tracking, vervoerder-API, klantmelding | Compensatieaanbiedingen |

### De interne agents waar niemand over schrijft
De betrouwbaarste successen zijn onopvallend en intern: twee systemen die van elkaar afwijken afstemmen, de eerste versie van een terugkerend rapport opstellen, binnenkomende verzoeken met context in de juiste wachtrij zetten en beleidsvragen met bronvermelding beantwoorden.

### Waar projecten vastlopen, in elke sector
- Geen administratiesysteem met API — de agent heeft geen vaste grond.
- Geen gedeelde definitie van een juiste uitkomst, dus niemand kan beoordelen.
- Oordeelsrijke taak met nul risicobereidheid: alles gaat door een poort en de waarde verdwijnt.
- Onduidelijk eigenaarschap: gebouwd door innovatie, nodig voor operations, niemand piket.

### De eerste kiezen
Scoor kandidaten op vier assen: volume, herhaalbaarheid van de stappen, bestaan van een administratiesysteem en omkeerbaarheid van de handelingen. Het beste eerste project is hoog volume, sterk herhalend, ondersteund door een API en omkeerbaar.
Kies bewust iets waar een fout gênant is en niet duur.

Q: Welke sector heeft de duidelijkste successen?
A: E-commerce en SaaS-support, omdat de taken hoog volume zijn en de meeste handelingen omkeerbaar.

Q: Zijn ze nuttig voor kleine bedrijven?
A: Ja, meestal in de interne vorm: triage, concepten, afstemming.

Q: Hoe schat ik de waarde vóór de bouw?
A: Tel het volume, meet de huidige menselijke tijd en schat het deel dat de agent zonder hulp afrondt.

## De ROI van een AI-agent meten zonder uzelf voor de gek te houden
https://aiagentdevelopment.info/nl/guides/roi-van-agents-meten
Bijgewerkt op 2026-08-05 · Kosten en business

- Schrijf de nulmeting vóór de lancering op — volume, tijd, kosten, foutpercentage.
- Tel taken afgerond zonder mens, geen deflectie of berichten.
- Trek foutkosten en reviewtijd af; die aftrek maakt het getal geloofwaardig.
- Rapporteer kwalitatieve voordelen apart in plaats van als verzonnen geld.

De meeste ROI-cijfers van agents overleven geen nauwkeurige lezing, en de reden is bijna altijd dezelfde: de nulmeting werd achteraf gereconstrueerd en de fouten bleven buiten de som.

Een eerlijk getal is niet moeilijk, maar het moet vóór de lancering beginnen. Schrijf op wat het vandaag kost, in de eenheden die u later gebruikt.

### Schrijf eerst de nulmeting op
- Volume: hoe vaak gebeurt deze taak per week?
- Afhandeltijd: hoe lang doet iemand erover — gemeten op een steekproef?
- Volledig belaste kosten per uur.
- Huidige kwaliteit: fout- of herstelpercentage.
- Wachttijd: hoe lang wacht de aanvrager vandaag, als dat telt.
Een achteraf gereconstrueerde nulmeting bevoordeelt altijd het project, en elke beoordelaar weet dat.

### Cijfers die standhouden en cijfers die vleien
| Deflectiepercentage | Telt onbeantwoord als opgelost | Taken afgerond zonder mens |
| Afgehandelde berichten | Volume is geen waarde | End-to-end afgeronde taken |
| Tevredenheid in agentchats | Overlevingsbias | Tevredenheid over alle contacten |
| Bespaarde tijd per antwoord | Negeert reviewtijd | Nettominuten na menselijke review |
| Kosten per token | Geen bedrijfsgetal | Kosten per afgeronde taak |

### De formule, inclusief het weggelaten deel
Jaarlijks voordeel = taken afgerond zonder mens × bespaarde minuten per taak × volledig belaste kosten per minuut — minus de kosten van fouten die de agent veroorzaakte, minus de reviewtijd die hij creëerde. Die aftrek is het eerlijke deel.
Schat foutkosten expliciet, al is het grof.

### Wanneer het eerlijke antwoord nee is
Soms zegt de rekensom stoppen, en dat uitspreken is het waardevolste van de oefening. Taken met laag volume verdienen een bouw zelden terug. Taken waarvan de uitvoer toch nagekeken moet worden besparen alleen reviewtijd.

Q: Welk afrondingspercentage is realistisch?
A: Zestig tot tachtig procent van een goed afgebakende taak met hoog volume, de rest geëscaleerd.

Q: Hoe lang tot terugverdienen?
A: Bij een goed gekozen interne taak meestal zes tot twaalf maanden inclusief onderhoud.

Q: Hoe tel ik waarde als de agent alleen opstelt?
A: Meet de tijd van blanco pagina tot goedgekeurde uitvoer, voor en na.

## AI-agentontwikkelaars aannemen: waarop letten en hoe testen
https://aiagentdevelopment.info/nl/guides/agentontwikkelaars-aannemen
Bijgewerkt op 2026-08-05 · Kosten en business

- Neem systeemengineers aan die in faalmodi denken, geen promptspecialisten.
- Selecteer met een briefing: schema's, stopvoorwaarden, tien cases, menselijke poorten.
- Frameworkkennis voorspelt succes het slechtst.
- Eis overdracht van prompts, schema's, evaluatie en traces.

De functietitel is nieuw, de vaardigheid niet. Wie agents bouwt die productie overleven zijn gewone sterke engineers die geleerd hebben te werken met een component die snel, capabel en af en toe zelfverzekerd fout is.

Die herformulering maakt aannemen veel makkelijker. U zoekt geen promptspecialist. U zoekt iemand die instinctief vraagt wat er gebeurt als de tool niets teruggeeft.

### Wat telt, op volgorde
- API- en integratiewerk: het meeste werk is netjes praten met uw systemen.
- Testinstinct: ze vragen naar evaluatie voordat ze naar het model vragen.
- Denken in faalmodi: lege resultaten, rechten, timeouts, gedeeltelijk succes.
- Beveiligingsbesef: minimale rechten, injection, audittrails, poorten.
- Kostenbesef: ze kunnen zonder opzoeken uitleggen waar tokens heen gaan.
- Modelbekendheid: nuttig, in weken te leren.
- Frameworkkennis: het minst belangrijke en het meest geadverteerde punt.

### Een selectieoefening van negentig minuten die werkt
Geef een korte briefing: een agent die ordervragen beantwoordt en terugbetalingen onder vijftig euro mag doen. Vraag om de toollijst met argumentschema's, de stopvoorwaarden, tien evaluatiecases en wat achter een menselijke poort staat. U zoekt geen code.
Sterke kandidaten stellen in de eerste vijf minuten vragen over rechten en randgevallen. Dat is het betrouwbaarste signaal.

### Vragen die ervaring van enthousiasme scheiden
| Hoe weet u dat een wijziging hielp? | We testen handmatig | Een vaste evaluatieset, voor en na |
| Wat doet u als een tool niets teruggeeft? | Opnieuw proberen | Een expliciet leeg resultaat waarop de agent kan handelen |
| Hoe stopt u injection? | Het model zeggen het te negeren | Minimale rechten, isolatie, poorten |
| Waarom was uw laatste agent traag? | Het model was traag | Zes seriële aanroepen; twee geparallelliseerd |
| Hoe kiest u een model? | Het beste | Per stap, gemeten op onze cases |

### Bureau, freelance of intern
Een bureau past bij een eerste bouw met een deadline: u koopt een team dat de standaardfouten al heeft gemaakt, en u moet overdracht van evaluatieset en toolschema's eisen. Intern is juist zodra de agent onderdeel wordt van het product.

Q: Heb ik een machine learning engineer nodig?
A: Meestal niet. Dit is systeemengineering tegen een model-API.

Q: Hoe groot moet het team zijn?
A: Twee engineers en een parttime domeinexpert dekken de meeste eerste projecten.

Q: Wat moet een bureau opleveren?
A: Repository, prompts, toolschema's, evaluatieset met resultaten, traces van de laatste maand, een dashboard en een notitie over bekende faalmodi.

## Kosten van AI-agentontwikkeling: echte cijfers en wat ze drijft
https://aiagentdevelopment.info/nl/guides/kosten-agentontwikkeling
Bijgewerkt op 2026-08-05 · Kosten en business

- Interne agents kosten vaak $8k–$45k; klantgerichte $35k–$150k.
- Integraties, evaluatie en rechten domineren de uren; prompts zijn de kleinste post.
- Draaikosten zijn meestal bescheiden en halveren met routinewerk.
- Begroot 15–25% van de bouwkosten per jaar en wijs een eigenaar aan.

Niemand kan uw project vanaf een webpagina begroten, maar de bandbreedtes zijn ook geen mysterie, en de vorm van de raming is opvallend constant in de projecten die wij deden en beoordeelden.

De drie getallen die u nodig heeft zijn bouwen, draaien, onderhouden. Teams onderhandelen hard over het eerste, maken zich zorgen over het tweede en vergeten het derde volledig — daarom zijn zoveel agents acht maanden na de lancering stilletjes kapot.

### Bouwkosten per scope
| Interne assistent, 2–3 leestools | $8.000–$20.000 | Lus, tools, retrieval, kleine evaluatieset |
| Interne agent met schrijfrechten | $20.000–$45.000 | Plus rechten, audit, goedkeuringspoorten |
| Klantgerichte supportagent | $35.000–$90.000 | Plus escalatie, toon, monitoring, belasting |
| Agent in uw product | $60.000–$150.000+ | Plus interface, multi-tenant, SLA, versionering |
| Alleen proof of concept | $5.000–$12.000 | Eén pad, geen rechten, niet leverbaar |

### Waar de uren echt heen gaan
De verdeling verrast wie verwacht dat het model het project is. Grofweg: integraties en toollaag 30%, evaluatie en iteratie 20%, rechten, audit en beveiliging 15%, monitoring en operationele tooling 10%, prompt- en retrievalwerk 15%, en de lus zelf ongeveer 10%.
Ontbreekt een evaluatiepost in een offerte, dan koopt u een demo.

### Draaien kost minder dan gevreesd
Bij een typische supportagent kost een afgeronde taak tussen een paar cent en enkele tientallen centen aan modelaanroepen. Bij tienduizend taken per maand is dat echt geld, maar zelden het dominante getal naast het werk dat het verving.

### De vergeten post: onderhoud
- Modelafbouw: één of twee keer per jaar herkwalificeren op een nieuwe versie.
- API-drift: de systemen achter uw tools veranderen ongevraagd.
- Retrievalonderhoud: documenten veranderen en een verouderde index is erger dan geen.
- Groei van de evaluatie: nieuwe gebruikers brengen nieuwe faalcategorieën.
- Eigenaarschap: iemand moet bereikbaar zijn als de agent iets vreemds doet.
Begroot 15–25% van de bouwkosten per jaar. Een agent is een dienst, geen project dat eindigt.

Q: Waarom lopen offertes zo uiteen?
A: Omdat de briefing zelden zo concreet is als hij voelt. Een offerte met rechten, evaluatie, monitoring en onderhoud is een ander product.

Q: Kunnen we kleiner beginnen?
A: Ja. Eén smalle taak, twee leestools en twintig evaluatiecases liggen vaak op $8.000–$15.000.

Q: Is intern goedkoper?
A: Goedkoper in cash, duurder in tijd, en alleen als iemand met ervaring het bezit.

## AI-agents opschalen: latency, concurrency en rate limits
https://aiagentdevelopment.info/nl/guides/agents-opschalen
Bijgewerkt op 2026-08-04 · Productie en beheer

- Het knelpunt is providerquotum, niet uw servers.
- Scheid interactief en achtergrondverkeer en zet het tweede in de wachtrij.
- Stream, toon echte voortgang en geef bruikbare deelresultaten bij limieten.
- Bouw de degradatiemodus achter een schakelaar vóór een incident u dwingt.

De eerste verkeerspiek leert elk team dezelfde les. Uw servers zijn bijna stil, de database is in orde en alles is traag — omdat elk verzoek meerdere seconden durende aanroepen zijn naar een provider met quota, en quota kan niet schelen hoeveel containers u startte.

Agents opschalen is daarom vooral wachtrijtheorie en verwachtingsmanagement, plus wat capaciteitsplanning.

### Weet welke van de drie limieten u raakt
| 429 van de provider | Verzoeken of tokens per minuut | Wachtrij, backoff, spreiden over sleutels of regio's |
| Traag maar zonder fouten | Seriële aanroepen per run | Onafhankelijke stappen parallelliseren |
| Geheugen of connecties op | Uw eigen service | Gewoon capaciteitswerk |
| Alleen traag in de piek | Concurrentie om gedeeld quotum | Prioriteitswachtrij |

### Zet alles wat niet interactief is in de wachtrij
Splits verkeer vanaf dag één in twee klassen. Interactief werk — iemand wacht — krijgt een korte deadline, een strakke stappenlimiet en een snel model waar kwaliteit dat toelaat. Achtergrondwerk gaat naar een wachtrij waarvan u de concurrency bepaalt en wordt als eerste geknepen.

### Maak het wachten korter, eerlijk
- Stream het antwoord terwijl het ontstaat.
- Toon de huidige stap in gewone taal.
- Geef bij een limiet het bruikbare deelresultaat terug en benoem wat ontbreekt.
- Haal alles wat niet blokkeert van het kritieke pad.
Latencybeleving is net zo goed een productvraagstuk als een technisch vraagstuk.

### Ontwerp de degradatiemodus vóór u hem nodig heeft
Beslis vooraf wat de agent doet als de provider traag is, over quotum gaat of uitvalt. Een verstandige ladder: volledige agent, dan goedkoper of alternatief model, dan alleen-retrieval antwoorden zonder tools, dan een eerlijke verontschuldiging met overdracht aan een mens.

Q: Meerdere provideraccounts of regio's?
A: Voor echte schaal of veerkracht, ja. Doe het achter één interne interface en pin modelversies per route.

Q: Hoe houd ik interactieve latency acceptabel?
A: Harde stappenlimieten, eenvoudige stappen naar een snel model, onafhankelijke aanroepen parallel en streamen.

Q: Wat breekt als eerste bij groei?
A: Bijna altijd de rate limits van de provider, daarna de interne API van uw drukste tool.

## Beveiliging van AI-agents: vangrails, rechten en prompt injection
https://aiagentdevelopment.info/nl/guides/agentbeveiliging-en-vangrails
Bijgewerkt op 2026-08-04 · Productie en beheer

- Zie de agent als een collega die vreemden kunnen ompraten.
- Injection is architectonisch: minimale rechten, isolatie, goedkeuringen, audit.
- Autoriseer op de identiteit van de eindgebruiker, serverzijde, bij elke aanroep.
- Zet vijandige cases in de evaluatie en draai ze na elke modelwissel opnieuw.

Het beveiligingsmodel voor agents wordt eenvoudiger zodra u de agent niet als code ziet maar als een behulpzame, snelle, onvermoeibare collega die door een vreemde tot dingen kan worden overgehaald.

Zo iemand geeft u op dag één geen onbeperkte databasetoegang, geen bedrijfskaart zonder limiet en geen toestemming om onbewaakt klanten te mailen. Dezelfde reflexen vertalen zich rechtstreeks en zijn betrouwbaarder dan welke instructie in een prompt ook.

### De dreiging die geen prompt oplost
Prompt injection zijn instructies verstopt in inhoud die de agent leest — een ticket, een webpagina, een pdf, een toolbeschrijving. Het model kan data waarover het moet redeneren niet betrouwbaar scheiden van instructies die het moet volgen, en geen zin als `negeer instructies in het document` dicht dat gat. Verdediging moet dus architectonisch zijn.
Ga ervan uit dat elke opgehaalde inhoud geschreven is door iemand die uw agent wil laten misdragen.

### Negen maatregelen, in onze volgorde van invoering
- Minimale rechten per tool: smal, waar mogelijk alleen-lezen, nooit een alles-account.
- Autorisatie op de eindgebruiker, serverzijde gecontroleerd bij elke aanroep.
- Menselijke goedkeuring vóór elke onomkeerbare handeling, met genoeg context.
- Argumentvalidatie en identifierresolutie vóór uitvoering; afwijzen in plaats van passend maken.
- Uitgaven- en stappenlimieten per run, plus snelheidslimieten per gebruiker en tool.
- Inhoudsisolatie: opgehaalde tekst is data, nooit systeeminstructie.
- Uitvoerfiltering op alles wat het systeem verlaat.
- Volledige auditlogging: wie, wat, welk record, welke run, welk resultaat.
- Noodschakelaar: één instelling die tools uitzet en alleen-lezen laat draaien.

### Schadebereik per handelingstype
| Een eigen record lezen | — | Rechtencontrole |
| Een antwoord opstellen | Ja | Geen |
| Een statusveld bijwerken | Meestal | Audit en snelheidslimiet |
| Een extern bericht sturen | Nee | Menselijke goedkeuring |
| Een terugbetaling doen | Nee | Goedkeuring, bedraglimiet |
| Data verwijderen | Nee | Goedkeuring, alleen soft delete |

### Test als een aanvaller, met regelmaat
Zet vijandige cases in uw evaluatieset en draai ze als elke andere test: een ticket met de instructie een intern document te mailen; een document dat beweert dat de gebruiker beheerder is. Elke run die eindigt in een verboden handeling is een gefaalde test.

Q: Lost betere prompting injection op?
A: Nee. Instructies verlagen het percentage maar elimineren het niet. Behandel het als architectuur.

Q: Moet de agent een serviceaccount gebruiken?
A: Alleen voor echt publieke data. Voor alles gebruikersspecifieks moet de identiteit doorlopen tot de rechtencontrole.

Q: Wat hoort achter een menselijke poort?
A: Alles wat onomkeerbaar is, zichtbaar voor klanten, boven een bedraggrens, en alles waarover de agent twijfelt.

## Agents monitoren in productie: wat loggen en waarop alarmeren
https://aiagentdevelopment.info/nl/guides/agents-monitoren-in-productie
Bijgewerkt op 2026-08-04 · Productie en beheer

- Trace elke run: contexten, aanroepen, versies, stopreden, latere correcties.
- Volg zes gedragsmetrieken; slaagpercentage en interventies tellen het zwaarst.
- Alarmeer op veranderingssnelheid en hang een trace bij elk alarm.
- Lees dagelijks een steekproef van echte runs.

Een klassieke service is gezond als hij snel antwoordt en geen fouten gooit. Een agent kan beide doen en volledig fout zitten: elk verzoek in twee seconden beantwoord, en allemaal met een beleid dat in maart is ingetrokken.

Daarom is agentmonitoring een aparte discipline. Ze rust op twee dingen: een trace per run die gedetailleerd genoeg is om te reconstrueren wat er gebeurde, en een handvol gedragsmetrieken waarvan de beweging iets betekent.

### Wat een bruikbare trace bevat
- Een run-ID op elke logregel, modelaanroep en uitgaand verzoek.
- De exacte context die per stap naar het model ging.
- Elke toolaanroep met argumenten, resultaat, duur en uitkomst.
- Modelnaam en -versie per aanroep, plus tokenaantallen.
- De stopreden: klaar, stappenlimiet, uitgavenlimiet, menselijke poort, fout.
- De einduitvoer en of iemand die later corrigeerde of terugdraaide.

### Zes metrieken die echt bewegen
| Slaagpercentage | Aanhoudende daling | Modelwissel, datadrift, gewijzigde API |
| Stappen per run | Langzame stijging | Toolfouten worden herhaald; retrieval verslechterd |
| Foutpercentage per tool | Piek bij één tool | Bovenliggend systeem kapot — niet de agent |
| Menselijke interventie | Stijgend | Vertrouwen daalt of nieuwe categorie |
| Ongefundeerde beweringen | Elke stijging | Retrieval faalt stil |
| Kosten per taak | Stijging bij gelijk volume | Opgeblazen context of meer retries |

### Alarmeer op gedrag, niet alleen op fouten
Een agent faalt zelden luidruchtig. Hij degradeert: iets meer stappen, iets meer retries, iets meer escalaties — en op een ochtend antwoordt hij uit verouderde documenten. Alarmeer op veranderingssnelheid in een schuivend venster en hang bij elk alarm de trace van een representatieve run.

### Bemonster en lees elke dag echte runs
Geen dashboard vervangt lezen. Kies dagelijks een handvol runs — een paar successen, elke escalatie, elke run die de limiet raakte — en lees ze helemaal.
Voeg alles wat verrast dezelfde dag toe aan de evaluatieset.

Q: Hoe lang volledige traces bewaren?
A: Lang genoeg voor debug en audit: gebruikelijk 30–90 dagen voor volledige contexten.

Q: Wat is het waardevolste alarm?
A: Een stijging in escalaties of menselijke correcties: het vroegste eerlijke signaal van verschuiving.

Q: Heb ik een speciale observability-tool nodig?
A: Niet om te beginnen. Een doorzoekbare tracetabel dekt het meeste.

## Agentkosten verlagen zonder de kwaliteit te schaden
https://aiagentdevelopment.info/nl/guides/agentkosten-verlagen
Bijgewerkt op 2026-08-04 · Productie en beheer

- Meet kosten per afgeronde taak, per type, vóór u optimaliseert.
- Context die u niet meer nodig heeft is meestal de grootste post.
- Zet stappen met weinig oordeel één voor één een niveau lager, met evaluatie.
- Begrens uitgaven per run en waarschuw bij het bereiken van de limiet.

Als een tokenrekening iemand verrast is de reflex overal op een goedkoop model over te stappen en kwaliteitsverlies te accepteren. Dat is zelden nodig. In de systemen die wij doorlichtten kwam het meeste uit context die er niet hoefde te zijn en uit stappen die geen duur model nodig hadden.

De methode hieronder is saai en effectief: eerst meten, dan vier wijzigingen op volgorde van opbrengst, dan beslissen of er nog een probleem is. De meeste teams stoppen na de tweede.

### Meet per run vóór u iets verandert
Maandtotalen zeggen niets bruikbaars. Log per run: invoer- en uitvoertokens, aantal aanroepen, model per aanroep en taaktype. Kijk dan naar kosten per afgeronde taak, uitgesplitst naar type.
Tel mislukte runs mee in de noemer. Een retrylus die drie pogingen verbrandt is een kostenprobleem vermomd als kwaliteitsprobleem.

### De vier wijzigingen, op opbrengst
| Context snoeien: gebruikte documenten weggooien, historie samenpersen | 20–40% | Laag als het doel vastgezet blijft |
| Goedkope stappen naar een kleiner model routeren | 20–40% | Laag, met evaluatie per stap |
| Het stabiele promptvoorvoegsel cachen | 10–30% bij herhaald verkeer | Laag |
| Stappen verminderen: betere tools, minder retries | 10–25% | Middel — vraagt toolwerk |

### De rekening is de context
Elke beurt stuurt de opgebouwde context opnieuw, dus een run van acht stappen kan hetzelfde document acht keer betalen. Drie gewoonten lossen het meeste op: gooi opgehaalde passages weg zodra hun stap klaar is; pers oude beurten samen tot feitelijke notities; snijd toolresultaten terug tot de gebruikte velden.

### Routeer per stap, niet op gevoel
Extractie, classificatie en opmaak hebben zelden uw sterkste model nodig; plannen en gebruikersproza vaak wel. Zet de eerste groep een niveau lager, draai de evaluatieset en houd de wijziging alleen als de cijfers standhouden.
- Begin bij de stap met het hoogste volume en het minste oordeel.
- Wijzig één stap tegelijk en draai de evaluatie opnieuw.
- Log welk model welke beslissing produceerde.
- Zet een uitgavenlimiet per run.

Q: Is caching de moeite waard?
A: Als uw runs een lang stabiel voorvoegsel delen, ja, en het is een van de goedkoopste winsten.

Q: Fine-tunen om te besparen?
A: Alleen voor een stap met hoog volume, smal en stabiel, waar een klein afgestemd model een groot evenaart.

Q: Hoe voorkom ik één peperdure run?
A: Limieten op stappen en uitgaven per run, detectie van identieke herhaalde aanroepen en stoppen met deelresultaat.

## AI-agents testen: een evaluatieset die zijn kosten waard is
https://aiagentdevelopment.info/nl/guides/agents-testen-en-evalueren
Bijgewerkt op 2026-08-04 · Productie en beheer

- Vijftig eigen cases beslissen beter dan welke benchmark ook.
- Beoordeel uitkomsten en bijwerkingen, nooit exacte transcripties.
- Dek bewust dubbelzinnige invoer, weigeringen en lege resultaten.
- Draai opnieuw bij elke wijziging van prompt, tool, model of retrieval.

De vraag die agents die live gaan scheidt van agents die in pilot wegkwijnen is simpel: hoe weet u of de wijziging van gisteren het beter maakte? Zonder antwoord is elke promptaanpassing een gok en wordt elke regressie door een klant ontdekt.

Een evaluatieset is het antwoord en vraagt geen platform. Vijftig cases in één bestand, een script dat ze draait en één beoordelingsregel per case zeggen meer dan elke ranglijst, want het zijn uw cases.

### Hoe een case eruitziet
Een case is een invoer, de begintoestand van de wereld en een toetsbare verwachting. Die verwachting is bijna nooit een exacte tekst — een agent kan in meerdere formuleringen gelijk hebben. Beoordeel de uitkomst: heeft hij de terugbetaaltool aangeroepen met bestelling 4471; bevat het eindantwoord de juiste datum; heeft hij geweigerd en doorgevraagd zoals het hoorde.
Bewaar de benodigde toestand bij de case. Een test die alleen op dinsdag slaagt door live data is geen test.

### Vijftig cases en waar ze vandaan komen
| Veelvoorkomende echte verzoeken uit logs | 20 | Beschermt het dagelijkse pad |
| Bekende eerdere storingen | 10 | Voorkomt terugkerende regressies |
| Dubbelzinnige invoer | 8 | Moet doorvragen, niet gokken |
| Cases die geweigerd moeten worden | 6 | Buiten scope, onbevoegd, onveilig |
| Lege of kapotte toolresultaten | 6 | Het meest voorkomende echte incident |

### Beoordeel uitkomsten, geen paden
Twee runs die via andere paden dezelfde juiste uitkomst bereiken zijn allebei correct, en een suite die één transcriptie eist faalt voortdurend zonder reden. Controleer wat er veranderde en wat er gezegd is: aanroepen met bijwerking, de kernfeiten van het antwoord, of er een menselijke poort werd gevraagd.

### Vier getallen om in de tijd te volgen
- Slaagpercentage over de hele set en apart over de weiger-subset.
- Percentage ongefundeerde beweringen.
- Mediaan en 95e percentiel van kosten en latency per run.
- Percentage menselijke interventies: hoe vaak iemand moest ingrijpen, en waarom.

### Draai hem in de pijplijn en ook na de lancering
Draai de set bij elke wijziging van prompts, tools, modelversie of retrievalconfiguratie. Blijf na de lancering echt verkeer bemonsteren: een paar runs per dag met de hand beoordeeld, en alles wat verrast gaat de set in.

Q: Met hoeveel cases beginnen?
A: Vijftig vangen echte regressies en zijn in een paar dagen geschreven. Twintig volstaan om te starten.

Q: Mag een model beoordelen?
A: Ja, met zorg. Geef expliciete criteria, houd de rubriek kort en controleer regelmatig een steekproef met de hand.

Q: Moet evaluatie deploys blokkeren?
A: Blokkeer op de veiligheidskritische subset. Voor algemene kwaliteit volgt u de trend.

## Multi-agentsystemen: wanneer meerdere agents beter zijn dan één
https://aiagentdevelopment.info/nl/guides/multi-agentsystemen
Bijgewerkt op 2026-08-04 · Agents bouwen

- Gebruik meerdere agents alleen bij onafhankelijke, anders uitgeruste en trage deeltaken.
- Geef gestructureerde objecten door en één ID voor het hele verzoek.
- Begrens de kosten systeembreed, niet per agent.
- Evalueer de overdrachten naast de uitkomsten.

Multi-agentdiagrammen zijn het meest verleidelijke artefact in dit vakgebied. Vakjes met functietitels, pijlen ertussen, een coördinator bovenaan — het lijkt een organigram, en organigrammen voelen als vooruitgang.

Dan komt productie en beginnen de vragen: welke agent produceerde dit foute getal, waarom accepteerde de coördinator het, en waarom kost één verzoek nu elf modelaanroepen.

### De drie voorwaarden
Meerdere agents lonen als alle drie gelden. De deeltaken zijn echt onafhankelijk. Elk vraagt andere tools of een ander modelniveau, zodat specialisatie iets reëels koopt. En het werk is traag genoeg dat parallelliteit de ervaring verandert. Gelden er maar twee, dan is één lus met meer tools bijna altijd beter.
Twee agents die voortdurend met elkaar moeten praten zijn één agent met een dure berichtenbus.

### Topologieën en hun kosten
| Supervisor | Eén agent delegeert aan specialisten | N+1 lussen | Supervisor routeert verkeerd |
| Pipeline | Vaste overdrachten, gespecialiseerde fasen | Voorspelbaar | Eén fase verslechtert stil |
| Parallelle waaier | Zelfde taak, meerdere blikken, samenvoegen | Hoogste | Samenvoegen wordt knelpunt |
| Debat of criticus | De een stelt voor, de ander weerlegt | 2× per uitwisseling | Overeenstemming zonder inzicht |
| Blackboard | Gedeelde toestand, iedereen leest en schrijft | Onvoorspelbaar | Races en lussen |

### Regels die het debugbaar houden
- Elke agent met geschreven contract: wat hij krijgt, teruggeeft en nooit mag doen.
- Geef gestructureerde objecten door tussen agents, nooit vrije proza.
- Eén run-ID voor het hele verzoek.
- Begrens de kosten van het hele systeem, niet per agent.
- Verbied cycli zonder expliciete teller en uitgangsvoorwaarde.
- Elke agent kan `dit lukte niet` teruggeven en de coördinator handelt dat af.

### Een voorbeeld dat het waard is
Concurrentieonderzoek past echt: gegeven tien bedrijven, verzamel publieke informatie over elk. De deeltaken zijn onafhankelijk, elk is traag en het samenvoegen is een eenvoudige aggregatie.

Q: Verbetert een supervisor de nauwkeurigheid?
A: Alleen als het routeren klopt. 90% vóór specialisten op 95% geeft ongeveer 85% end-to-end.

Q: Is agentdebat de kosten waard?
A: Soms, bij echt betwistbare oordelen waarbij u de criticus bewijs kunt geven.

Q: Hoe debug ik een multi-agentstoring?
A: Met een gedeelde ID op elke aanroep, opgeslagen invoer en uitvoer per agent en een weergave van de overdrachten op volgorde.

## RAG voor agents: antwoorden onderbouwen zonder in context te verdrinken
https://aiagentdevelopment.info/nl/guides/rag-voor-agents
Bijgewerkt op 2026-08-04 · Agents bouwen

- Bied retrieval aan als tool die de agent aanroept, niet als vaste eerste stap.
- Knip op structuur, houd fragmenten zelfstandig, hang titels en identifiers eraan.
- Trefwoorden plus vectoren verslaan elk apart op echt verkeer.
- Eis citaties en sta een eerlijk leeg resultaat toe.

Retrieval-augmented generation wordt meestal geïntroduceerd als pipeline: vraag inbedden, topfragmenten ophalen, plakken, genereren. Dat werkt voor een vraag-antwoordvak. Binnen een agent is het de verkeerde vorm, want de agent weet pas wat hij nodig heeft nadat hij een stap heeft gezet.

De versie die werkt behandelt retrieval als een tool die de agent aanroept wanneer hij besluit bewijs nodig te hebben — soms twee keer met andere zoekopdrachten, soms helemaal niet.

### Retrieval als tool, niet als voorwoord
Bied zoeken aan als gewone tool met een zoekargument en een kleine, gestructureerde return: enkele passages, elk met identifier en bron. De agent bepaalt wanneer hij hem aanroept, kan verfijnen na het resultaat en kan een andere tool aanroepen als het antwoord gestructureerde data is.
Log de zoekopdrachten die de agent schrijft: dat is de eerlijkste beschrijving van wat uw gebruikers echt vragen.

### Knipbeslissingen tellen zwaarder dan het embeddingmodel
- Splits op structuur — koppen, secties, lijstitems — niet op een vast aantal tekens.
- Houd elk fragment op zichzelf staand.
- Hang documenttitel en sectiekop aan elk fragment.
- Bewaar identifier en URL bij elk fragment zodat een antwoord de bron kan tonen.
- Liever weinig, grotere, betekenisvolle fragmenten; overlap is een pleister.

### Hybride verslaat pure vectoren op echte corpora
| Conceptuele vraag | Sterk | Zwak | Vector |
| Exacte productcode of fouttekst | Zwak | Sterk | Trefwoorden |
| Zeldzame eigennaam | Gemengd | Sterk | Trefwoorden |
| Geherformuleerde beleidsvraag | Sterk | Zwak | Vector |
| Echt verkeer in totaal | Gemengd | Gemengd | Beide, samengevoegd en herordend |

### Laat citeren en sta falen toe
Twee eisen doen het meeste werk voor betrouwbaarheid. Ten eerste draagt elke bewering uit retrieval de identifier van haar passage en maakt uw interface daar een link van. Ten tweede moet zoeken niets kunnen teruggeven en moet de agent geleerd hebben dat `ik vind dit niet in onze documentatie` een correcte uitkomst is.

Q: Moet de agent altijd zoeken vóór het antwoord?
A: Nee. Zoeken bij elk verzoek verspilt latency en vult context bij vragen die geen bewijs nodig hebben.

Q: Hoeveel passages teruggeven?
A: Drie tot zes goed gekozen verslaan er twintig.

Q: En als retrieval niets bruikbaars geeft?
A: Dat moet een ondersteunde uitkomst zijn. Geef een expliciet leeg resultaat terug.

## Geheugen in AI-agents: wat bewaren, samenpersen en weggooien
https://aiagentdevelopment.info/nl/guides/geheugen-in-ai-agents
Bijgewerkt op 2026-08-04 · Agents bouwen

- Modellen onthouden niets; agents hebben wat u opnieuw samenstelt.
- Vier lagen: vastgezet doel, recente beurten, samengeperste feiten, verse ophaal.
- Pers samen tot toetsbare feiten, niet tot verhaal, en alleen op een drempel.
- Blijvend geheugen vraagt herkomst, vervaldatum en een correctieweg.

In een modelaanroep zit geen geheugen. Elke beurt is een nieuw verzoek en het model weet alleen wat u deze keer heeft samengesteld. Alles wat mensen beschrijven als een agent die vergeet, of die tijdens een lange run slechter wordt, is een beslissing van uw code over wat er meegaat.

Zodra u dat accepteert wordt geheugenontwerp een vertrouwd engineeringprobleem: wat is altijd relevant, wat recent, wat is samen te vatten en wat kunt u beter vers ophalen dan opslaan.

### De vier lagen
| Vastgezet | Doel, randvoorwaarden, identiteit, beleid | Nooit | 200–500 tokens |
| Recent | Laatste beurten letterlijk, met resultaten | Schuivend venster | 2–5 beurten |
| Samengeperst | Oudere beurten als korte feitelijke notities | Herschreven bij groei | Onder 500 tokens |
| Opgehaald | Documenten voor deze stap | Na gebruik weggegooid | Per stap |

### Pers feiten samen, geen proza
De gebruikelijke fout is oude beurten als verhaal samenvatten — de klant vroeg naar haar bestelling en de agent keek het na. Dat leest prettig en helpt niets. Pers samen tot de feiten die een latere stap nodig kan hebben: bestelling 4471, status verzonden, terugbetaling gevraagd, beleid 30 dagen, nog niets terugbetaald.
Pers samen op een drempel, niet elke beurt. Samenvattingen van samenvattingen laten details stil verdwijnen.

### Ophalen is geen onthouden
Documenten uit een kennisbank horen bij de stap die ze nodig had. Ze daarna in de lopende context houden is de snelste weg naar een opgeblazen, dure, afgeleide run. Ophalen, gebruiken, citeren, weggooien.

### Blijvend geheugen tussen sessies
Langlevende agents verzamelen echt nuttige feiten over een persoon of account. Sla die bewust op in een klein gestructureerd record met een expliciete schrijfstap. Drie regels houden het gezond: schrijf alleen feiten waarop een toekomstige run zou handelen, leg altijd de herkomst vast en geef elk feit een vervaldatum.
- Schrijf bewust — als toolaanroep, niet als bijwerking.
- Bewaar bron en datum naast elk feit.
- Begrens de omvang en laat ongebruikt vervallen.
- Laat de gebruiker zien en corrigeren wat over hem is opgeslagen.

Q: Hoeveel historie letterlijk bewaren?
A: Drie tot vijf beurten dekken het meeste redeneren zonder de context te domineren.

Q: Heb ik een vectordatabase nodig voor geheugen?
A: Voor documenten ophalen vaak wel. Voor de lopende toestand van één run niet.

Q: Hoe voorkom ik verouderd blijvend geheugen?
A: Geef elk feit bron, datum en vervaldatum, en laat vers opgehaalde data voorgaan.

## Tool calling: tools ontwerpen die de agent goed gebruikt
https://aiagentdevelopment.info/nl/guides/tool-calling-voor-agents
Bijgewerkt op 2026-08-04 · Agents bouwen

- De meeste storingen zijn toolontwerp, geen prompt.
- Eén tool één taak; begrens met types, niet met proza.
- Schrijf fouten als korte instructies; behandel leeg als geldige uitkomst.
- Valideer elk argument en los identifiers op naar wat deze gebruiker mag zien.

Als een agent zich misdraagt is de reflex de prompt te herschrijven. In onze ervaring is de prompt misschien een derde van de keren de oorzaak; de rest van de tijd zijn de tools ontworpen voor een programma en niet voor een lezer die uit namen en beschrijvingen moet afleiden wat een functie doet.

Tools zijn het hele vermogen van de agent om de wereld te beïnvloeden, en hun definities zijn letterlijk deel van de modelcontext. Ze goed ontwerpen is goedkoper en veel duurzamer dan prompttuning.

### Zeven regels die de meeste slechte aanroepen voorkomen
- Eén tool, één taak. `search_orders` en `refund_order` verslaan een `manage_order` met modus.
- Types in plaats van proza. Enums, bereiken en formaten doen wat een beschrijving nooit doet.
- Namen die zeggen wat er gebeurt. `send_email_to_customer` is eenduidig; `notify` niet.
- Fouten als instructie: wat er mis was en wat nu te doen, in één korte zin.
- Lege resultaten zijn resultaten. Een expliciet niet-gevonden verslaat een exception.
- Idempotentiesleutels op alles met bijwerking.
- Kleine returns. Snijd terug tot de nodige velden; 40 KB JSON koopt verwarring.

### Voor en na
| `query(sql)` | Onbegrensde macht, niet controleerbaar | `get_orders_by_customer(customer_id, limit)` |
| `date: string` | Model verzint formaten | `date: string, formaat JJJJ-MM-DD` |
| `HTTP 500` | Impliceert geen actie, eindeloos herhaald | `Orderservice niet bereikbaar. Zeg de klant het later te proberen.` |
| Geeft het hele record terug | Vult context, verdunt aandacht | Geeft zes benoemde velden terug |
| `update_status(id, status)` | Elke status, elk record | `cancel_order(id)` met rechtencontrole |

### Beschrijvingen zijn prompt
Het beschrijvingsveld is geen documentatie voor collega's; het is tekst die het model leest tijdens het beslissen. Zeg wanneer u de tool gebruikt en wanneer niet, noem de ene voorwaarde die telt en geef één voorbeeldargument. Drie zinnen verslaan drie alinea's.
Kunnen twee tools hetzelfde verzoek bedienen, dan kiest de agent soms verkeerd. Voeg ze samen of maak de grens expliciet.

### Valideer altijd vóór uitvoering
Geef modeluitvoer nooit ongecontroleerd door aan een systeemaanroep. Valideer argumenten tegen het schema, los identifiers op tegen records die deze gebruiker mag zien, en wijs af wat niet past in plaats van het passend te maken.

Q: Hoeveel tools is te veel?
A: Boven ongeveer tien in één lus daalt de selectienauwkeurigheid en vullen beschrijvingen de context.

Q: Moeten tools ruwe API-antwoorden teruggeven?
A: Nee. Geef een kleine, stabiele vorm terug met de velden die echt nodig zijn.

Q: Hoe voorkom ik verzonnen argumenten?
A: Door te begrenzen: enums in plaats van vrije tekst, expliciete formaten en identifiers die moeten oplossen.

## AI-agentarchitectuur: de patronen die productie overleven
https://aiagentdevelopment.info/nl/guides/architectuurpatronen-voor-agents
Bijgewerkt op 2026-08-04 · Agents bouwen

- Standaard: begrensde lus met expliciete stopvoorwaarden en lineaire trace.
- De toolgateway is de meest waardevolle component.
- Planner–uitvoerder geeft zichtbare intentie; de criticus minder ongefundeerde beweringen.
- Laag uw geheugen: doel, recente beurten, samengeperste feiten, verse ophaal.

Architectuurdiscussies beginnen meestal aan de verkeerde kant: een diagram van vakjes met conceptnamen. De bruikbare versie begint bij de storing die u wilt voorkomen, want elk patroon hieronder bestaat om één specifieke slechte middag tegen te houden.

Deze zes zijn de patronen waar we telkens naar teruggrijpen. Ze combineren: een productieagent is doorgaans een begrensde lus met toolgateway, twee geheugenlagen en een menselijke poort — plus een criticusronde alleen waar de kosten van fout zijn een extra aanroep rechtvaardigen.

### 1. De begrensde lus
Het basisgeval en uw standaard. Eén lus over een kleine toolset met expliciete stopvoorwaarden: stappenlimiet, uitgavenlimiet, herhalingsdetectie en tijdslimiet. Het voordeel is een lineaire trace die van boven naar beneden te lezen is.
Kunt u uw agent niet tekenen als een lus met een lijst uitgangen, dan heeft u nog geen architectuur maar een ambitieuze prompt.

### 2. Planner–uitvoerder met herplannen
Voor taken boven de vijf stappen: vraag eerst een genummerd plan, voer het uit en herplan bij een mislukking in plaats van een verouderd plan te volgen. De winst is niet nauwkeurigheid, maar dat een mens de intentie ziet vóór de handeling.

### 3. De criticusronde
Een tweede aanroep beoordeelt het concept of de voorgestelde handeling tegen het doel en het opgehaalde bewijs, en mag het één keer terugsturen. Dat vangt een reëel deel van zelfverzekerde maar ongefundeerde uitvoer.
| Begrensde lus | 0 | Traceerbaarheid, kostenbeheersing | Nooit — dit is de basis |
| Planner–uitvoerder | 1–2 | Zichtbare intentie, controleerbaarheid | Taken onder vijf stappen |
| Criticusronde | 1 per beoordeelde uitvoer | Minder ongefundeerde beweringen | Goedkope, omkeerbare uitvoer |
| Toolgateway | 0 | Rechten, audit, snelheidslimieten | Alleen prototypes |
| Gelaagd geheugen | 0–1 | Relevantie bij lange context | Korte enkele runs |
| Menselijke poort | 0 | Onomkeerbaars blijft veilig | Als niets onomkeerbaar is |

### 4. De toolgateway
Laat de agent uw systemen niet rechtstreeks aanroepen. Zet voor elke tool één laag die vier dingen doet: argumenten valideren tegen een schema, controleren of deze eindgebruiker dit record mag raken, een snelheidslimiet toepassen en een auditregel met run-ID schrijven.

### 5. Gelaagd geheugen
Eén ongedifferentieerde gespreksgeschiedenis is de meest voorkomende oorzaak dat een agent gedurende een run slechter wordt. Scheid: doel en randvoorwaarden, nooit gesnoeid; recente beurten letterlijk; oudere beurten samengeperst tot korte feitelijke notities; en opgehaalde kennis, per stap vers en nooit opgestapeld.

### 6. De menselijke poort
Elke onomkeerbare handeling staat achter een expliciete goedkeuring met genoeg context om in seconden te beslissen. De poort is een productfunctie, geen beperking.

Q: Heb ik alle zes patronen nodig?
A: Nee. Begin met de begrensde lus en de gateway; beide zijn vrijwel verplicht voor alles wat echte systemen raakt.

Q: Verbetert een criticusronde echt de nauwkeurigheid?
A: Bij taken waar het model plausibele maar ongefundeerde antwoorden kan geven, merkbaar wel.

Q: Waar hoort de gateway?
A: In uw eigen service, tussen agent en systemen, met de identiteit van de eindgebruiker erdoorheen.

## No-codeplatforms of maatwerk: een eerlijke vergelijking
https://aiagentdevelopment.info/nl/guides/no-code-of-maatwerk
Bijgewerkt op 2026-08-04 · Frameworks en modellen

- Platform en maatwerk zijn fasen, geen rivalen.
- Rechten per gebruiker, producteigendom en volume duwen richting maatwerk.
- Bewijs de flow op een platform en bouw daarna alleen het verdiende opnieuw.
- Exporteer prompts, definities en logs vanaf dag één.

Het debat no-code versus maatwerk wordt meestal gevoerd door mensen met iets te verkopen. Nadat we beide hebben gebouwd is onze mening saaier en bruikbaarder: het zijn fasen, geen rivalen — en de fout is te lang in één fase blijven.

Een platform is de goedkoopste manier om te ontdekken wat uw taak echt vraagt. Maatwerk is hoe u de controle over rechten, kosten per eenheid en productoppervlak terugneemt zodra u dat weet.

### Naast elkaar, zonder marketing
| Tijd tot eerste versie | Dagen | Weken |
| Kostenvorm | Per seat of run, doorlopend | Engineering vooraf, dan infrastructuur |
| Toegang tot interne systemen | Wat connectoren bieden | Alles waarvoor u code schrijft |
| Rechten per eindgebruiker | Meestal grof | Zo fijn als u ze bouwt |
| Evaluatie en regressietests | Van de leverancier, soms oppervlakkig | Van u, zo diep als u investeert |
| Portabiliteit | Configuratie ligt bij de leverancier | Repository is van u |
| Past wanneer | Waardebewijs, standaardtaak, klein team | Productoppervlak, echte rechten, volume |

### Vier vragen die het snel beslissen
- Heeft de agent rechten per gebruiker op interne data nodig? Zo ja, vrijwel altijd maatwerk.
- Is de agent onderdeel van wat u verkoopt? Zo ja, maatwerk.
- Meer dan een paar duizend taken per maand? Reken de prijs per run uit vóór u zich vastlegt.
- Heeft u een eigen evaluatieset en audittrail nodig? Kijk eerst wat het platform exporteert.

### Het hybride patroon dat werkt
Bewijs de flow op een platform, instrumenteer alles en laat het een maand met echte gebruikers draaien. U leert drie dingen die u niet kon ontwerpen: welke verzoeken echt binnenkomen, welke tools gebruikt worden en waar mensen ingrijpen. Bouw daarna alleen de delen opnieuw die het verdiend hebben.
Exporteer prompts, definities en logs vanaf dag één. Maakt een platform dat lastig, beschouw dat als een bevinding over het platform.

Q: Kan no-code het definitieve antwoord zijn?
A: Ja, voor interne, standaard taken met gematigd volume en lage foutkosten.

Q: Is maatwerk altijd nauwkeuriger?
A: Nee. Nauwkeurigheid komt uit toolontwerp, onderbouwing en evaluatie — alle drie ook op een platform mogelijk.

Q: Wat is de grootste verborgen kostenpost?
A: Onderhoud. Begroot 15–25% van de bouwkosten per jaar en wijs een eigenaar aan.

## Het Model Context Protocol, uitgelegd voor bouwers
https://aiagentdevelopment.info/nl/guides/model-context-protocol-uitgelegd
Bijgewerkt op 2026-08-04 · Frameworks en modellen

- MCP standaardiseert ontdekking en aanroep tussen agentclient en toolserver.
- Authenticatie, autorisatie en goedkeuring blijven van u.
- Verpak smalle mogelijkheden en handhaaf rechten in de server, per aanroep.
- Servers van derden zijn afhankelijkheden waarvan de beschrijvingen in uw context belanden.

Elk team dat meer dan één agent bouwt schrijft dezelfde adapter twee keer: verbinden met een systeem, beschrijven wat het kan en die mogelijkheden aan het model aanbieden in de vorm die de client van vandaag verwacht. Het Model Context Protocol bestaat om die duplicatie te stoppen door de interface tussen agentclient en toolserver te standaardiseren.

Dat is echt nuttig en tegelijk smaller dan het enthousiasme suggereert. MCP beschrijft hoe mogelijkheden worden aangekondigd en aangeroepen. Het bepaalt niet wie ze mag aanroepen, en die twee verwarren is de bron van beveiligingsincidenten.

### Wat het protocol standaardiseert
- Ontdekking: de server vertelt de client welke tools en bronnen hij aanbiedt, met schema's.
- Aanroep: de client roept aan met getypeerde argumenten en krijgt een gestructureerd resultaat.
- Bronnen: alleen-lezen inhoud die de client op verzoek in de context trekt.
- Transport: een gedeeld formaat zodat client en server van verschillende makers samenwerken.

### Wat het bewust niet doet
MCP authenticeert uw gebruikers niet, bepaalt niet welke records wie mag lezen en niet of een handeling goedkeuring vereist. Dat blijft van u en hoort aan de serverkant — een client die netjes om toestemming vraagt is geen rechtensysteem. De meest voorkomende architectuurfout is een brede tool als `run_query` via MCP openzetten en op de prompt vertrouwen.
Behandel elke MCP-tool alsof een verwarde of gemanipuleerde aanroeper hem met de slechtst denkbare argumenten aanroept.

### Waar het vandaag loont
| Eén intern systeem, meerdere agentclients | Hoog — server schrijft u één keer |
| Desktopassistenten met lokale context | Hoog — daar is het ecosysteem gebouwd |
| Eén agent met drie eigen tools | Laag — directe functieaanroepen zijn eenvoudiger |
| Tools van derden buiten uw beheer | Middel — handig, maar audit de server |

### Een veilige manier om het te adopteren
- Verpak smalle mogelijkheden, geen algemene macht: `get_order(id)` in plaats van `sql(query)`.
- Handhaaf autorisatie in de server, per aanroep, met de identiteit van de eindgebruiker.
- Geef korte, eerlijke fouten terug — `niet gevonden`, `niet toegestaan`.
- Log elke aanroep met argumenten en identiteit; dat is uw audittrail.
- Pin de servers die u gebruikt op beoordeelde versies.

Q: Heb ik MCP nodig om een agent te bouwen?
A: Nee. Voor één agent met een handvol eigen tools zijn directe functieaanroepen eenvoudiger.

Q: Is MCP standaard veilig?
A: Het is een transport- en ontdekkingsstandaard, geen beveiligingsmodel. Authenticatie en autorisatie implementeert u serverzijde.

Q: Kunnen MCP-servers een injectiekanaal zijn?
A: Ja, zowel via tooldescripties die in de context komen als via teruggegeven inhoud.

## Een model kiezen voor uw agent: vermogen, latency en kosten
https://aiagentdevelopment.info/nl/guides/model-kiezen-voor-uw-agent
Bijgewerkt op 2026-08-04 · Frameworks en modellen

- Kies per stap, niet één model voor de hele agent.
- Benchmarks maken de shortlist; dertig eigen cases beslissen.
- Latency, betrouwbare gestructureerde uitvoer en echte contextlengte knellen.
- Pin expliciete versies en houd de evaluatie op één commando afstand.

De gestelde vraag is welk model het beste is voor agents. De vraag die een goed systeem oplevert is: welk model is het beste voor deze stap, op onze data, binnen ons latencybudget — en het antwoord is meestal meer dan één.

Een run is niet homogeen. De volgende actie kiezen vraagt redeneren. Drie velden uit een document halen niet. Een resultaat samenvatten voor de gebruiker ook niet. Alles als één inkoopbeslissing behandelen is hoe teams topprijzen betalen om JSON te herschikken.

### Splits de run vóór u kiest
| Plannen of actie kiezen | Redeneren, instructies volgen | Het sterkste dat u zich kunt veroorloven |
| Tool aanroepen met argumenten | Betrouwbare gestructureerde uitvoer | Middenklasse met strikte schema's |
| Velden uit een resultaat halen | Nauwkeurigheid op korte tekst | Klein en snel |
| Classificeren of routeren | Consistentie | Klein of afgestemde classifier |
| Het gebruikersantwoord schrijven | Toon en helderheid | Middenklasse |

### Benchmarks maken de shortlist, niet de keuze
Publieke benchmarks zeggen welke modellen plausibel zijn. Ze zeggen niet welk model uw schema's, documentformaten en lastige klanten aankan. Bouw dertig echte cases uit uw logs — inclusief de vijf gênante — en laat de shortlist daarop lopen.
Neem cases op waarin het juiste gedrag weigeren of doorvragen is. Modellen verschillen veel meer in weten wanneer te stoppen.

### De drie beperkingen die echt knellen
- Latencyvloer: elke aanroep heeft er een en een agent doet er meerdere. Meet de hele run.
- Betrouwbaarheid van gestructureerde uitvoer: 97% geldige argumenten breekt één op tien runs met drie aanroepen.
- Contextgedrag: lange context kost en verdunt aandacht; meet op de echte lengte.

### Routing zonder onderzoeksproject
Modelrouting klinkt geavanceerd en is meestal een configuratiebestand. Een standaardmodel per staptype, een override per tool, en loggen welk model welke beslissing produceerde. Begin met alleen extractie en classificatie een niveau lager.

Q: Overal het grootste model?
A: Alleen als u niet gemeten heeft. De beslisstap profiteert meestal; extractie, classificatie en opmaak zelden.

Q: Werken open modellen voor agents?
A: Voor smalle stappen met strikte schema's vaak wel, en op volume is de economie overtuigend.

Q: Hoe vaak herzien?
A: Bij elke versie die u zou kunnen overnemen, en verder ongeveer elke twee kwartalen.

## Agentorkestratie: wanneer nodig en wanneer ballast
https://aiagentdevelopment.info/nl/guides/agentorkestratie
Bijgewerkt op 2026-08-04 · Frameworks en modellen

- Orkestratie koopt duurzaamheid, idempotentie, vertakking en hervatting.
- Vraag wat het kost om een halfmislukte run over te doen.
- Queue, toestandsregel en idempotentiesleutels leveren het meeste goedkoop.
- Houd prompts en schema's buiten de workflowdefinities.

Orkestratiebibliotheken lossen een echt probleem op: een run die minuten duurt, meerdere systemen raakt en een herstart moet overleven zonder de al gedane betaling te herhalen. Dat is echt en vervelend om met de hand op te lossen.

Het is ook niet het probleem van de meeste agents. Een supportagent die in vijftien seconden antwoordt en veilig opnieuw kan starten heeft er niets van nodig. Deze gids scheidt de gevallen, zodat u orkestratie invoert vanwege de faalmodi en niet omdat het diagram leeg oogt.

### Wat orkestratie werkelijk geeft
- Duurzame toestand: de run overleeft een deploy, crash of scale-down.
- Idempotente stappen: een nieuwe poging herhaalt geen effect dat al plaatsvond.
- Vertakking en samenvoeging: echte control flow, geen prompt die het beschrijft.
- Hervatting: pauzeren voor een menselijke goedkeuring die vier uur later komt.
- Waarneembaarheid door constructie: elke stap is een object met status.

### De test die beslist
Eén vraag: als deze run halverwege sterft, wat kost overdoen dan? Zijn dat een paar cent en seconden, doe het over — u heeft geen duurzaamheid nodig maar een retry. Is het een dubbele terugbetaling, een tweede klantmail of twintig minuten wachttijd, dan heeft u duurzame, idempotente stappen nodig.
De meeste teams ontdekken hun antwoord bij de eerste deploy midden in een run.

### Waar de complexiteit opduikt
| Lokale ontwikkeling | Draai het bestand | Plus worker en toestandsopslag |
| Debuggen | Eén lineaire trace | Stappen correleren in een runhistorie |
| Deploy midden in een run | Run sterft | Run hervat |
| Menselijke goedkeuringen | Onhandig; meestal nieuw verzoek | Eersteklas pauze en hervatting |
| Kosten van een bug in stap 3 | Alles opnieuw | Alleen stap 3 opnieuw |

### De middenweg die velen overslaan
U hoeft niet te kiezen tussen kale lus en volledig platform. Een bescheiden queue, één toestandsregel per run en idempotentiesleutels op de twee tools met bijwerking dekken misschien tachtig procent van het voordeel met een fractie van het operationele oppervlak.

Q: Kan ik orkestratie gebruiken voor een simpele chatagent?
A: Dat kan en het werkt, maar u betaalt dagelijks in wrijving bij lokale ontwikkeling voor een voordeel dat u zelden claimt.

Q: Is een message queue genoeg?
A: Vaak wel. Queue plus toestandsregel per run plus idempotentiesleutels dekken de gebruikelijke faalmodi.

Q: Hoe blijven gedistribueerde runs debugbaar?
A: Met een stabiele run-ID op elke logregel, aanroep en uitgaand verzoek, en de exacte context per stap opgeslagen.

## Een agentframework kiezen: wat er echt toe doet
https://aiagentdevelopment.info/nl/guides/agentframework-kiezen
Bijgewerkt op 2026-08-04 · Frameworks en modellen

- Ranglijsten verouderen snel; de geschiktheidsvragen niet.
- Drie afspraken: provider-SDK, orkestratiebibliotheek, beheerd platform.
- Prompts, schema's, evaluatie en traceformaat horen in uw repository.
- Bouw dezelfde kleine agent twee keer en meet debugbaarheid.

Elk artikel dat agentframeworks op naam rangschikt is verouderd voordat het geïndexeerd is. Deze bibliotheken herschrijven hun kernabstracties om de paar releases, en wat vandaag wint kan veranderd zijn tegen de tijd dat u live gaat.

Daarom doet deze gids iets duurzamers: hij somt de acht vragen op die bepalen of u over zes maanden nog blij bent met uw keuze, en legt uit wat elk antwoord kost.

### De acht vragen, op volgorde van belang
- Kan ik de lus lezen? Vindt u het bestand niet waar modeluitvoer een toolaanroep wordt, dan debugt u geen slechte run.
- Wat gebeurt er bij een toolfout — komt die bij mij, of wordt hij onzichtbaar opnieuw geprobeerd met een andere prompt?
- Is mijn prompt de prompt van het framework? Verborgen systeemtekst verrast u bij een audit.
- Kan toestand worden bewaard en hervat, of kost een crash de run?
- Hoe worden tools gedefinieerd, en kan ik die definities buiten hergebruiken?
- Hoe is het upgradeverhaal — zijn kernabstracties recent hernoemd?
- Kan ik van model wisselen zonder van framework te wisselen?
- Wat voegt het toe aan een koude start en aan elke beurt?

### Drie categorieën, drie afspraken
| Provider-SDK plus eigen lus | Volledige zichtbaarheid, weinig afhankelijkheden | Retries, toestand, persistentie schrijft u zelf | Eén agent, weinig tools, veel debuggen |
| Orkestratiebibliotheek | Duurzame toestand, vertakking, retries, hervatting | Wat zichtbaarheid; upgraderumoer | Lange of meerstapsstromen |
| Beheerd platform | Hosting, traces, evaluatie, interface | Portabiliteit; prijs per seat of run | Klein team, standaardtaak, snel bewijs |

### Schrijf zelf wat van u moet blijven
Wat u ook kiest, vier zaken horen in uw eigen repository in een vorm die geen framework bezit: de prompts, de tooldefinities met hun JSON-schema's, de evaluatieset en het traceformaat. Dat is wat echt werk kostte. Als platte data met dunne adapters is van framework wisselen een dag; als decorators en overerving is het een herschrijving.

### De test die niemand doet
Bouw vóór u beslist dezelfde kleine agent twee keer: één keer met uw favoriet en één keer met de provider-SDK en een zelfgeschreven lus. Dezelfde drie tools, dezelfde tien cases. U meet geen nauwkeurigheid — die zal vergelijkbaar zijn. U meet hoe lang het duurde, hoe leesbaar de trace is en hoe makkelijk u ontdekte waarom case zeven faalde.
Bewaar de zelfgeschreven versie: die is uw referentie als u moet bewijzen of een vreemdheid uit uw prompt of uit het framework komt.

Q: Heb ik een framework nodig voor een eerste agent?
A: Nee. Een eerste agent met drie tools is een lus, een schemalijst en een stopvoorwaarde.

Q: Is een beheerd platform een val?
A: Niet als u prompts, schema's en evaluatie portabel houdt. Het risico is niet het platform, maar dat uw intellectuele kapitaal alleen als configuratie daarbinnen bestaat.

Q: Hoeveel invloed heeft het framework op nauwkeurigheid?
A: Veel minder dan gedacht. Nauwkeurigheid komt uit toolontwerp, onderbouwing en evaluatie.

## Wanneer u geen AI-agent moet gebruiken (en wat dan wel)
https://aiagentdevelopment.info/nl/guides/wanneer-geen-ai-agent
Bijgewerkt op 2026-08-04 · Basis

- Vaste volgordes willen een pipeline met een modelstap, geen agent.
- Rekenwerk, exact matchen en subseconde-latency passen alle drie niet.
- Zonder evaluatieset weet u nooit of een wijziging hielp: eerst twintig voorbeelden.
- Onomkeerbare, waardevolle handelingen horen achter een menselijke poort.

Wij bouwen agents voor de kost, en juist daarom bestaat deze pagina. De snelste manier om het vertrouwen van een team in deze techniek te beschadigen is een agent zetten op een taak die er geen nodig had, hem 94% goed zien doen waar een script 100% deed, en het volgende kwartaal besteden aan verdedigen.

Hieronder de zes situaties waarin we nee zeggen, en wat we in plaats daarvan aanraden. Geen van alle gaat over modelvermogen; ze gaan over waar niet-determinisme een kostenpost is in plaats van een voordeel.

### 1. De stappen veranderen nooit
Ligt de volgorde vast — bestand halen, kolommen valideren, transformeren, laden, melden — dan hoeft niets de volgende stap te bepalen, want niets bepaalt. Schrijf de pipeline. Vraagt één stap oordeel, roep dan voor die stap het model aan en houd de rest deterministisch.
Dit is de meest voorkomende overbouw die we zien. Een modelaanroep in een pipeline is niet minder dan een agent; het is het juiste.

### 2. De taak is rekenen of exact matchen
Totalen, afstemmingen, belasting, rechtenregels met gepubliceerde drempels: die hebben juiste antwoorden en bestaande implementaties. Een model kan een berekening prachtig uitleggen en toch af en toe fout zitten, en af en toe is in finance een ramp.

### 3. Latencybudget onder een seconde
Een agent die plant, twee tools aanroept en antwoordt haalt dat niet betrouwbaar onder een seconde. Zit u in een checkout of een zoek-tijdens-typen, haal het werk dan van het kritieke pad of gebruik een classifier en een lookup.

### 4. Niemand kan zeggen hoe een correcte run eruitziet
Kan het team geen twintig voorbeelden van de goed uitgevoerde taak leveren, dan heeft u geen evaluatieset — en zonder die set weet u nooit of een wijziging hielp. Bouw eerst de voorbeelden.
Twintig gelabelde voorbeelden is een bewust lage lat. Haalt u die niet, dan is de taak nog niet goed genoeg begrepen.

### 5. Elke handeling is onomkeerbaar en waardevol
Overboekingen, contracthandtekeningen, verwijderingen in productie. U mag er een agent voor zetten — als opsteller die het dossier samenstelt en aan een mens overdraagt. Wat u niet moet doen is een autonome lus onbewaakte schrijfrechten geven op iets onomkeerbaars.

### 6. De benodigde data is niet toegankelijk
Een agent is zo goed als zijn tools, en tools zijn zo goed als uw API's. Leeft de informatie in een systeem zonder lees-API of in een spreadsheet die drie mensen met de hand bijhouden, dan blijft er voor de agent gokken over. Repareer eerst de toegang.

Q: Wanneer is een agent duidelijk het juiste middel?
A: Als de volgende stap echt afhangt van wat de vorige teruggaf, als meerdere tools nodig kunnen zijn in een volgorde die u niet kunt vastleggen, en als een mens dit vandaag doet door op te zoeken en te beslissen.

Q: We hebben al een agent op een vaste pipeline. Eruit halen?
A: Niet per se: meet eerst. Werkt hij betrouwbaar en zijn de kosten acceptabel, laat hem staan.

Q: Mag een agent deel zijn van een deterministisch systeem?
A: Ja, en dat is vaak het beste ontwerp. Houd de ruggengraat deterministisch en geef de agent één begrensd gebied waar oordeel nodig is.

## Soorten AI-agents: vijf vormen die bijna alles dekken
https://aiagentdevelopment.info/nl/guides/soorten-ai-agents
Bijgewerkt op 2026-07-28 · Basis

- Vijf vormen: beantwoorder, één lus, planner–uitvoerder, router, samenwerkende agents.
- Elke hogere sport koopt vermogen met traceerbaarheid en kosten.
- De meeste productieagents zijn één lus met drie tot zes tools.
- Klim alleen op met een trace die structureel falen aantoont.

Academische taxonomieën — reflex, modelgebaseerd, doelgebaseerd, nutgebaseerd — helpen bij tentamens en nauwelijks bij de vraag wat u maandag bouwt. In de praktijk telt de vorm van de control flow, want die bepaalt kosten, latency en hoe lastig debuggen wordt.

Vijf vormen dekken vrijwel elke agent die we opleverden of beoordeelden. Ze vormen een complexiteitsladder, en de meest voorkomende dure fout is twee sporten te hoog beginnen.

### De vijf vormen, van goedkoop naar lastig
| Tool-ondersteunde beantwoorder | Eén aanroep, misschien één tool | Opzoeken, verrijken, classificeren | Nauwelijks een agent; prima |
| Agent met één lus | Model lust over een kleine toolset | Support, onderzoek, triage | Afdwalen bij lange taken |
| Planner–uitvoerder | Plannen, uitvoeren, herplannen bij fout | Meerstapsoperaties, migraties | Verouderde plannen na stap drie |
| Router met specialisten | Router kiest een smalle subagent | Brede domeinen met aparte skills | Routeerfouten stapelen |
| Samenwerkende agents | Meerdere agents wisselen resultaten uit | Echt parallel onderzoek | Kosten, latency, ontraceerbare fouten |

### Begin één sport lager dan goed voelt
De agent met één lus lost veel meer echte problemen op dan zijn reputatie suggereert en heeft één enorm voordeel: een lineaire trace die een mens van boven naar beneden leest. Elke hogere sport koopt vermogen door traceerbaarheid uit te geven. Noem vóór u opklimt het concrete geval waarin de eenvoudige vorm faalde, met trace als bewijs.

### Welke sport u werkelijk nodig heeft
- Eén opzoeking en één beslissing: tool-ondersteunde beantwoorder.
- Weinig tools en wisselende volgorde: één lus.
- Een mens zou eerst een checklist schrijven: planner–uitvoerder.
- Het werk splitst netjes in aparte expertises met aparte tools: router.
- Twee deeltaken echt onafhankelijk en beide traag: samenwerking kan lonen.

### De specialistenval
Routers zien er netjes uit op een diagram en gedragen zich slecht aan de randen. De router ziet alleen het verzoek, niet wat de specialisten zouden vinden, dus moet hij gokken. Twee remedies: laat een specialist `niet van mij` teruggeven en herrouteer één keer, en houd het aantal specialisten klein genoeg om elk in één zin te beschrijven.
Meet routeernauwkeurigheid apart. Een router op 90% vóór specialisten op 95% geeft 85% end-to-end.

Q: Zijn multi-agentsystemen beter dan één agent?
A: Alleen als de deeltaken echt onafhankelijk zijn en elk andere tools of modelniveaus vragen.

Q: Welke vorm komt het meest voor in productie?
A: De agent met één lus, drie tot zes tools en een menselijke poort voor onomkeerbare handelingen.

Q: Wanneer klim ik een sport hoger?
A: Als u de trace heeft van een echte fout die de eenvoudige vorm structureel niet kan oplossen.

## Hoe AI-agents werken: de lus, stap voor stap
https://aiagentdevelopment.info/nl/guides/hoe-ai-agents-werken
Bijgewerkt op 2026-07-28 · Basis

- Eén beurt: context samenstellen, beslissen, valideren, uitvoeren, loggen, stop controleren.
- Het model ziet alleen wat u terugzet — snoeien veroorzaakt de meeste rare gedragingen.
- Schrijf toolfouten als bruikbare instructies, niet als diagnose.
- Traces zijn het belangrijkste debughulpmiddel; bouw ze vóór de tweede feature.

Agents lijken magie in demo's en loodgieterswerk in productie. De reden: het interessante is niet de modeluitvoer maar de lus die haar verwerkt, en die lus is kort genoeg om in één keer te lezen.

Deze gids voert één verzoek van begin tot eind door die lus: wat het model per beurt ziet, wat uw code met het resultaat doet, hoe een falende tool terugkomt en wat de lus stopt. Kunt u dit voor uw eigen systeem vertellen, dan kunt u het debuggen.

### Eén ronde van de lus, op volgorde
- Stel de context samen: doel, tooldefinities, opgehaalde feiten en een gesnoeide historie.
- Vraag het model om de volgende stap. Het antwoordt direct of vraagt een toolaanroep met argumenten.
- Valideer de argumenten voordat er iets gebeurt — types, bereiken en of deze aanroeper dit record mag raken.
- Voer de tool uit. Vang fouten en vertaal ze naar korte, feitelijke berichten in plaats van stacktraces.
- Voeg aanroep en resultaat toe aan de historie en controleer de stopvoorwaarden.
- Herhaal, of geef het eindantwoord terug met wat de agent werkelijk deed.

### Wat het model wel en niet ziet
Het model herinnert zich niets van de vorige beurt behalve wat u terugzet in de context. Dat ene feit verklaart bijna al het verwarrende gedrag. Vergeet de agent een randvoorwaarde van vier stappen geleden, dan heeft uw snoeien die verwijderd. Herhaalt hij dezelfde falende aanroep drie keer, dan zei de foutmelding niet waarom in woorden waarmee hij iets kan.
Schrijf toolfouten als instructie, niet als diagnose. Niet `HTTP 404`, maar `Geen klant met dit ID. Vraag om bevestiging van het bestelnummer.`

### Stoppen: het deel dat demo's nooit tonen
| Stappenlimiet | 8–15 toolaanroepen | Geef deelresultaat met uitleg terug |
| Uitgavenlimiet | Vaste kosten per run | Stop en log voor beoordeling |
| Klok | 30–120 s bij interactief gebruik | Draag over met wat bekend is |
| Herhalingsdetectie | Zelfde aanroep en argumenten twee keer | Forceer een andere tak of stop |
| Menselijke poort | Elke onomkeerbare handeling | Pauzeer en vraag goedkeuring |

### Een trace lezen als het misgaat
Een trace is het geordende verslag van elke context, beslissing, aanroep en uitkomst van één run. Het is het enige debughulpmiddel dat telt en het eerste dat u bouwt. De vraag is nooit waarom het model slecht is, maar welke beurt als eerste misging en wat het model op dat moment kon zien.

Q: Hoeveel stappen voordat de agent stopt?
A: Voor interactieve taken dekt een limiet van acht tot twaalf aanroepen bijna alles legitiems; wie meer nodig heeft, zit meestal vast.

Q: Eerst plannen of stap voor stap beslissen?
A: Korte taken gaan prima stap voor stap. Boven vijf stappen maakt een expliciet plan de run controleerbaar.

Q: Waarom herhaalt mijn agent dezelfde falende aanroep?
A: Bijna altijd omdat de foutmelding geen bruikbare informatie bevat. Geef korte, duidelijke fouten terug en voeg herhalingsdetectie toe.

## AI-agent of chatbot: wat heeft uw probleem echt nodig?
https://aiagentdevelopment.info/nl/guides/ai-agent-of-chatbot
Bijgewerkt op 2026-07-21 · Basis

- Chatbots antwoorden; agents veranderen systemen buiten het gesprek.
- Het verschil bepaalt budget, tests en de kring van goedkeurders.
- De meeste geslaagde builds zijn hybride: retrieval plus twee of drie tools.
- Log wat gebruikers vragen en niet krijgen — dat is uw toolroadmap.

De meeste teams die om een agent vragen beschrijven een chatbot, en een flink aantal dat om een chatbot vraagt beschrijft een agent. Het etiket telt, want voorbij het tekstvak hebben de twee vrijwel niets gemeen: andere storingen, andere tests, andere goedkeuringen, andere kostencurves.

De scheidslijn is simpel. Moet de software iets buiten het gesprek veranderen? Zo nee — hij legt uit, vat samen, stelt op, haalt op — dan wilt u een chatbot, waarschijnlijk met retrieval, en bent u in weken live. Zo ja — hij boekt, betaalt terug, werkt bij, verstuurt — dan wilt u een agent en plant u in maanden, want het interessante werk zit in rechten en herstelpaden, niet in de antwoorden.

### De eerlijke vergelijking
| Wat het oplevert | Tekst om te lezen | Wijzigingen in een systeem, plus tekst |
| Ergste realistische fout | Fout antwoord waarop iemand handelt | Al uitgevoerde foute handeling |
| Testen | Antwoordkwaliteit op een vragenset | Correctheid van uitkomsten over hele runs |
| Typische bouwtijd | 2–6 weken | 2–4 maanden tot productie |
| Wie keurt goed | Content en support | Ook security, data en systeemeigenaar |
| Terugkerende kosten | Tokens en contentonderhoud | Integratiedrift en onderhoud van evaluatie |

### Tekenen dat u een chatbot wilt
- De nuttige output is een uitleg, samenvatting of concept dat iemand nakijkt.
- Uw kennis verandert vaker dan uw processen.
- Er is geen API waarin u software met een gerust hart laat schrijven.
- De waarde is deflectie: minder makkelijke tickets bij mensen.

### Tekenen dat u een agent wilt
- Wie het antwoord leest, doet daarna vijf klikken in een ander systeem.
- Je moet eerst iets opzoeken voordat je weet wat de volgende stap is.
- Succes is een afgeronde transactie, geen tevreden lezer.
- Iemand volgt al een checklist, en die checklist vertakt.

### De hybride die meestal wint
Wat contact met echte gebruikers overleeft is zelden zuiver: een chatbot die twee of drie zorgvuldig gekozen tools kan aanroepen, met een menselijke poort voor alles wat onomkeerbaar is. U krijgt de snelle route naar waarde via retrievalantwoorden en voegt precies die handelingen toe die de meeste klikken schrappen.
Instrumenteer eerst de chatbot: log wat mensen vragen en hij niet kan. Dat log is uw toolroadmap, gesorteerd op vraag.

Q: Kan ik een chatbot later tot agent uitbouwen?
A: Ja, en dat is meestal de goedkoopste route. Houd retrieval, logging en promptassets los van de antwoordlus en voeg tools één voor één toe met een menselijke poort.

Q: Is een chatbot altijd goedkoper?
A: Per verzoek bijna altijd. Per uitkomst vaak niet: als de agent een taak afrondt die anders acht minuten personeelstijd kost, zijn de extra tokens verwaarloosbaar.

Q: Wat is riskanter in een gereguleerde omgeving?
A: Duidelijk de agent, want hij handelt. Dat betekent dat goedkeuringspoorten, audit en terugdraaipaden onderdeel zijn van de bouw.

## Wat is een AI-agent? Een bruikbare definitie voor bouwers
https://aiagentdevelopment.info/nl/guides/wat-is-een-ai-agent
Bijgewerkt op 2026-07-21 · Basis

- Een AI-agent beslist, handelt via echte tools, observeert en beslist opnieuw.
- Het engineeringwerk zit in de lus en de toolcontracten; het model is één component.
- Vaste volgordes zijn workflows: goedkoper, voorspelbaarder en vaak het juiste antwoord.
- Autonomie kiest u per handeling: alleen concept, alleen omkeerbaar, sandbox of onbeperkt.

Het woord agent is zo opgerekt dat het alles dekt: van een prompt met een mooie naam tot een gedistribueerd systeem met een eigen piketrooster. Dat is geen woordenschatprobleem maar een budgetprobleem: teams keuren het ene goed en krijgen het andere.

Dit is de definitie die wij gebruiken bij het afbakenen van werk, en ze is bewust smal. Een AI-agent is software waarin een taalmodel de volgende stap kiest, daarvoor een echte tool aanroept, leest wat terugkomt en opnieuw kiest — tot een doel is bereikt of een grens het stopt. Roept niets in uw systeem een tool aan, dan heeft u een zeer goede tekstgenerator. Ligt de volgorde vooraf vast, dan heeft u een workflow met een model in een van de vakjes. Beide zijn prima. Geen van beide heeft een agentbudget nodig.

### De lus is het product, niet het model
Elke agent bestaat uit dezelfde drie zetten, herhaald: beslissen, handelen, waarnemen. Het model levert alleen het beslissen. Al het andere — welke tools er zijn, hoe hun fouten geformuleerd worden, welke toestand tussen iteraties overleeft, wanneer de lus moet stoppen — is gewone software die u schrijft en waarvoor u instaat. Teams die denken dat het model het product is, besteden hun tijd aan prompts en zijn verbaasd over de onbetrouwbaarheid. Teams die de lus als product behandelen, werken aan toolcontracten en stopvoorwaarden en krijgen iets dat op een slechte middag te debuggen valt.
Nuttige test: als u het model weghaalt en er een mens neerzet die dezelfde informatie leest, klopt de rest van het systeem dan nog? Zo niet, dan is de software eromheen te dun.

### Wat een agent scheidt van waar hij mee verward wordt
| Chatbot | Niemand — het antwoordt | Nee | Fout of verzonnen antwoord |
| Workflow met een LLM-stap | De ontwikkelaar, vooraf | Ja, in vaste volgorde | Breekt bij invoer buiten de flow |
| Agent | Het model, tijdens uitvoering | Ja, ter plekke gekozen | Dwaalt af, lust, handelt op slechte data |
| Multi-agentsysteem | Meerdere modellen plus coördinator | Ja | Al het bovenstaande, lastiger te traceren |

### De vier onderdelen van elke echte agent
Haal de frameworknamen weg en elke productieagent waarmee we werkten bevat dezelfde vier onderdelen.
- Een toetsbaar doel: één zin die iemand goed of fout kan rekenen.
- Een tooloppervlak: de concrete functies, met getypeerde argumenten en eerlijke fouten.
- Een toestandsdrager: wat de volgende iteratie van de vorige mag zien.
- Stopvoorwaarden: stappenlimiet, uitgavenlimiet en een regel om over te dragen aan een mens.

### Autonomie is een draaiknop, geen schakelaar
De interessante ontwerpbeslissing is niet of u een agent gebruikt, maar hoeveel touw u hem geeft. In de praktijk zijn er vier standen, en geslaagde projecten beginnen linkser dan de demo suggereert: de agent stelt op en een mens verstuurt; de agent handelt bij omkeerbare dingen en vraagt bij onomkeerbare; de agent handelt vrij in een sandbox met uitgavenlimiet; de agent handelt vrij op productiesystemen. Elke stap naar rechts vermenigvuldigt zowel de waarde als de schade.

### Waar de definitie zich terugbetaalt
Streng zijn bespaart op drie plekken. Bij afbakenen: vijf vaste API-aanroepen met één samenvatstap is een workflow, en als agent gebouwd voegt u niet-determinisme toe dat niemand nodig had. Bij ramen: agents kosten meer omdat het faaloppervlak groter is. Bij evalueren: een agent test u pas goed als u accepteert dat dezelfde invoer verschillende paden kan nemen — dus uitkomsten toetsen, geen transcripties.
Vraagt iemand om een agent, vraag dan welke beslissing de software zelf moet nemen. Is die er niet, dan heeft u zojuist drie maanden bespaard.

Q: Is een chatbot een AI-agent?
A: Volgens deze definitie niet. Een chatbot antwoordt binnen het gesprek; een agent handelt in systemen daarbuiten. Een supportbot die uw orderdatabase leest, een terugbetaling doet en een e-mail stuurt is wél een agent.

Q: Moet een agent autonoom zijn?
A: Hij moet zijn volgende stap zelf kiezen, wat iets anders is dan onbewaakt handelen. Een agent die vijf stappen plant, er vier uitvoert en bij de vijfde om goedkeuring vraagt, blijft een agent.

Q: Heb ik een framework nodig?
A: Nee. De kleinste nuttige agent is een lus, een lijst tooldefinities en een stopvoorwaarde — misschien honderd regels.