Hvordan en AI-samtaleagent fungerer innvendig

Hvordan en AI-samtaleagent fungerer innvendig (OpenClaw-arkitektur)

Hvordan fungerer en AI-samtaleagent i praksis, tur for tur? Dette innlegget åpner den svarte boksen til OpenClaw: fra øyeblikket kundens melding ankommer på WhatsApp til teksten agenten skriver tilbake. Det blir teknisk. Det er verdt det hvis du bestemmer produktarkitektur, hvis du skal kjøpe en løsning og vil evaluere det underliggende, eller hvis du liker å vite hva som skjer bak samtalen.

TL;DR: hver tur går gjennom 6 stadier — ingest, løs kontekst, velg ferdigheter, bestem neste handling, utfør med guard-rails, lagre minne. Hele syklusen kjører på <2 sekunder på Cloudflares edge, uten fast server.

---

Hvorfor arkitekturen er viktig

Samtaleagenter som ser ut til å fungere i en demo, men bryter sammen i produksjon, har vanligvis ett av disse 4 problemene:

1. Høy latens — kunden venter 8 sekunder på svar, samtalen dør.
2. Ukontrollert hallusinasjon — agenten finner opp pris, tidspunkt, retningslinjer.
3. Tapt kontekst — kunden kommer tilbake etter 2 dager og agenten "glemmer" alt.
4. Ukontrollerte kostnader — hver lang samtale fyller opp prompten og du betaler en formue i tokens.

Alle 4 er arkitekturvalg, ikke begrensninger i modellen. OpenClaw ble bygget for å unngå alle 4 — og veien til å forstå det er å se på syklusen til en tur.

---

Syklusen til en tur (6 stadier)

Tenk deg at kunden nettopp sendte meldingen "quero marcar pra sábado de manhã". Hva skjer mellom "received" og agentens svar?

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

Meldingen fra WhatsApp ankommer via Metas webhook direkte til en Cloudflare Worker på det geografisk nærmeste tilstedeværelsespunktet (PoP). I Brasil betyr dette São Paulo eller Rio, nettverkslatens < 20ms.

Workeren gjør tre ting:

1. Validerer signaturen til webhooken (HMAC mot WABA-hemmeligheten).
2. Identifiserer tenanten via mottakerens telefonnummer (multi-tenant via to_number).
3. Normaliserer payloaden — lyd blir transkripsjon, bilde blir beskrivelse, lokasjon blir {lat,lng}, tekst forblir som den er.

Ved slutten av stadium 1 har du et objekt {tenant_id, conversation_id, user_message} klart for neste steg.

Stadium 2 — Løs kontekst (D1 + KV, ~80ms)

Agenten trenger 3 kontekstdeler før den kan bestemme seg:

• Nylig historikk fra samtalen (siste N relevante turer).
• Langtidsminne for kunden (preferanser, kjøpshistorikk, notater).
• Agentstatus (persona, aktiverte skills, regler).

Alt kommer fra D1 (Cloudflares distribuerte SQLite). D1 erstatter tradisjonell Postgres/Mongo — ingen databaseserver å vedlikeholde, tilgang på få ms fra workeren, multi-tenant via tenant_id.

Nøkkelpunkt: vi laster ikke hele samtalen inn i prompten. Memory Manager v2 fra OpenClaw (beskrevet i vår interne dokumentasjon) velger kun de relevante turene for gjeldende tur (siste N + N med høy semantisk relevans). Dette holder tokenkostnaden forutsigbar selv i samtaler med 100+ turer.

Steg 3 — Valg av skills (policy engine, ~20ms)

Hver agent har et sett med tilgjengelige skills — funksjoner den kan kalle. Eksempler: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Gitt meldingen "quero marcar pra sábado de manhã", filtrerer policy engine:

• Skills som er kompatible med den oppdagede intensjonen (timebestilling).
• Skills som er tillatt for denne fasen av samtalen (ikke alle skills er tilgjengelige hele tiden).
• Skills som denne tenanten har aktivert (kalender vises bare hvis tenanten har integrert den).

Til slutt har du et lite undersett av skills som sendes til modellen — ikke alle 50 mulige, bare de 4 som gir mening her. Dette reduserer drastisk sjansen for at modellen kaller feil skill.

Steg 4 — Beslutning (LLM-kall, 400-1200ms)

Nå kommer modellen inn. OpenClaw gjør ett enkelt kall til en frontier-LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurerbart per tenant) med:

• System prompt = agentens persona + regler + tilgjengelige skills.
• History = turer valgt i steg 2.
• User message = meldingen fra gjeldende tur.

Modellen svarer med én av to ting:

• Endelig svar (tekst direkte til kunden).
• Tool call (forespørsel om å utføre en spesifikk skill med parametere).

I eksempelet "quero marcar pra sábado de manhã" returnerer modellen typisk:

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

Steg 5 — Utførelse med guard-rails (variabel, ~100-500ms)

Skillen kjører ikke i modellen. Den kjører i vår egen kode, som:

1. Validerer parametere (har date_range riktig format? er det innenfor tenantens regler?).
2. Sjekker tillatelse (har denne agenten rett til å slå opp i denne kalenderen?).
3. Utfører kallet (Google Calendar API i dette tilfellet).
4. Returnerer strukturert resultat til modellen.

Hvorfor er dette viktig? Fordi modellen aldri fabrikkerer resultatet. Hvis kalenderen returnerer [10h, 11h], er det nøyaktig det som sendes til neste kall. Hvis skillen feiler, vet modellen at den feilet. Null risiko for at agenten "finner opp" at det er en tid klokken 9 når det ikke er det.

For tilfeller som involverer sensitiv informasjon (pris, frist, kundenavn), tvinger pipelinen tool call — den lar ikke modellen svare fra sin egen "kunnskap". Dette eliminerer den vanligste klassen av hallusinasjon i kommersielle agenter.

Steg 6 — Respons og persistering (~50ms)

Med resultatet fra skillen i hånden gjør modellen det andre kallet — nå for å forme det endelige svaret til kunden. F.eks.:

"Jeg har lørdag klokken 10 og 11. Hvilken foretrekker du?"

Parallelt gjør workeren:

1. Sender meldingen tilbake via WhatsApp API.
2. Persisterer den komplette turen (user + assistant + tool calls + varighet) i D1.
3. Oppdaterer langtidsminnet hvis turen produserte et nytt faktum (f.eks.: "kunden foretrekker lørdag").
4. Sender observabilitetshendelse (latensmetrikk, tokenkostnad, eskalasjonsrate).

Alt dette kjører parallelt. Persisteringen blokkerer ikke sendingen av meldingen — kunden venter ikke på D1.

---

Hvor forsvaret mot hallusinasjon ligger

En agent som hallusinerer i produksjon mister tillit raskt. OpenClaw har 4 forsvarslinjer:

1. Tvungen sannhetskilde. Faktuelle data (pris, tidspunkt, navn) kommer alltid fra en skill, aldri fra modellen alene.
2. Dobbel verifisering av sensitive data. Timebestilling bekreftes med kunden før persistering. Betaling bekreftes før tilgang gis.
3. Eksplisitte negative regler. Personaen til hver agent inkluderer "aldri finn opp X, Y, Z" — modellen adlyder.
4. Fallback til menneske. Når ingen skill dekker spørsmålet, sier agenten "la meg sjekke med teamet" og oppretter en sak — den gjetter ikke.

I revisjoner vi har gjort de siste 6 månedene (ekte samtaler gjennomgått manuelt), lå den faktuelle hallusinasjonsraten under 0,3 % av turene — og nesten alle tilfellene skyldtes konfigurasjon (tenanten glemte å aktivere relevant skill), ikke modellfeil.

---

Kostnaden per samtale

God arkitektur er usynlig helt til du ser på fakturaen. Gitt at hver runde gjør 1-2 LLM-kall + oppslag i D1, ligger den typiske kostnaden per fullstendig samtale (10-15 runder) på: