Hur en konversationsdriven AI-agent fungerar inifrån

Hur en konversationsbaserad AI-agent fungerar inifrån (OpenClaw-arkitektur)

Hur fungerar en konversationsbaserad AI-agent i praktiken, tur för tur? Det här inlägget öppnar den svarta lådan i OpenClaw: från det ögonblick kundens meddelande anländer på WhatsApp till texten som agenten skriver tillbaka. Det kommer att vara tekniskt. Det är värt det om du fattar beslut om produktarkitektur, om du ska köpa en lösning och vill utvärdera grunden, eller om du gillar att veta vad som händer bakom konversationen.

TL;DR: varje tur passerar genom 6 steg — ingest, lös kontext, välj skills, besluta nästa åtgärd, exekvera med guard-rails, persistera minne. Hela cykeln körs på <2 sekunder på Cloudflares edge, utan fast server.

---

Varför arkitekturen spelar roll

En konversationsagent som verkar fungera i en demo men går sönder i produktion har vanligtvis ett av dessa 4 problem:

1. Hög latens — kunden väntar 8 sekunder på svar, konversationen dör.
2. Okontrollerad hallucination — agenten hittar på pris, tider, policyer.
3. Förlorad kontext — kunden kommer tillbaka efter 2 dagar och agenten "glömmer" allt.
4. Okontrollerad kostnad — varje lång konversation fyller prompten och du betalar en förmögenhet i tokens.

Alla 4 är arkitekturval, inte begränsningar i modellen. OpenClaw byggdes för att undvika alla 4 — och vägen till förståelse är att titta på cykeln för en tur.

---

Cykeln för en tur (6 steg)

Tänk dig att kunden precis skickade meddelandet "quero marcar pra sábado de manhã". Vad händer mellan "received" och agentens svar?

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

Meddelandet från WhatsApp anländer via Metas webhook direkt till en Cloudflare Worker på den geografiskt närmaste närvaropunkten (PoP). I Brasilien innebär det São Paulo eller Rio, nätverkslatens < 20ms.

Workern gör tre saker:

1. Validerar signaturen för webhooken (HMAC mot WABA-hemligheten).
2. Identifierar tenanten via mottagarens telefonnummer (multi-tenant via to_number).
3. Normaliserar payloaden — ljud blir transkription, bild blir beskrivning, plats blir {lat,lng}, text förblir som den är.

I slutet av steg 1 har du ett objekt {tenant_id, conversation_id, user_message} redo för nästa steg.

Steg 2 — Lös kontext (D1 + KV, ~80ms)

Agenten behöver 3 kontextdelar innan den beslutar:

• Senaste historik från konversationen (senaste N relevanta turerna).
• Långtidsminne för kunden (preferenser, köphistorik, anteckningar).
• Agentens tillstånd (persona, aktiverade skills, regler).

Allt kommer från D1 (Cloudflares distribuerade SQLite). D1 ersätter traditionell Postgres/Mongo — ingen databasserver att underhålla, åtkomst på några ms från workern, multi-tenant via tenant_id.

Nyckelpunkt: vi laddar inte hela konversationen i prompten. OpenClaws Memory Manager v2 (beskriven i vår interna dokumentation) väljer bara de turer som är relevanta för den aktuella turen (senaste N + N med hög semantisk relevans). Detta håller tokenkostnaden förutsägbar även i konversationer med 100+ turer.

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

Varje agent har en uppsättning tillgängliga skills — funktioner som den kan anropa. Exempel: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Givet meddelandet "quero marcar pra sábado de manhã", filtrerar policy engine:

• Skills som är kompatibla med den detekterade avsikten (bokning).
• Skills som är tillåtna för denna fas av konversationen (inte alla skills är tillgängliga hela tiden).
• Skills som denna tenant har aktiverat (kalender visas bara om tenanten har integrerat den).

I slutändan har du en liten delmängd av skills som skickas till modellen — inte de 50 möjliga, bara de 4 som är relevanta här. Detta minskar drastiskt risken att modellen anropar fel skill.

Steg 4 — Beslut (LLM-anrop, 400-1200ms)

Nu kommer modellen in. OpenClaw gör ett enda anrop till en frontier-LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurerbart per tenant) med:

• System prompt = agentens persona + regler + tillgängliga skills.
• History = turer valda i steg 2.
• User message = meddelandet från den aktuella turen.

Modellen svarar med en av två saker:

• Slutgiltigt svar (text direkt till kunden).
• Tool call (begäran om att köra en specifik skill med parametrar).

I exemplet "quero marcar pra sábado de manhã" returnerar modellen typiskt:

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

Steg 5 — Exekvering med guard-rails (variabel, ~100-500ms)

Skillen körs inte i modellen. Den körs i vår egen kod, som:

1. Validerar parametrar (har date_range korrekt format? ligger det inom tenantens regler?).
2. Kontrollerar behörighet (har denna agent rätt att söka i denna kalender?).
3. Utför anropet (Google Calendar API i detta fall).
4. Returnerar strukturerat resultat till modellen.

Varför spelar detta roll? Eftersom modellen aldrig fabricerar resultatet. Om kalendern returnerar [10h, 11h] är det exakt det som skickas till nästa anrop. Om skillen misslyckas vet modellen att den misslyckades. Noll risk att agenten "hittar på" att det finns en tid kl. 9 när det inte gör det.

För fall som involverar känslig information (pris, leveranstid, kundnamn) tvingar pipelinen tool call — den låter inte modellen svara utifrån sin egen "kunskap". Detta eliminerar den klass av hallucination som är vanligast hos kommersiella agenter.

Steg 6 — Svar och persistens (~50ms)

Med skillens resultat i hand gör modellen det andra anropet — nu för att formulera det slutgiltiga svaret till kunden. Exempel:

"Jag har lördag kl. 10 och 11. Vilken föredrar du?"

Parallellt gör workern:

1. Skickar meddelandet tillbaka via WhatsApp API.
2. Persisterar den kompletta turen (user + assistant + tool calls + varaktighet) i D1.
3. Uppdaterar långtidsminnet om turen producerade ett nytt faktum (t.ex.: "kunden föredrar lördag").
4. Emitterar observabilitetsevent (latensmått, tokenkostnad, eskaleringsfrekvens).

Allt detta körs parallellt. Persistensen blockerar inte sändningen av meddelandet — kunden väntar inte på D1.

---

Var finns försvaret mot hallucination

En agent som hallucinerar i produktion förlorar förtroende snabbt. OpenClaw har 4 försvarslinjer:

1. Påtvingad source-of-truth. Faktadata (pris, tid, namn) kommer alltid från en skill, aldrig från modellen ensam.
2. Dubbel verifiering av känslig data. Bokning bekräftas med kunden innan den persisteras. Betalning bekräftas innan åtkomst ges.
3. Explicita negativa regler. Varje agents persona inkluderar "hitta aldrig på X, Y, Z" — modellen lyder.
4. Fallback till människa. När ingen skill täcker frågan säger agenten "låt mig kolla med teamet" och öppnar ett ärende — den gissar inte.

I granskningar vi gjort de senaste 6 månaderna (verkliga konversationer manuellt genomgångna) låg den faktamässiga hallucinationsfrekvensen under 0,3% av turerna — och nästan alla fall berodde på konfiguration (tenanten glömde att aktivera relevant skill), inte modellfel.

---

Kostnaden per konversation

Bra arkitektur är osynlig tills du tittar på fakturan. Givet att varje tur gör 1-2 LLM-anrop + uppslagningar i D1, hamnar den typiska kostnaden per komplett konversation (10-15 turer) på: