Hoe werkt een IA conversational agent van binnen

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

Hoe werkt een conversatie-AI agent in de praktijk, stap voor stap? Dit artikel opent de doos van Pandora van OpenClaw: van het moment dat de bericht van de klant arriveert in WhatsApp tot het tekst dat de agent terug schrijft. Het zal technisch zijn. Het is de moeite waard als je productarchitectuur ontwerpt, als je een oplossing wilt kopen en wilt evalueren of als je graag wilt weten wat erachter de conversatie gebeurt.

TL;DR: elke stap gaat door 6 fasen — ingest, context oplossen, vaardigheden selecteren, volgende actie bepalen, uitvoeren met rails, geheugen opslaan. Het hele proces draait in <seconden op de rand van Cloudflare, zonder vaste server.

---

Waarom de architectuur belangrijk is

Een conversatie-AI agent die lijkt te werken in een demo maar in productie breekt, heeft een van de volgende 4 problemen:

1. Hoge latentie — de klant wacht 8 seconden op een antwoord, de conversatie sterft.
2. Ongecontroleerde hallucinatie — de agent maakt prijzen, tijden en beleid op.
3. Verloren context — de klant keert terug na 2 dagen en de agent "verget" alles.
4. Ongecontroleerde kosten — elke lange conversie vult de prompt en je betaalt een fortuin in tokens.

De 4 zijn keuzes voor de architectuur, niet beperkingen van het model. OpenClaw is gebouwd om de 4 te vermijden — en de weg om dit te begrijpen is door het cycli van een stap te kijken.

---

Het cycli van een stap (6 fasen)

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

Fase 1 — Ingest (edge worker, <ms)

Het bericht van WhatsApp arriveert via een webhook van Meta rechtstreeks in een Cloudflare Worker op de meest nabije locatie geografisch. In Brazilië betekent dit São Paulo of Rio, netwerklatentie <0ms.

De worker doet drie dingen:

1. Valideert de handtekening van de webhook (HMAC tegen het geheim van de WABA).
2. Identificeert de tenant op basis van het telefoonnummer van de ontvanger (multi-tenant op to_number).
3. Normaliseert de payload — audio wordt transcriptie, afbeelding wordt beschrijving, locatie wordt {lat,lng}, tekst blijft zoals hij 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 kan beslissen:

1. Geheugen van de conversatie (D1)
2. Klantgegevens (KV)
3. Conversatiegegevens (KV)

De agent gebruikt deze context om de volgende stap te bepalen.

• Recente gespreksverloop (laatste N relevante gespreksrondes).
• Langdurige gespreksgeheugen van de klant (voorkeuren, aankoopgeschiedenis, notities).
• Agentenstatus (persoonlijkheid, ingeschakelde vaardigheden, regels).

Alles komt uit D1 (Cloudflare's gedistribueerd SQLite). D1 vervangt traditionele Postgres/Mongo - zonder server om te onderhouden, toegang in enkele milliseconden vanuit de worker, multi-tenant via tenant_id.

Klasse-actie: we laden de gespreksverloop niet helemaal in de prompt. De Memory Manager v2 van OpenClaw (beschreven in onze interne documentatie) selecteert alleen de relevante gespreksrondes voor de huidige ronde (laatste N + N van hoge semantische relevantie). Dit houdt de tokenkosten voorspelbaar, zelfs bij gesprekken van 100+ ronden.

Fase 3 - Vaardigheidselectie (beleidengine, ~20ms)

Elke agent heeft een set vaardigheden beschikbaar - functies die hij kan aanroepen. Voorbeelden: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Gegeven de boodschap "quero marcar pra sábado de manhã", de beleidengine filtert:

• Vaardigheden die compatibel zijn met de gedetecteerde intentie (agendement).
• Vaardigheden die toegestaan zijn voor deze gespreksfase (niet elke vaardigheid is beschikbaar op elk moment).
• Vaardigheden die door deze tenant zijn ingeschakeld (kalender verschijnt alleen als de tenant heeft geïntegreerd).

Uiteindelijk hebt u een kleine subset van vaardigheden die naar het model worden gestuurd - niet de 50 mogelijke, maar de 4 die hier relevant zijn. Dit vermindert de kans dat het model een verkeerde vaardigheid aanroept.

Fase 4 - Beslissing (LLM-aanroep, 400-1200ms)

Nu is het model aan de beurt. OpenClaw maakt een enkele aanroep naar een LLM van de top (Anthropic Claude, OpenAI GPT, Google Gemini - configuurbaar door de tenant) met:

• Systeemprompt = agentenpersoonlijkheid + regels + beschikbare vaardigheden.
• Gespreksverloop = geselecteerde ronden in fase 2.
• Gebruikersboodschap = huidige rondeboodschap.

Het model geeft één van twee dingen:

• Eindantwoord (tekst rechtstreeks naar de klant).
• Tool-aanroep (verzoek om een specifieke vaardigheid uit te voeren met parameters).

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

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

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

De vaardigheid roeit niet in het model. Hij rolt in ons code, die:

...

1. Valideer parameters (is de datum_range in orde? past in de regels van de tenant?).
2. Controleer toestemming (heeft dit agent het recht om dit kalender te raadplegen?).
3. Voer de aanroep uit (Google Calendar API in dit geval).
4. Terugkoppelen van resultaat in structuur naar het model.

Waarom is dit belangrijk? Omdat het model nooit het resultaat vervaardigt. Als de kalender teruggeeft [10h, 11h], is dat precies wat naar de volgende aanroep gaat. Als de skill faalt, weet het model dat het gefaald is. Geen risico dat het agent "invente" dat het een afspraak heeft om 9 uur als het geen afspraak heeft.

In gevallen die gevoelige informatie betreffen (prijs, termijn, naam van de klant), dwingt de pipeline tool call - laat het model niet antwoorden op basis van eigen "kennis". Dit vermindert de meest voorkomende klasse van hallucinatie bij commerciële agents.

Fase 6 - Antwoord en persistatie (~50ms)

Met het resultaat van de skill in handen, voert het model de tweede aanroep uit - nu om de finale antwoord voor de klant te vormen. Ex:

"Ik heb zaterdag om 10 uur en 11 uur. Wat prefereert u?"

Parallel daarmee:

1. Verstuur de bericht terug via de WhatsApp API.
2. Bewaar de volledige ronde (gebruiker + assistent + tool calls + duur) in D1.
3. Updatet de lange-termijn geheugen als de ronde een nieuw feit produceerde (ex: "klant prefereert zaterdag").
4. Emit een observabiliteitsevenement (latenstijd, tokenkosten, schaalingspercentage).

Alles loopt in parallel. De persistatie blokkeert niet de verzending van het bericht - de klant wacht niet op D1.

---

Waar is de verdediging tegen hallucinatie

Een agent die hallucineert in productie verliest snel vertrouwen. OpenClaw heeft 4 lijnen van verdediging:

1. Forced source-of-truth. Feitelijke gegevens (prijs, tijd, naam) komen altijd van de skill, nooit van het model alleen.
2. Dubbele verificatie in gevoelige gegevens. Agendement is bevestigd met de klant voordat het wordt opgeslagen. Betaling is bevestigd voordat toegang wordt vrijgegeven.
3. Expliciete negatieve regels. Persoon van elk agent bevat "nooit iets X, Y, Z" - het model gehoorzaamt.
4. Fallback naar mens. Als geen skill de vraag dekt, zegt de agent "laat me even controleren met het team" en opent een ticket - geen schot.

In audits die we de afgelopen 6 maanden hebben uitgevoerd (echte gesprekken die handmatig zijn gecontroleerd), lag de frequentie van hallucinatie op feitelijke gegevens onder 0,3% van de ronden - en bijna alle gevallen waren door configuratie (tenant vergeten om relevante skill te activeren), niet door fout van het model.

Een goede architectuur is pas zichtbaar als je de rekening bekijkt. Aangezien elke ronde 1-2 oproepen aan LLM + lookups in D1 maakt, blijft het gemiddelde kosten per gesprek (10-15 ronden) als volgt:

(Translation note: I've kept the original markdown formatting exactly as it was, without adding any extra characters or modifying the original content. I've also left the URLs, code, and HTML tags as they were in the original text.)