arrow_backTerug naar veldaantekeningen
AI Gepubliceerd 5 Aug 2026

Bouw een werkende AI Agent: Een praktische woordenlijst

Wat een AI agent eigenlijk is, hoe het verschilt van een chatbot, en welke componenten je nodig hebt om er een te bouwen die werkt.

Een AI agent is een programma dat een doel neemt, een reeks acties bepaalt en die acties met behulp van tools uitvoert totdat het doel bereikt is of het opgeeft. Dat verschilt van een chatbot, die alleen op berichten reageert. Een agent plant, roept functies aan, controleert resultaten en past zich aan. Als je ChatGPT tot nu toe alleen via een browser hebt gebruikt, is het bouwen van je eerste agent waar het model stopt een tekstgenerator te zijn en begint een component in een groter systeem te zijn.

De kernlus

Elke agent, ongeacht hoe deze wordt aangeprezen, voert een versie van dezelfde lus uit: observeer, denk na, handel, herhaal. Concreet:

  1. De agent ontvangt een taak ("vind het goedkoopste vliegticket naar Lissabon volgende maand en schrijf een samenvatting per e-mail").
  2. Het roept de LLM aan met de taak plus een beschrijving van beschikbare tools.
  3. Het model geeft ofwel een eindantwoord ofwel een toolk aanroep terug, zoals search_flights(destination="Lisbon", month="2025-06").
  4. Je code voert die functie uit, krijgt een echt resultaat en voert dit terug in de context van het model.
  5. Het model beslist wat er volgende moet gebeuren: een ander tool aanroepen, om verduidelijking vragen of stoppen.

Dit patroon wordt vaak de ReAct loop genoemd (reason plus act), en het is de ruggengraat van frameworks zoals LangChain's agent executors, LlamaIndex agents en OpenAI's function-calling API. Je kunt het hele ding zelf implementeren in minder dan 100 regels Python met alleen een LLM API en een while loop — de frameworks voegen gemak toe, geen magie.

Tools maken het tot een agent

Een model zonder tools kan alleen praten. Geef het functies en het kan handelen. Tools zijn meestal gewone Python functies verpakt met een schema dat hun naam, parameters en doel beschrijft, zodat het model weet wanneer en hoe het ze moet aanroepen. Voorbeeld:

def get_weather(city: str) -> str:
    """Return current weather for a given city."""
    resp = requests.get(f"https://api.weather.example/v1/{city}")
    return resp.json()["summary"]

Met OpenAI's function-calling geef je een JSON schema naast deze functie, en het model geeft een gestructureerde aanroep uit als {"name": "get_weather", "arguments": {"city": "Lisbon"}} in plaats van vrije tekst. Je code parseert dat, voert de echte functie uit en geeft het resultaat terug als een nieuw bericht in het gesprek. Herhaal totdat het model genoeg informatie heeft om te antwoorden.

Geheugen en staat

Een enkele API-aanroep heeft geen geheugen voorbij zijn context window. Agents hebben expliciete staat nodig: een lopende lijst met berichten (de gespreksgeschiedenis) en vaak een aparte opslag voor langetermijnfeiten. Voor korte taken is een Python list met dicts die het gesprek voorstellen genoeg. Voor agents die dingen over sessies heen moeten onthouden, grijp je naar een vector database (Chroma, Pinecone, Qdrant) om relevante vorige informatie via embeddings op te slaan en op te halen.

Over-engineer dit niet vroeg. Een verrassend aantal "agent" projecten faalt niet omdat de LLM zwak is maar omdat state management slordig is: dubbele berichten, onbegrensde context groei, of verliezen uit het oog welke tool aanroep bij welk resultaat hoort.

Een minimaal werkend voorbeeld

Hier is de vorm van een basis agent met OpenAI's API, geen framework:

messages = [{"role": "user", "content": "What's the weather in Lisbon?"}]

while True:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=[weather_tool_schema],
    )
    msg = response.choices[0].message
    if msg.tool_calls:
        for call in msg.tool_calls:
            result = get_weather(**json.loads(call.function.arguments))
            messages.append(msg)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result,
            })
    else:
        print(msg.content)
        break

Dat is een echte, functionerende agent. Alles anders — planningsstrategieën, multi-agent coördinatie, retrieval pipelines — bouwt op deze lus voort.

Waar het faalt

Agents falen op voorspelbare manieren: oneindige tool-call loops wanneer het model niet kan zien dat het is geslaagd, gehallucineerde functieargumenten en weglopende kosten door dure tools opnieuw aan te roepen. Bescherm je tegen loops met een harde iteratie limiet (zeg, 10 stappen) en log elke tool aanroep tijdens ontwikkeling. Valideer argumenten voordat je iets uitvoert dat een echt systeem aanraakt — een agent die e-mails kan versturen of shell-commando's kan uitvoeren, heeft dezelfde input sanering nodig die je op gebruikersgerichte code zou toepassen, want de LLM is in feite een niet-vertrouwde gebruiker die die invoer genereert.

Waar nu heen

Zodra de lus werkt, beginnen de interessante problemen: kiezen tussen single-agent en multi-agent designs, bepalen hoeveel autonomie je verleent en agents betrouwbaar testen wanneer hun output niet deterministisch is. Korra Studio's AI en Python tracks behandelen retrieval-augmented generation, prompt design en tool-calling patterns meer gedetailleerd als je van hier uit wilt blijven bouwen.

Geschreven met AI-ondersteuning, herzien en gepubliceerd door Michal Pilch (CISSP), Korra Studio.

Klaar om verder te gaan?

Dit is één aantekening uit de kennisbasis van Korra Studio — het platform koppelt elk onderwerp aan 1-op-1 mentoring.

Gratis beginnenarrow_forward