Wat zijn de verschillende typen AI-agents?

Wat de typen AI-agents zijn

De typen AI-agents zijn afkomstig uit één taxonomie: eenvoudige reflex-agents, modelgebaseerde reflex-agents, doelgebaseerde agents, nutgebaseerde agents en lerende agents. Elke naam beschrijft één aspect: hoeveel de agent onthoudt en hoe ver vooruit hij plant voordat hij actie onderneemt. Twee aanvullende termen, multi-agent en hiërarchisch, beschrijven hoe meerdere agents met elkaar zijn verbonden in plaats van hoe een individuele agent beslissingen neemt.

Deze lijst is ouder dan elk model dat u heeft gebruikt. Hij is afkomstig uit het standaard AI-leerboek en heeft de komst van large language models overleefd omdat hij de vraag stelt die nog steeds uw ontwerp bepaalt: wat moet dit systeem weten voordat het actie onderneemt? Als u nog probeert te bepalen waar een agent eindigt en een chat-assistent begint, lees dan eerst het verschil tussen een AI-agent en het LLM waarop deze draait. Deze pagina begint na die grens.

Eenvoudige reflex-agents: één voorwaarde, één actie

Een eenvoudige reflex-agent koppelt de huidige invoer aan een actie en houdt geen geheugen bij van eerdere gebeurtenissen. Als de temperatuur boven de 25 is, schakel de ventilator in. Dat is het volledige mechanisme.

U heeft er vrijwel zeker al eens een uitgevoerd. Een webhook die een n8n-workflow activeert, die een formulierinzending leest en een rij naar een database schrijft, is een eenvoudige reflex-agent. Het blijft er een, zelfs wanneer er een taalmodel tussenin staat dat een categorie voor die rij kiest. Vraag het wat het een uur geleden heeft gedaan en het kan u geen antwoord geven, omdat niets het antwoord heeft bewaard.

Dit type is vaker correct dan mensen verwachten. Het is goedkoop om uit te voeren en het falen ervan is inzichtelijk: de voorwaarde kwam overeen, of niet. Wanneer de taak daadwerkelijk "wanneer X binnenkomt, doe Y" is, voegt geheugen alleen manieren toe om fouten te maken zonder dat dit iets oplevert. Een door een webhook geactiveerde n8n-agent is deze rij van de taxonomie met een gebruikersinterface erbovenop.

Het systeem faalt op het moment dat de juiste actie afhankelijk is van de geschiedenis. Een antwoordbot zonder thread-status zal zichzelf bij het derde bericht tegenspreken, omdat de eerste twee berichten nooit deel uitmaakten van de invoer.

Model-based reflex agents: status behouden tussen gebeurtenissen

Een model-based reflex agent houdt een intern beeld van zijn omgeving bij en werkt dit beeld bij zodra er nieuwe input binnenkomt. Het woord "model" verwijst hier naar een wereldmodel, niet naar een neuraal netwerk. Deze term bestond al veertig jaar voordat de huidige betekenis populair werd, wat bij de eerste lezing bijna iedereen in verwarring brengt.

Een regel voor huisautomatisering die verlichting uitschakelt na twintig minuten zonder beweging is model-based. Dat moet ook wel. "Nu geen beweging" en "geen beweging sinds 21:40" zijn voor een eenvoudige reflex agent dezelfde input; alleen opgeslagen status kan het verschil tussen beide aangeven.

De LLM-versie is elke agent met een geheugenopslag erachter: een doorlopende samenvatting van het gesprek, of een simpel markdown-bestand dat de agent aan het begin van elke run leest. Een lokale geheugenservice voor een agent is diezelfde gedachte in een verpakte vorm. Het mechanisme verandert niet. Het wereldbeeld van de agent overleeft de gebeurtenis die het heeft gecreëerd.

Status heeft een prijs. Een verouderd feit is erger dan geen feit, omdat de agent er met volledig vertrouwen en zonder waarschuwing naar handelt. Alles wat u opslaat, moet een manier hebben om te verlopen of opnieuw te worden gecontroleerd, anders blijft de agent redeneren over een server die u in maart buiten gebruik hebt gesteld.

Doelgerichte agents: plannen naar een verifieerbare status

Een doelgerichte agent ontvangt een gewenste eindstatus en zoekt naar een reeks acties om deze te bereiken. De agent werkt terug vanaf het einddoel, waardoor het pad niet vooraf vastligt.

Een programmeer-agent is het duidelijkste voorbeeld dat u zelf kunt draaien. "Zorg dat de falende test slaagt" specificeert geen bestanden of stappen. De agent leest de test, stelt een plan op, wijzigt code, voert de test uit, leest de foutmelding en probeert het opnieuw. De lus eindigt bij een controle die de agent daadwerkelijk kan uitvoeren; daarom werkt die instructie wel en "verbeter deze code" niet. Een doel dat de agent kan evalueren, is een doel dat de agent kan bereiken. Een doel dat de agent niet kan evalueren, resulteert in een oneindige lus met bijbehorende kosten. Een programmeer-agent draaien op uw eigen VPS plaatst die lus op een plek waar deze kan draaien zonder uw laptop te belasten.

De kosten zitten in deze cyclus. Elke planningsstap is een nieuwe model-aanroep die de volledige geschiedenis tot dan toe meeneemt; een taak van tien stappen kost dus meer dan tien keer de prijs van één stap. De essentie van de techniek zit in de vorm van de lus en de voorwaarde die deze stopt, wat het onderwerp is van loop engineering.

Utility-gebaseerde agents: kiezen tussen meerdere goede antwoorden

Een doel is binair. Utility is een score. Een utility-gebaseerde agent krijgt te maken met meerdere acceptabele uitkomsten en kiest degene die het hoogst scoort volgens een functie die u heeft geschreven.

Een back-up-taak die voor aanvang van de werkdag voltooid moet zijn zonder de uplink te verzadigen, is een utility-probleem. Er is geen enkel correct antwoord, alleen een afweging. Een router die beslist welk model welk verzoek afhandelt, waarbij prijs wordt afgewogen tegen de kwaliteit van het antwoord, heeft dezelfde structuur.

Het algoritme is niet het lastige gedeelte. Het schrijven van een eerlijke utility-functie wel. Scoor alleen op kosten en u krijgt bij elk verzoek het goedkoopste model, inclusief het ene verzoek dat het dure model nodig had. Het systeem optimaliseert precies wat u heeft gemeten, wat een probleem vormt wanneer datgene wat u mat, werd gekozen omdat het eenvoudig te meten was.

Leeragenten: het type waarvan de meeste mensen aannemen dat ze het al hebben

Een leeragent past zijn eigen gedrag aan op basis van feedback over resultaten uit het verleden. Hiervoor is een mechanisme nodig dat de uitkomst beoordeelt en een mechanisme dat het beleid als reactie daarop wijzigt.

Zeer weinig zelfgehoste systemen voldoen aan deze definitie. Een agent die notities leest die hij vorige week heeft geschreven, is een modelgebaseerde agent met een geheugenbestand. De gewichten zijn identiek. Het beleid is identiek. Het ophalen van informatie is geen leren, en dit onderscheid is praktisch: een geheugengebaseerd systeem herhaalt een fout eeuwig tenzij het geheugen wordt aangepast, terwijl een leersysteem geacht wordt de fout niet meer te maken.

Als u het leeraspect wilt implementeren, bouw dan eerst de evaluatie. Een gescoorde testset, het uitvoeren van uw wijziging tegen deze set, en een besluit om de wijziging te behouden of te verwerpen, vormen een gesloten lus waarin u zelf de lerende component bent. Dat is trager dan het klinkt, en het is de enige versie die momenteel werkt voor zelfgehoste onderdelen. Zelf een evaluatie-omgeving hosten is waar dat begint.

Multi-agent en hiërarchische systemen: configuraties, geen typen

Dit zijn geen zesde en zevende type. Ze beschrijven hoe agents zijn georganiseerd.

Een multi-agent systeem voert meerdere agents tegelijk uit in een gedeelde omgeving, zoals een wachtrij of een git repository. Omdat de omgeving gedeeld is, ontstaan er conflicten. Twee agents die hetzelfde bestand bewerken is het standaardprobleem; de oplossing is een lock of een werkrij. Geen enkele prompt lost dit op.

Een hiërarchisch systeem plaatst een supervisor boven werkers. De supervisor splitst een taak, verdeelt de onderdelen en voegt de resultaten samen. Dit is populair omdat het overeenkomt met hoe mensen werk verdelen, en het is kostbaar omdat de context van de supervisor groeit met elk rapport dat deze leest. Een multi-agent harness toont hoe dit in de praktijk wordt opgezet.

Eén agent die werkt is beter dan vier die grotendeels werken.

Elke overdracht is een punt waar informatie verloren kan gaan. Begin met één lus. Splits deze pas wanneer u de stap kunt benoemen die de bottleneck vormt.

Waarom bijna elk reëel systeem een hybride is

Denk aan een deployment-agent die u zelf zou draaien. Een webhook start deze, wat reflexief is. De agent leest de huidige release-status, wat modelgebaseerd is. Hij plant de stappen van de draaiende versie naar de doelversie, wat doelgebaseerd is. Hij kiest een uitrolvenster op basis van de huidige belasting, wat utiliteitsgebaseerd is. De agent past zijn eigen beleid nooit aan, dus hij leert niet.

Eén systeem, vier rijen van de taxonomie tegelijkertijd. De taxonomie bewijst zijn waarde als ontwerpchecklist, niet als label voor het eindproduct. Wanneer het systeem zich misdraagt, is de nuttige vraag welke laag fout is. Een trigger die afging bij de verkeerde gebeurtenis, een status die verouderd raakte, een doelcontrole die nooit kan slagen en een score die de verkeerde uitkomst beloont, zijn vier verschillende bugs met vier verschillende oplossingen.

Welk type is geschikt voor welke taak

• Vaste trigger, vaste respons, geen historie vereist: eenvoudige reflex.
• De juiste respons hangt af van wat er eerder is gebeurd: modelgebaseerde reflex.
• De eindtoestand is controleerbaar, maar het pad is vooraf onbekend: doelgebaseerd.
• Meerdere acceptabele uitkomsten met een reële afweging tussen de opties: utility-gebaseerd.
• U heeft resultaten nodig die in de loop van de tijd verbeteren: bouw een evaluatielus en accepteer dat u zelf de lerende component bent.

Kunt u deze agents zelf hosten en wat zijn de kosten?

Ja, en de kosten vallen uiteen in twee delen. Orchestratie is goedkoop. Een n8n-instantie of een agent-loop in Python brengt het grootste deel van de tijd door met wachten op netwerkaanroepen, dus 2 vCPU en 4 GB RAM volstaan. Het model is waar de kosten zitten.

Als de agent een gehoste API aanroept, heeft de server vrijwel niets nodig en schaalt de rekening mee met het aantal tokens. Voor een doelgerichte agent betekent dit dat de kosten schalen met het aantal planningsstappen dat u toestaat; stel daarom een limiet in op de loop.

Als u het model op uw eigen hardware draait, bepaalt het RAM-geheugen wat u überhaupt kunt draaien. De onderstaande cijfers zijn typische gepubliceerde bestandsgroottes voor 4-bit gekwantiseerde gewichten per augustus 2026, naast een schatting voor het totale RAM-geheugen, omdat zowel het contextvenster als de runtime ruimte nodig hebben naast de gewichten zelf.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

Een 8B-model op 4-bit is ongeveer 4.9 GB aan gewichten, en een systeem met 10 GB RAM draait dit zonder swapping. Een 70B-model bij dezelfde kwantisatie is 43 GB aan gewichten en vereist ongeveer 64 GB. Let op wat deze cijfers buiten beschouwing laten: snelheid. Op een VPS zonder GPU produceert een 8B-model op 4-bit slechts enkele tokens per seconde. Dat is acceptabel voor een agent die 's nachts een wachtrij verwerkt, maar traag voor alles waar een gebruiker op moet wachten. Gebruik lokale inferentie voor batchverwerking en gebruik een GPU of een API voor interactieve taken. De shortlist van zelf te hosten AI-agents behandelt welke projecten de schijfruimte waard zijn, en een studiepad voor agents in 2026 behandelt wat u in welke volgorde moet leren.

Waar de taxonomie tekortschiet

De taxonomie biedt geen informatie over tools of rechten. De tekstboek-agents nemen waar en handelen. De auteurs van dat hoofdstuk hielden geen rekening met een agent die beschikt over een productie-API-token. Een doelgerichte agent met shell-toegang en een doelgerichte agent met enkel een alleen-lezen databaseverbinding staan in dezelfde rij van de tabel, terwijl ze een totaal verschillend risico vormen. Bepaal waartoe een agent toegang heeft voordat u besluit hoe intelligent deze moet zijn, en lees hoe u geheimen buiten een AI-agent houdt voordat u deze inloggegevens verstrekt.

De taxonomie vermeldt eveneens niets over wat er gebeurt wanneer een stap faalt. Echte agents besteden het grootste deel van hun runtime aan het afhandelen van fouten: een rate limit, of een tool die een onverwachte uitvoer teruggeeft aan het model. Die code bepaalt of uw systeem bruikbaar is, en geen enkele rij in de taxonomie beschrijft dit proces.

FAQ

Wat zijn de vijf typen AI-agents?

Simple reflex, model-based reflex, goal-based, utility-based en learning agents. Ze zijn gerangschikt op basis van de hoeveelheid kennis die de agent bezit voordat deze actie onderneemt. Een simple reflex agent ziet alleen de huidige invoer. Een model-based agent houdt de status van zijn omgeving bij. Een goal-based agent plant acties richting een doelstatus. Een utility-based agent beoordeelt verschillende acceptabele uitkomsten en kiest de beste. Een learning agent past zijn eigen beleid aan op basis van feedback; dit is iets wat vrijwel geen enkele zelfgehoste opstelling daadwerkelijk doet.

Welk type AI-agent moet ik gebruiken voor een eenvoudige automatisering?

Een simple reflex agent, wat in de praktijk neerkomt op een webhook of een planning die een vaste reeks acties activeert. Als de juiste reactie alleen afhangt van de zojuist ontvangen invoer, voegt geheugen alleen storingsbronnen toe zonder extra functionaliteit. Stap over op een model-based ontwerp zodra u één beslissing kunt benoemen die moet weten wat er in het verleden is gebeurd.

Kan ik mijn eigen AI-agents draaien op een VPS?

Ja. De orchestratielaag is licht, dus 2 vCPU en 4 GB RAM is ruim voldoende om een workflow-engine of een agent-loop te draaien. De werkelijke afweging is waar het model draait. Een gehoste API houdt de server licht en verplaatst de kosten naar tokens. Een lokaal model vereist RAM in verhouding tot het aantal parameters, en zonder GPU genereert het slechts enkele tokens per seconde, wat geschikter is voor batchverwerking in een wachtrij dan voor een chatvenster.

Is een large language model op zichzelf een AI-agent?

Nee. Een model vertaalt invoertekst naar uitvoertekst en stopt daarna. Het wordt pas een agent wanneer iets het model in een lus verpakt die actie kan ondernemen in de wereld en het resultaat terug kan voeren; hiervoor zijn tools nodig die het model kan aanroepen en een voorwaarde die de lus vertelt wanneer deze moet stoppen. De wrapper is de agent. Het model is slechts één onderdeel daarvan.

Heb ik een multi-agent systeem nodig?

Meestal niet. Een enkele lus met verschillende tools volstaat voor het meeste werk en is veel eenvoudiger te debuggen. Meerdere agents zijn nuttig wanneer onderdelen van een taak echt onafhankelijk zijn en tegelijkertijd kunnen draaien, of wanneer een onderdeel een ander model vereist. De kosten zitten in de coördinatie: gedeelde status en een supervisor wiens context groeit met elk rapport van een worker dat hij leest. Voeg pas een tweede agent toe wanneer u de specifieke stap kunt aanwijzen die traag is.