Hoe een Conversational 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 voor beurt? Dit bericht opent de zwarte doos van OpenClaw: vanaf het moment dat het bericht van de klant binnenkomt op WhatsApp tot de tekst die de agent terugschrijft. Het wordt technisch. Het is de moeite waard als je beslissingen neemt over productarchitectuur, als je een oplossing gaat kopen en de kern wilt beoordelen, 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 bepalen, uitvoeren met guard-rails, geheugen opslaan. De volledige cyclus draait in <2 seconden op de edge van Cloudflare, zonder vaste server.

---

Waarom de architectuur ertoe doet

Een conversationele agent die lijkt te werken in een demo maar kapotgaat 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 prijzen, tijden, beleid.
3. Verloren context — klant komt na 2 dagen terug en de agent "vergeet" alles.
4. Ongecontroleerde kosten — elk lang gesprek vult de prompt en je betaalt een fortuin aan tokens.

Alle 4 zijn architectuurkeuzes, geen beperkingen van het model. OpenClaw is gebouwd om alle 4 te vermijden — en de manier om dat te begrijpen is door de cyclus van een beurt te bekijken.

---

De cyclus van een beurt (6 fasen)

Stel je voor dat de klant zojuist 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 de webhook van Meta rechtstreeks binnen op 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 het WABA-geheim).
2. Identificeert de tenant aan de hand van het telefoonnummer van de ontvanger (multi-tenant op basis van 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 een beslissing neemt:

• 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.

Kernpunt: we laden niet het volledige gesprek in de prompt. De Memory Manager v2 van OpenClaw (beschreven in onze interne documentatie) selecteert alleen de relevante beurten voor de huidige beurt (laatste N + N met hoge semantische relevantie). Dit houdt de tokenkosten voorspelbaar, zelfs bij 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 zijn toegestaan voor deze fase van het gesprek (niet elke skill is altijd beschikbaar).
• Skills die deze tenant heeft ingeschakeld (calendar verschijnt alleen als de tenant het heeft geïntegreerd).

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

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

Nu komt het model in actie. OpenClaw doet een 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 een van twee dingen:

• Definitief antwoord (tekst rechtstreeks naar 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 eigen 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 aan het model.

Waarom is dit belangrijk? Omdat het model nooit het resultaat verzint. Als de agenda [10h, 11h] 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 een tijdslot om 9u is terwijl dat er niet is.

Voor gevallen met gevoelige informatie (prijs, levertijd, klantnaam) forceert de pipeline een tool call — het model mag niet antwoorden vanuit eigen "kennis". Dit elimineert de meest voorkomende klasse van hallucinatie bij commerciële agents.

Fase 6 — Antwoord en persistentie (~50ms)

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

"Ik heb zaterdag om 10u en 11u. Welke heeft uw voorkeur?"

Tegelijkertijd 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. Werkt het langetermijngeheugen bij als de beurt een nieuw feit opleverde (bijv.: "klant heeft voorkeur voor zaterdag").
4. Zendt een observability-event uit (latentiemetric, tokenkosten, escalatieratio).

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

---

Waar zit de verdediging tegen hallucinatie

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

1. Geforceerde source-of-truth. Feitelijke gegevens (prijs, tijdstip, naam) komen altijd van een skill, nooit van het model alleen.
2. Dubbele verificatie bij gevoelige gegevens. Een afspraak wordt bevestigd met de klant voordat deze wordt opgeslagen. Een betaling wordt bevestigd voordat toegang wordt verleend.
3. Expliciete negatieve regels. De persona van elke agent bevat "verzin nooit X, Y, Z" — het model gehoorzaamt.
4. Fallback naar een 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 beoordeeld), bleef het percentage feitelijke hallucinatie onder 0,3% van de beurten — en bijna alle gevallen kwamen door configuratie (tenant vergat een relevante skill in te schakelen), niet door een modelfout.

---

De kosten per gesprek

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