Human-in-the-loop AI-agents: ontwerppatronen

Een AI-agent is een systeem dat met een taalmodel bepaalt welke acties het neemt, tools aanroept om ze uit te voeren en in meerdere stappen naar een doel toewerkt. Daardoor zijn agents nuttig voor operationeel werk, zoals uitzonderingen bij zendingen afhandelen, facturen triëren of antwoorden aan klanten voorbereiden. Het betekent ook dat het systeem handelt, en acties hebben gevolgen die gegenereerde tekst alleen niet heeft.

Dit artikel is voor operationeel leidinggevenden en engineers die agents ontwerpen die met echte systemen werken. Human-in-the-loop-ontwerp betekent dat je vooraf, en in code, vastlegt welke besluiten een agent zelf neemt, welke hij voorlegt aan een mens ter goedkeuring en welke hij nooit neemt. Doe je dat goed, dan automatiseer je het grootste deel van het volume en handelen mensen de zaken af die een eigen oordeel vragen.

Een goedkeuringsstap zet de agent op pauze voor een actie met gevolgen. Een mens ziet wat de agent wil doen en waarom, en de agent gaat pas verder na goedkeuring. De belangrijkste ontwerpkeuzes:

• Waar je pauzeert. Zet goedkeuringsstappen voor acties die moeilijk terug te draaien zijn of die buiten de organisatie komen: betalingen, terugbetalingen, e-mails aan klanten en wijzigingen in bronsystemen.
• Wat je laat zien. De voorgestelde actie, de input waarop die is gebaseerd, de redenering in een of twee zinnen en de bron van elke bewering, zoals de beleidsclausule of het orderrecord.
• Hoe iemand reageert. Goedkeuren, aanpassen en dan goedkeuren, afwijzen met een reden, of de zaak overnemen. Afwijzingen met een reden zijn waardevolle data voor evaluaties.
• Wat er gebeurt tijdens het wachten. De status van de agent wordt opgeslagen, zodat hij uren later verder kan. Goedkeuringen verlopen als ze te lang blijven liggen.

Het goedkeuringsscherm bepaalt of de stap werkt. Heeft een beoordelaar vijf minuten nodig om de context te reconstrueren, dan gaat hij goedkeuren zonder te lezen. Staan de reden en het bewijs op het scherm, dan kosten de meeste goedkeuringen een paar seconden.

Een goedkeuringsstap bij elke actie maakt automatisering zinloos. Door te routeren op risico en zekerheid blijven mensen bij de zaken die hen nodig hebben. We delen elke tool in op risico en bepalen dan per actie of die wordt uitgevoerd, op goedkeuring wacht of wordt geweigerd:

from dataclasses import dataclass
from enum import Enum

class Risk(Enum):
    READ = "read"
    REVERSIBLE = "reversible"
    IRREVERSIBLE = "irreversible"

TOOL_RISK = {"lookup_order": Risk.READ, "draft_reply": Risk.REVERSIBLE, "issue_refund": Risk.IRREVERSIBLE}
AUTO_THRESHOLD = 0.85

@dataclass
class ProposedAction:
    tool: str
    args: dict
    confidence: float  # built from checkable signals, see below
    reason: str

def route(action: ProposedAction) -> str:
    risk = TOOL_RISK.get(action.tool)
    if risk is None:
        return "reject"  # unknown tools never run
    if risk is Risk.READ:
        return "execute"
    if risk is Risk.REVERSIBLE and action.confidence >= AUTO_THRESHOLD:
        return "execute"
    return "queue_for_approval"

Een waarschuwing over zekerheid: de zekerheid die een model zelf opgeeft, is slecht gekalibreerd, dus gebruik die nooit als enige signaal. Bouw de score op uit signalen die je kunt controleren, zoals of de uitgelezen velden de validatie doorstonden, of het opgehaalde beleid de zaak duidelijk dekt, of twee onafhankelijke runs het eens zijn en hoe vergelijkbare zaken scoorden in je testset. Stel de drempel daarna af op echte uitkomsten. Begin voorzichtig en verlaag hem als de data dat ondersteunt.

Een agent kan alleen doen wat zijn tools toestaan. Daardoor is het ontwerp van tools de meest effectieve veiligheidsmaatregel die je hebt.

Regels die we bij elke agent toepassen:

• Geef de agent smalle tools, zoals issue_refund(order_id, amount), en vermijd algemene tools zoals run_sql.
• Dwing limieten af in de code van de tool: maximale bedragen, toegestane ontvangers en rate limits. De prompt stuurt de agent; de tool handhaaft de regels.
• Laat tools draaien met credentials die alleen voor de agent gelden, nooit met die van een beheerder.
• Behandel tekst die de agent leest uit e-mails, documenten en webpagina's als onbetrouwbaar, omdat die instructies kan bevatten die op de agent zijn gericht.

Neemt een agent een besluit, dan vraagt iemand vroeg of laat waarom. Met een audittrail kun je dat voor elke actie beantwoorden, ook maanden later. Leg per run vast:

• De trigger en de inputdata, of een verwijzing daarnaar.
• Elke modelaanroep met de promptversie, het model-ID en de output.
• Elke toolaanroep met de argumenten, het resultaat en een tijdstempel.
• Het routeringsbesluit, de signalen voor zekerheid die eraan ten grondslag lagen en de drempel die op dat moment gold.
• Wie de actie goedkeurde, aanpaste of afwees, en met welke reden.

Sla dit gestructureerd en doorzoekbaar op. Behalve voor compliance gebruik je de audittrail om fouten te debuggen en om nieuwe cases te vinden voor je testset.

Agents krijgen te maken met input die ze niet aankunnen en systemen die plat liggen. Ontwerp expliciet wat er dan gebeurt:

1. 01Escaleer met context. Kan de agent niet beslissen, dan geeft hij de zaak aan een mens, met wat hij tot dan toe heeft gevonden. Eindeloos opnieuw proberen is geen optie.
2. 02Begrens de lus. Beperk per run het aantal stappen, toolaanroepen en de uitgaven, en escaleer als een limiet is bereikt.
3. 03Val netjes terug. Is een afhankelijke dienst niet beschikbaar, zet het werk dan in een wachtrij of val terug op het handmatige proces, en waarschuw het team.
4. 04Zorg voor een noodstop. Medewerkers moeten een agent, of één tool, kunnen pauzeren zonder nieuwe deployment.

• Elke tool is ingedeeld op risico, en voor acties buiten de scope bestaat geen tool.
• De code van de tool dwingt limieten af, met credentials met beperkte rechten.
• Onomkeerbare en externe acties vereisen goedkeuring, met bewijs op het goedkeuringsscherm.
• Zekerheid is opgebouwd uit controleerbare signalen en afgesteld op uitkomsten.
• Elke run laat een volledige, doorzoekbare audittrail achter.
• Lussen zijn begrensd, fouten escaleren met context en er is een noodstop.

We ontwerpen agents vanaf de eerste versie zo, en breiden de automatisering uit zodra de audittrail en evaluaties laten zien dat het veilig is. Onze agent die facturen goedkeurt en de case over zendingsuitzonderingen laten deze patronen in de praktijk zien, en onze aanpak beschrijft hoe we agents in productie brengen.