Hoe een Conversationele AI-Agent van Binnen Werkt

Hoe een Conversationele AI-Agent van Binnen Werkt (OpenClaw Architectuur)

Hoe werkt een conversationele AI-agent in de praktijk, beurt na beurt? Deze post opent de zwarte doos van OpenClaw: van het moment dat het bericht van de klant op WhatsApp aankomt tot de tekst die de agent terugschrijft. Het wordt technisch. Het is de moeite waard als je productarchitectuur bepaalt, als je een oplossing gaat kopen en de diepgang wilt evalueren, of als je graag wilt weten wat er achter het gesprek gebeurt.

TL;DR: elke beurt doorloopt 6 fasen — ingest, context oplossen, skills selecteren, volgende actie beslissen, uitvoeren met guard-rails, geheugen persisteren. De hele cyclus draait in <2 seconden op de edge van Cloudflare, zonder vaste server.

---

Waarom de architectuur belangrijk is

Conversationele agent die lijkt te werken in een demo maar crasht in productie heeft meestal een van deze 4 problemen:

1. Hoge latentie — klant wacht 8 seconden op antwoord, gesprek sterft.
2. Ongecontroleerde hallucinatie — agent verzint prijs, tijdstip, beleid.
3. Verloren context — klant komt terug na 2 dagen en agent "vergeet" alles.
4. Ongecontroleerde kosten — elk lang gesprek vult de prompt en je betaalt een fortuin aan tokens.

De 4 zijn architectuurkeuzes, geen modelbeperkingen. OpenClaw werd gebouwd om de 4 te vermijden — en de manier om het te begrijpen is door naar de cyclus van een beurt te kijken.

---

De cyclus van een beurt (6 fasen)

Stel je voor dat de klant net het bericht "ik wil een afspraak maken voor zaterdagochtend" heeft gestuurd. Wat gebeurt er tussen de "received" en het antwoord van de agent?

Fase 1 — Ingest (edge worker, <50ms)

Het WhatsApp-bericht komt via webhook van Meta rechtstreeks aan bij een Cloudflare Worker op het geografisch dichtstbijzijnde point of presence (PoP). In Brazilië betekent dit São Paulo of Rio, netwerklatentie < 20ms.

De worker doet drie dingen:

1. Valideert de handtekening van de webhook (HMAC tegen WABA-geheim).
2. Identificeert de tenant aan de hand van het telefoonnummer van de ontvanger (multi-tenant per to_number).
3. Normaliseert de payload — audio wordt transcriptie, afbeelding wordt beschrijving, locatie wordt {lat,lng}, tekst blijft zoals het is.

Aan het einde van fase 1 heb je een object {tenant_id, conversation_id, user_message} klaar voor de volgende stap.

Fase 2 — Context oplossen (D1 + KV, ~80ms)

De agent heeft 3 stukken context nodig voordat hij beslist:

• Recente geschiedenis van het gesprek (laatste N relevante beurten).
• Langetermijngeheugen van de klant (voorkeuren, aankoopgeschiedenis, notities).
• Status van de agent (persona, ingeschakelde skills, regels).

Alles komt uit D1 (gedistribueerde SQLite van Cloudflare). D1 vervangt traditionele Postgres/Mongo — geen databaseserver om te onderhouden, toegang in enkele ms vanuit de worker, multi-tenant via tenant_id.

Belangrijk punt: we laden niet het volledige gesprek in de prompt. De Memory Manager v2 van OpenClaw (beschreven in onze interne documentatie) selecteert alleen de beurten die relevant zijn voor de huidige beurt (laatste N + N met hoge semantische relevantie). Dit houdt de tokenkosten voorspelbaar, zelfs in gesprekken van 100+ beurten.

Fase 3 — Selectie van skills (policy engine, ~20ms)

Elke agent heeft een set beschikbare skills — functies die hij kan aanroepen. Voorbeelden: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Gegeven het bericht "quero marcar pra sábado de manhã", filtert de policy engine:

• Skills die compatibel zijn met de gedetecteerde intentie (planning).
• Skills die toegestaan zijn voor deze fase van het gesprek (niet elke skill is altijd beschikbaar).
• Skills die deze tenant heeft ingeschakeld (calendar verschijnt alleen als de tenant geïntegreerd heeft).

Uiteindelijk heb je een kleine subset van skills die aan het model worden doorgegeven — niet de 50 mogelijke, maar alleen de 4 die hier zinvol zijn. Dit vermindert drastisch de kans dat het model de verkeerde skill aanroept.

Fase 4 — Beslissing (LLM call, 400-1200ms)

Nu komt het model in actie. OpenClaw maakt één enkele aanroep naar een frontier LLM (Anthropic Claude, OpenAI GPT, Google Gemini — configureerbaar per tenant) met:

• System prompt = persona van de agent + regels + beschikbare skills.
• History = geselecteerde beurten in fase 2.
• User message = bericht van de huidige beurt.

Het model antwoordt met één van twee dingen:

• Definitief antwoord (directe tekst voor de klant).
• Tool call (verzoek om een specifieke skill uit te voeren met parameters).

In het voorbeeld "quero marcar pra sábado de manhã", retourneert het model doorgaans:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

Fase 5 — Uitvoering met guard-rails (variabel, ~100-500ms)

De skill draait niet in het model. Hij draait in onze code, die:

1. Valideert parameters (heeft date_range het juiste formaat? valt het binnen de regels van de tenant?).
2. Controleert toestemming (heeft deze agent het recht om deze agenda te raadplegen?).
3. Voert de aanroep uit (Google Calendar API in dit geval).
4. Retourneert gestructureerd resultaat naar het model.

Waarom is dit belangrijk? Omdat het model nooit het resultaat verzint. Als de agenda [10u, 11u] retourneert, is dat precies wat naar de volgende aanroep gaat. Als de skill faalt, weet het model dat het gefaald heeft. Nul risico dat de agent "verzint" dat er om 9u een tijdstip is wanneer dat niet zo is.

Voor gevallen die gevoelige informatie betreffen (prijs, deadline, naam van de klant), dwingt de pipeline tool call af — het laat het model niet antwoorden vanuit zijn eigen "kennis". Dit elimineert de klasse van hallucinatie die het meest voorkomt bij commerciële agenten.

Fase 6 — Antwoord en persistentie (~50ms)

Met het resultaat van de skill in handen, doet het model de tweede aanroep — nu om het definitieve antwoord voor de klant te vormen. Bijv.:

"Ik heb zaterdag om 10u en 11u. Welke geeft u de voorkeur?"

Parallel daaraan doet de worker:

1. Verstuurt het bericht terug via de WhatsApp API.
2. Persisteert de volledige beurt (user + assistant + tool calls + duur) in D1.
3. Actualiseert het langetermijngeheugen als de beurt een nieuw feit heeft opgeleverd (bijv.: "klant geeft voorkeur aan zaterdag").
4. Zendt observeerbaarheidsevent uit (latentiemetriek, tokenkosten, escalatiepercentage).

Dit alles draait parallel. De persistentie blokkeert niet het verzenden van het bericht — de klant wacht niet op D1.

---

Waar de verdediging tegen hallucinatie zit

Een agent die hallucineert in productie verliest snel vertrouwen. OpenClaw heeft 4 verdedigingslinies:

1. Afgedwongen source-of-truth. Feitelijke gegevens (prijs, tijdstip, naam) komen altijd van een skill, nooit van het model alleen.
2. Dubbele verificatie bij gevoelige gegevens. Afspraak wordt bevestigd met de klant voordat deze wordt gepersisteerd. Betaling wordt bevestigd voordat toegang wordt vrijgegeven.
3. Expliciete negatieve regels. Persona van elke agent bevat "verzin nooit X, Y, Z" — het model gehoorzaamt.
4. Fallback naar mens. Wanneer geen enkele skill de vraag dekt, zegt de agent "laat me even checken met het team" en opent een ticket — gokt niet.

In audits die we de afgelopen 6 maanden hebben uitgevoerd (echte gesprekken handmatig herzien), lag het percentage feitelijke hallucinaties onder 0,3% van de beurten — en bijna alle gevallen waren door configuratie (tenant vergat relevante skill in te schakelen), niet door een fout van het model.

---

De kosten per gesprek

Goede architectuur is onzichtbaar totdat je de factuur bekijkt. Aangezien elke beurt 1-2 LLM-aanroepen + opzoekingen in D1 maakt, blijven de typische kosten per volledig gesprek (10-15 beurten) op: