Wat een agent in productie is

Een agent is een systeem rond een prompt

Een chatbot beantwoordt één vraag en stopt. Een agent gaat door tot de taak klaar is. Hij maakt een plan, roept een tool aan, leest het resultaat, controleert het en bepaalt de volgende stap. Die lus maakt een agent nuttig, en ook riskant: elke ronde kan een echt systeem raken.

Bij NexOps beginnen we elk agentproject met één zin: welke taak, voor wie en hoe meten we dat het goed ging? Kun je dat niet beantwoorden, dan ben je er nog niet klaar voor om een model te kiezen. Het model is één onderdeel van het systeem, en het onderdeel dat je het makkelijkst vervangt.

Deze cursus volgt één agent van ontwerp tot beheer. In deze eerste les beschrijven we de lus en de acht bouwstenen. Keuzes tussen frameworks behandelen we niet uitgebreid, want de bouwstenen blijven hetzelfde, welk framework je ook kiest.

De lus

Elke agent in productie doorloopt dezelfde zes stappen.

1. Doel. Een taak met een succesmaat, bijvoorbeeld "classificeer het binnenkomende verzoek en schrijf een antwoord dat een mens kan goedkeuren".
2. Plan. Het model verdeelt de taak in stappen. Houd plannen kort. Een lang plan is een lange lijst plekken waar het mis kan gaan.
3. Tool aanroepen. Het model vraagt de harness om een tool uit te voeren. De harness voert hem uit, niet het model, met de rechten van een afgebakend service-account.
4. Observeren. De harness geeft het resultaat terug, samen met de bron.
5. Controleren. Regels, guardrails en een evaluatieset bepalen of de stap acceptabel is.
6. Antwoorden of overdragen. De agent rondt af, of een mens beslist.

De belangrijkste ontwerpregel is dat de lus begrensd is. Stel een maximum aantal stappen in, een maximale duur en een tokenbudget. Een agent zonder grens blijft vroeg of laat hangen in een toolfout en besteedt je budget daaraan.

De acht bouwstenen

Dezelfde onderdelen zitten in elke agent die we bouwen. Behandel elk onderdeel als iets dat je configureert, test en beheert.

Les 2 tot en met 8 behandelen deze bouwstenen een voor een.

Een minimale lus in code

Het voorbeeld hieronder toont de vorm van een begrensde lus. Het is schematisch: het laat de besturing zien, niet de API van een framework.

# Schematische agentlus. De namen zijn plaatsaanduidingen, geen echte framework-API.
MAX_STEPS = 8          # harde grens op het aantal rondes in de lus
TOKEN_BUDGET = 40_000  # harde grens op tokens voor één taak
 
def run_agent(task, model, tools, checks):
    state = {"task": task, "history": [], "tokens": 0}
    for step in range(MAX_STEPS):
        decision = model.decide(state)               # plannen of antwoorden
        if decision.kind == "answer":
            return checks.final(decision.text, state)  # laatste poort voor de gebruiker
        if decision.tool not in tools:               # standaard weigeren
            state["history"].append(("error", "unknown tool"))
            continue
        result = tools[decision.tool].run(decision.args)  # draait met een afgebakende identiteit
        state["history"].append((decision.tool, result))  # resultaat en bron
        state["tokens"] += model.last_usage
        if state["tokens"] > TOKEN_BUDGET:
            return handover(state, reason="budget")  # een mens neemt over
    return handover(state, reason="step limit")

Drie details tellen. De toollijst is een toegestane lijst, dus een onbekende tool is een fout en nooit een improvisatie. Elk resultaat gaat samen met zijn bron in de geschiedenis. En beide uitgangen, budget en staplimiet, dragen de taak over aan een mens in plaats van stilletjes te falen.

Waar de agentlus aansluit op het platform

Op Databricks sluiten de onderdelen zo op elkaar aan. Tools bereik je via MCP-servers, die door Databricks beheerd, eigen of extern kunnen zijn, en Unity Catalog-rechten sturen de beheerde servers aan. Gespreksstate en langetermijngeheugen staan in beheerde stores op basis van Lakebase. MLflow Tracing legt elke stap vast met invoer, uitvoer, latency en tokengebruik. Unity Gateway staat voor de modellen en voegt toegangsbeheer, budgetten, limieten en logging toe. De huidige documentatie noemt het Unity Gateway; veel teams, en onze site, zeggen nog Unity AI Gateway.

Lees dit niet als een boodschappenlijst. Begin bij de taak en de maat, en voeg alleen de bouwstenen toe die de taak nodig heeft. Een antwoordschrijver voor een interne servicedesk heeft minder tools nodig dan een agent die je ERP bijwerkt.

Veelgemaakte fouten

• Beginnen met het framework. Kies eerst de taak en de evaluatieset. Frameworks komen en gaan; de lus blijft.
• Eén grote agent. Meerdere kleine agents met elk één taak zijn makkelijker te testen dan één agent met twintig tools.
• Geen grens. Stel altijd limieten in voor stappen, tijd en tokens.
• Geen overdracht. Bepaal wie overneemt en hoe die persoon ziet wat de agent deed.

Samenvatting

Een agent is een begrensde lus rond een model met afgebakende tools, geheugen, guardrails, evaluatie en een mens die kan goedkeuren. Het model is vervangbaar. De lus, de grenzen en het bewijs houd je.

In de volgende les kijken we naar de bouwsteen met het meeste risico: tools.