Vraag een chatbot naar een late bestelling en hij geeft je advies. Vraag het aan een AI-agent en deze kan de bestelling opzoeken, de vertraging controleren, een voucher toepassen en terugrapporteren. Het verschil is dat een agent actie kan ondernemen en kan reageren op wat er gebeurt, in plaats van slechts één antwoord te geven.

In marketing wordt de term steeds uitgebreider, dus deze gids blijft bij de manier waarop deze systemen daadwerkelijk werken. Om het concreet te maken, hebben we een kleine agentlus in Python 3.13 gebouwd en uitgevoerd, en de onderstaande uitvoer is afkomstig van die runs. Ons ‘model’ is een scriptfunctie, geen echt AI-model, zodat de lus door iedereen kan worden uitgevoerd en getest. Het toont de controlestructuur, niet de intelligentie. Nieuw bij de basis? Lees eerst wat een groot taalmodel is.

Wat is een AI-agent?

Er bestaat geen eenduidige definitie. In de huidige praktijk is een AI-agent software die een doel nastreeft door herhaaldelijk te beslissen wat er vervolgens moet gebeuren, tools te gebruiken om op de wereld in te spelen en zich aan te passen op basis van resultaten. Meestal komt de besluitvorming voort uit een groot taalmodel.

Denk eens aan het verschil tussen iemand die aanwijzingen geeft en iemand die de boodschap doet. De eerste antwoorden één keer. De tweede gaat naar buiten, vindt de winkel gesloten, probeert een andere en komt pas terug als de klus geklaard is.

Chatbot, workflow of agent?

Deze bestaan op een spectrum, en veel nuttige systemen zijn een mix. De belangrijkste vraag is hoeveel van het pad tijdens runtime wordt bepaald.

Wat zit er in een agent?

De agentenlus

1. Beslis. Het model kijkt naar het doel en de geschiedenis, en kiest een actie of besluit dat deze is voltooid.
2. Act. Uw code voert de gevraagde tool uit.
3. Observeren. Het resultaat wordt toegevoegd aan de geschiedenis.
4. Herhaal totdat het doel is bereikt of een limiet is bereikt.

Dat is de kern van de meeste agenten. De verfijning ligt vooral in het model, de tools en de beveiligingen rondom deze lus.

Een lus die je kunt lopen

Onze kleine agent handelt vertraagde bestellingen af. Het heeft twee instrumenten, en één ervan heeft menselijke goedkeuring nodig omdat het geld kost:

ORDERS = {
    "A100": {"status": "delayed", "days_late": 6},
    "B200": {"status": "shipped", "days_late": 0},
}

def get_order(order_id):
    return ORDERS.get(order_id, {"error": "order not found"})

def issue_voucher(order_id, amount):
    return {"voucher": f"V-{order_id}", "amount": amount}

TOOLS = {"get_order": get_order, "issue_voucher": issue_voucher}
NEEDS_APPROVAL = {"issue_voucher"}

En hier is de lus zelf. Het is gewone code en elke veiligheidsregel leeft hier in plaats van in het model:

def run_agent(goal, model, approve, max_steps=5):
    history = []
    for step in range(1, max_steps + 1):
        decision = model(goal, history)
        if "finish" in decision:
            return decision["finish"]

        name, args = decision["tool"], decision["args"]
        if name in NEEDS_APPROVAL and not approve(name, args):
            result = {"denied": True}
        else:
            result = TOOLS[name](**args)

        history.append({"tool": name, "result": result})
    return None   # stopped: step limit reached

Om een echt model te gebruiken, zou je de functie model vervangen door een aanroep naar een LLM API, waarbij je het doel, de geschiedenis en beschrijvingen van je tools doorgeeft. De lus blijft vrijwel hetzelfde.

Wat er gebeurde tijdens onze runs

We hebben vijf situaties uitgeprobeerd met de scriptbeslissingsfunctie en elke stap vastgelegd.

Een vertraagde bestelling, waarbij de voucher is goedgekeurd

step 1: get_order({'order_id': 'A100'}) -> {'status': 'delayed', 'days_late': 6}
step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'voucher': 'V-A100', 'amount': 200}
step 3: finish -> Sorry for the delay. Voucher V-A100 issued.

Bij elke stap werd het resultaat van de voorgaande stap gebruikt. De voucher werd pas in aanmerking genomen nadat de vertraging was bevestigd.

Hetzelfde bevel, waarbij de goedkeuring werd geweigerd

step 2: issue_voucher({'order_id': 'A100', 'amount': 200}) -> {'denied': True}
step 3: finish -> Your order is late. A person will review compensation.

De mens zei nee, de tool werkte nooit en de agent paste zijn antwoord aan.

Een onbekende bestelling

step 1: get_order({'order_id': 'Z999'}) -> {'error': 'order not found'}
step 2: finish -> I could not find that order.

Tools duidelijke foutmeldingen geven helpt. Een echt model kan ze lezen en verstandig reageren, in plaats van te raden.

Een model dat vastloopt

We hebben ook een defecte beslissingsfunctie ingewisseld die dezelfde actie voor altijd herhaalde:

step 1: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 2: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
step 3: get_order({'order_id': 'B200'}) -> {'status': 'shipped', 'days_late': 0}
stopped: step limit reached

Agenten kunnen echt in dit soort lussen terechtkomen, en elke stap met een echt model kost geld. Zonder max_steps zou deze nooit zijn geëindigd.

Hoe hulpmiddelen werken

Dit is het meest verkeerd begrepen deel. Een taalmodel kan niets op zichzelf uitvoeren. Het produceert gestructureerde tekst waarin staat welk hulpmiddel het wil, met welke argumenten. Uw code beslist of deze wordt uitgevoerd. Daarom is de lus de juiste plek voor machtigingen, validatie en logging.

Modelaanbieders bieden hiervoor tool- of functieaanroepen. Het Model Context Protocol (MCP) is een open standaard voor het verbinden van modellen met tools en gegevens, en ons artikel over Playwright MCP laat één gebruik zien. Schrijf duidelijke gereedschapsnamen en -beschrijvingen, omdat het model ervan afhankelijk is om de juiste keuze te maken.

Geheugen

Lange taken kunnen het contextvenster van een model ontgroeien, waardoor systemen vaak oudere stappen samenvatten. In samenvattingen kunnen details verloren gaan, wat een van de redenen is dat langlopende agenten van hun koers kunnen afwijken.

Multi-agentsystemen

Sommige systemen verdelen het werk over verschillende gespecialiseerde agenten, zoals een planner, een onderzoeker en een recensent. Dit kan helpen bij grote taken die netjes verdeeld zijn. Het voegt ook kosten toe, meer manieren om te falen en moeilijker debuggen. Probeer eerst een enkele agent met goede tools en splits deze alleen als er een duidelijke reden is.

Risico’s en limieten

• Verkeerde acties. De fout van een chatbot is een slechte zin. De fout van een agent kan een verzonden e-mail of een verwijderd record zijn.
• Snelle injectie. Een webpagina of e-mail die de agent leest, kan verborgen instructies bevatten. Behandel alle tooluitvoer als niet-vertrouwde gegevens, niet als opdrachten.
• Samengestelde fouten. Een kleine fout in het begin kan elke latere stap in de verkeerde richting sturen.
• Kosten en latentie. Elke stap kan een andere modelaanroep zijn, waardoor een taak veel langzamer en duurder kan zijn dan een enkele prompt.
• Inconsistentie. Hetzelfde doel kan bij elke run een ander pad volgen, waardoor testen moeilijker wordt.
• Verantwoording. Mensen blijven verantwoordelijk voor wat het systeem doet, dus houd een administratie bij.

Vangrails die ertoe doen

1. Minste rechten. Geef elke agent alleen de tools en toegang die hij nodig heeft.
2. Menselijke goedkeuring voor alles wat duur, onomkeerbaar of extern is, zoals onze demo doet.
3. Harde limieten voor stappen, tijd en uitgaven.
4. Valideer toolinvoer in code en vertrouw niet op instructies van het model.
5. Log elke stap, zodat je kunt zien waarom er iets is gebeurd. Zie monitoring versus waarneembaarheid.
6. Test met echte scenario’s, inclusief mislukkingen. Controleer de eindresultaten en individuele antwoorden. Onze gids met best practices voor AI-agenten gaat verder over de implementatie.

Wanneer moet u een agent gebruiken?

Codeerassistenten zijn tegenwoordig een van de meest volwassen voorbeelden, omdat ze bestanden kunnen lezen, tests kunnen uitvoeren, fouten kunnen zien en het opnieuw kunnen proberen, terwijl een mens het resultaat beoordeelt. Een testsuite geeft hen een duidelijk signaal van succes. Onze gids voor snelle engineering is ook van toepassing op het schrijven van goede instructies voor agenten. Begin met het eenvoudigste dat kan werken, want een goed gemotiveerd telefoontje is vaak beter dan een ingewikkelde agent.

Tot slot

Een AI-agent is minder mysterieus dan het klinkt: een model, enkele tools en een lus met limieten. Het moeilijkste deel is vertrouwen, niet de code. Om te leren hoe ze zich gedragen, neem je onze kleine lus, verbind je deze met een echt model met alleen-lezen tools en bekijk je de logboeken terwijl deze werken. Je zult snel zien waar het schittert en waar het een mens nodig heeft.

Veelgestelde vragen

Blijf leren