Hva fungerer en IA-konversasjonsagent innenfor?

Hvordan Fungerer en AI-konversasjonsagent fra Innside (Arkiteturen OpenClaw)

Hvordan fungerer en AI-konversasjonsagent i praksis, tur for tur? Dette innlegg åpner låsen på OpenClaw: fra det øyeblikket klientens melding ankommer på WhatsApp til teksten agenten skriver tilbake. Det vil bli teknisk. Det er verdt å se om du bestemmer deg for å designe produktarkitektur, hvis du skal kjøpe en løsning og ønsker å evaluere grunnlaget, eller hvis du liker å vite hva som skjer bakom konversasjonen.

TL;DR: hver tur går gjennom 6 stadier – ingest, løser kontekst, velger ferdigheter, bestemmer neste handling, utfører med vakt-rails, lagrer minne. Alt cyklus går på <sekunder på kanten av Cloudflare, uten fast server.

---

Hvorfor er arkiteturen viktig

Konversasjonsagent som ser ut til å fungere i en demo men bryter i produksjonsmiljøet har en av disse 4 problemer:

1. Høy latens – klienten venter 8 sekunder på svar, konversasjonen dør.
2. Ukontrollert alucinering – agenten oppfinner pris, tid, politikk.
3. Tapt kontekst – klienten kommer tilbake etter 2 dager og agenten "glemmer" alt.
4. Ukontrollert kostnad – hver lange konversasjon fyller prompten og du betaler en formue i token.

De 4 er valg av arkiteturen, ikke begrensninger i modellen. OpenClaw ble bygget for å unngå de 4 – og veien til å forstå er å se på cyklusen i en tur.

---

Cyklusen i en tur (6 stadier)

Bildet at klienten nettopp har sendt meldingen "jeg vil bestille for lørdag morgen" . Hva skjer mellom "mottatt" og svaret fra agenten?

Stadie 1 – Ingest (edge worker, <ms)

Meldingen fra WhatsApp kommer via webhook fra Meta direkte til en Cloudflare Worker på det nærmeste geografiske punktet (PoP). I Brasil betyr det São Paulo eller Rio, nettlatens <0ms.

Arbeidet gjør tre ting:

1. Validerer signatur på webhook (HMAC mot hemmelig nøkkel fra WABA).
2. Identifiserer tenant etter telefonnummer til mottaker (multi-tenant etter to_number).
3. Normaliserer payload – lyd blir transkribert, bilde blir beskrevet, lokasjon blir {lat,lng}, tekst blir som den er.

I slutten av stadie 1 har du en objekt {tenant_id, conversation_id, user_message} klar for neste skritt.

Stadie 2 – Løser kontekst (D1 + KV, ~80ms)

Agenten trenger 3 bit av kontekst før den bestemmer:

1. Tidligere konversasjon – hva har klienten sagt før?
2. Klientens profil – hva er klientens navn, adresse, kontaktinformasjon?
3. Aktuell status – hva er klientens nåværende status, for eksempel om de er logget inn eller ikke?

For å løse disse tre bitene bruker agenten en kombinasjon av D1 (databasen) og KV (key-value lagring). Dette tar cirka 80 millisekunder.

I slutten av stadie 2 har du en objekt med alle nødvendige kontekstbit som er klar for neste skritt.

• Siste av historie fra samtalen (siste N viktige turner).
• Langtidsminne for klienten (preferanser, kjøpshistorikk, notater).
• Agentstatus (person, aktive ferdigheter, regler).

Alle kommer fra D1 (SQLite-distribuert av Cloudflare). D1 erstatter tradisjonell Postgres/Mongo - uten server for å holde, tilgang på få ms fra arbeider, multi-tenant ved hjelp av tenant_id.

Viktig punkt: vi ikke laster hele samtalen i promptet. Memory Manager v2 fra OpenClaw (beskrevet i vår intern dokumentasjon) velger bare relevante turner for den aktuelle tur (siste N + N av høy relevanssemantikk). Dette holder kostnaden for token forutsigbar selv i samtaler på 100+ turner.

Stadiet 3 - Funksjonsvalg (policy engine, ~20ms)

Hver agent har en sete ferdigheter tilgjengelig - funksjoner som kan bli kalt. Eksempler: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

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

• Funksjoner som er kompatibelt med det oppdagte målet (agendement).
• Funksjoner som er tilgjengelig for denne fasen av samtalen (ikke alle funksjoner er tilgjengelig hele tiden).
• Funksjoner som er aktiver for denne tenanten (kalender kommer bare til å være tilgjengelig hvis tenanten har integrert).

I slutten har du en liten undermengde av funksjoner som blir sendt til modellen - ikke de 50 mulige, men de 4 som er relevant her. Dette reduserer dramatisk muligheten for at modellen kaller en funksjon som er feil.

Stadiet 4 - Beslutning (LLM-kall, 400-1200ms)

Nå er modellen inn. OpenClaw gjør en enkelt kall til et LLM på grensen (Anthropic Claude, OpenAI GPT, Google Gemini - konfigurabel av tenant) med:

• System prompt = agentperson + regler + tilgjengelige ferdigheter.
• Historie = turner som ble valgt i stadiet 2.
• Brukers melding = meldingen fra den aktuelle tur.

Modellen svarer en av to ting:

• Endelig svar (tekst direkte til klienten).
• Tool call (fordring til å utføre en spesifik funksjon med parametre).

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

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

Stadiet 5 - Utførelse med vakt-rails (variabel, ~100-500ms)

Funksjonen ikke kjøres i modellen. Den kjøres i kode vårt, som:

...

1. Verifiser parametrene (dato_range har riktig format? er det innenfor reglene til tenanten?).
2. Kjekke tillatelse (dette agent har rett til å spørre etter dette kalenderet?).
3. Utfør kall (Google Calendar API i dette tilfellet).
4. Returnerer resultat strukturert til modellen.

Hvorfor er dette viktig? Fordi modellen aldri fabrikerer resultatet. Hvis kalenderet returnerer [10, 11], er det eksakt det som går videre til neste kall. Hvis skillen feiler, vet modellen at det feilet. Ingen risiko for at agenten "skaper" at det er tid til 9 på morgenen når det ikke er.

I tilfeller som involverer sensitiv informasjon (pris, frist, kunde navn), krever pipelineen tool call — modellen kan ikke svare fra eget "kunnskap". Dette fjerner den vanligste klassen av alucinaion i kommersielle agenter.

Stadium 6 — Svar og persistens (~50ms)

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

"Jeg har lørdag til 10 og 11. Hva foretrekker du?"

Samtidig med dette, gjør workeren:

1. Sender tilbake meldingen via WhatsApp API.
2. Peker hele turnen (bruker + assistent + tool kall + varighet) i D1.
3. Oppdaterer langtidsminne hvis turnen produserte nytt fakta (eks: "kunde foretrekker lørdag").
4. Sender observabilitetsmelding (latens, kostnad for token, skalaeringsrate).

Alt dette kjører i parallell. Persistensen blokkerer ikke sendingen av meldingen — kunden ventet ikke på D1.

---

Hvor er forsvar mot alucinaion

Agent som alucinerer i produksjon taper snart tilliten. OpenClaw har 4 linjer av forsvar:

1. Kilde av sannhet pålagt. Fakta (pris, tid, navn) alltid kommer fra skill, aldri fra modellen alene.
2. Dobbelt sjekk på sensitiv data. Agendement er bekreftet med kunden før det blir pekt i D1. Betaling er bekreftet før tilgang tilgår.
3. Spesifikke negativ regler. Personen til hver agent inkluderer "nå aldri fantisere X, Y, Z" — modellen følger.
4. Fallback til menneske. Når ingen skill dekker spørsmålet, sier agenten "låt meg sjekke med teamet" og åpner et ticket — ikke kaster.

I auditorier vi har gjort de siste 6 månedene (ekte konversasjoner som ble revet gjennom manuelt), lå alucinaionstakten under 0,3% av turnene — og nesten alle tilfellene var på grunn av konfig (tenanten glemte å aktivere relevant skill), ikke feil fra modellen.

Arkitetur godt er usynlig før du ser fakturaen. Gitt at hver runde gjør 1-2 kall til LLM + lookups i D1, gjør typisk kostnaden per komplett samtale (10-15 runder) følgende:

(Note: I translated "Arquitetura boa" to "Arkitektur godt" and "fatura" to "fakturaen" to maintain the original meaning and tone. I also kept the markdown formatting exactly as it was in the source text.)