Miten keskusteleva tekoälyagentti toimii sisältä

Miten tekoälykeskusteluagentti toimii sisältä päin (OpenClaw-arkkitehtuuri)

Miten tekoälykeskusteluagentti toimii käytännössä, vuoro vuorolta? Tämä kirjoitus avaa OpenClaw'n mustan laatikon: siitä hetkestä kun asiakkaan viesti saapuu WhatsAppiin siihen tekstiin asti, jonka agentti kirjoittaa takaisin. Tämä on teknistä. Se kannattaa lukea, jos päätät tuotearkkitehtuurista, jos aiot ostaa ratkaisun ja haluat arvioida sen perusteellisesti, tai jos sinua kiinnostaa tietää mitä keskustelun takana tapahtuu.

TL;DR: jokainen vuoro kulkee 6 vaiheen läpi — vastaanotto, kontekstin selvitys, taitojen valinta, seuraavan toiminnon päätös, suoritus suojakaiteilla, muistin tallennus. Koko sykli pyörii <2 sekunnissa Cloudflaren edge-verkossa, ilman kiinteää palvelinta.

---

Miksi arkkitehtuurilla on väliä

Keskusteluagentti, joka näyttää toimivan demossa mutta hajoaa tuotannossa, kärsii yleensä yhdestä näistä 4 ongelmasta:

1. Korkea latenssi — asiakas odottaa 8 sekuntia vastausta, keskustelu kuolee.
2. Hallitsematon hallusinaatio — agentti keksii hinnan, aikataulun, käytännön.
3. Kadonnut konteksti — asiakas palaa 2 päivän jälkeen ja agentti "unohtaa" kaiken.
4. Hallitsemattomat kustannukset — jokainen pitkä keskustelu täyttää promptin ja maksat omaisuuden tokeneista.

Kaikki 4 ovat arkkitehtuurivalintoja, eivät mallin rajoituksia. OpenClaw rakennettiin välttämään kaikki 4 — ja tapa ymmärtää se on tarkastella yhden vuoron sykliä.

---

Yhden vuoron sykli (6 vaihetta)

Kuvittele, että asiakas on juuri lähettänyt viestin "quero marcar pra sábado de manhã". Mitä tapahtuu "vastaanotettu"-tilan ja agentin vastauksen välillä?

Vaihe 1 — Vastaanotto (edge worker, <50ms)

WhatsApp-viesti saapuu Metan webhookin kautta suoraan Cloudflare Workerille maantieteellisesti lähimpään läsnäolopisteeseen (PoP). Brasiliassa tämä tarkoittaa São Pauloa tai Riota, verkkolatenssi < 20ms.

Worker tekee kolme asiaa:

1. Validoi webhookin allekirjoituksen (HMAC WABA-salaisuutta vasten).
2. Tunnistaa tenantin vastaanottajan puhelinnumeron perusteella (multi-tenant to_number-kentän mukaan).
3. Normalisoi payloadin — ääni muuttuu transkriptioksi, kuva kuvaukseksi, sijainti muuttuu {lat,lng}-muotoon, teksti pysyy ennallaan.

Vaiheen 1 lopussa sinulla on objekti {tenant_id, conversation_id, user_message} valmiina seuraavaan vaiheeseen.

Vaihe 2 — Kontekstin selvitys (D1 + KV, ~80ms)

Agentti tarvitsee 3 kontekstipalaa ennen päätöksentekoa:

• Viimeaikainen historia keskustelusta (viimeiset N relevanttia vuoroa).
• Pitkäaikainen muisti asiakkaasta (mieltymykset, ostohistoria, muistiinpanot).
• Agentin tila (persoona, käytössä olevat skillit, säännöt).

Kaikki tulevat D1:stä (Cloudflaren hajautettu SQLite). D1 korvaa perinteisen Postgres/Mongon — ei tietokantapalvelinta ylläpidettäväksi, pääsy muutamassa millisekunnissa workerilta, multi-tenant tenant_id:llä.

Avainasia: me emme lataa koko keskustelua promptiin. OpenClaw'n Memory Manager v2 (kuvattu sisäisessä dokumentaatiossamme) valitsee vain nykyiselle vuorolle relevantit vuorot (viimeiset N + N semanttisesti erittäin relevanttia). Tämä pitää token-kustannuksen ennustettavana jopa yli 100 vuoron keskusteluissa.

Vaihe 3 — Skillien valinta (policy engine, ~20ms)

Jokaisella agentilla on joukko käytettävissä olevia skillejä — funktioita, joita se voi kutsua. Esimerkkejä: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Viestillä "quero marcar pra sábado de manhã" policy engine suodattaa:

• Skillit, jotka ovat yhteensopivia tunnistetun intention kanssa (ajanvaraus).
• Skillit, jotka ovat sallittuja tässä keskustelun vaiheessa (kaikki skillit eivät ole käytettävissä koko ajan).
• Skillit, jotka tämä tenant on ottanut käyttöön (kalenteri näkyy vain, jos tenant on integroinut sen).

Lopulta sinulla on pieni osajoukko skillejä, joka välitetään mallille — ei kaikkia 50 mahdollista, vaan vain ne 4, jotka ovat tässä järkeviä. Tämä vähentää dramaattisesti riskiä, että malli kutsuu väärää skilliä.

Vaihe 4 — Päätös (LLM-kutsu, 400-1200ms)

Nyt malli astuu kuvaan. OpenClaw tekee yhden kutsun eturivin LLM:lle (Anthropic Claude, OpenAI GPT, Google Gemini — konfiguroitavissa tenanttikohtaisesti) seuraavilla:

• System prompt = agentin persoona + säännöt + käytettävissä olevat skillit.
• History = vaiheessa 2 valitut vuorot.
• User message = nykyisen vuoron viesti.

Malli vastaa kahdella tavalla:

• Lopullinen vastaus (suora teksti asiakkaalle).
• Tool call (pyyntö suorittaa tietty skilli parametreilla).

Esimerkissä "quero marcar pra sábado de manhã" malli tyypillisesti palauttaa:

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

Vaihe 5 — Suoritus suojakaiteilla (vaihteleva, ~100-500ms)

Skilli ei suorita mallissa. Se suoritetaan meidän koodissamme, joka:

1. Validoi parametrit (onko date_range oikeassa muodossa? onko se tenantin sääntöjen mukainen?).
2. Tarkistaa oikeudet (onko tällä agentilla oikeus hakea tätä kalenteria?).
3. Suorittaa kutsun (Google Calendar API tässä tapauksessa).
4. Palauttaa jäsennellyn tuloksen mallille.

Miksi tällä on merkitystä? Koska malli ei koskaan keksi tulosta. Jos kalenteri palauttaa [10h, 11h], juuri se menee seuraavaan kutsuun. Jos skill epäonnistuu, malli tietää sen epäonnistuneen. Nollariski sille, että agentti "keksisi" ajan klo 9, kun sellaista ei ole.

Tapauksissa, joissa käsitellään arkaluonteista tietoa (hinta, toimitusaika, asiakkaan nimi), pipeline pakottaa tool call -kutsun — se ei anna mallin vastata omasta "tietämyksestään". Tämä eliminoi hallusinaatioiden yleisin luokan kaupallisissa agenteissa.

Vaihe 6 — Vastaus ja persistointi (~50ms)

Kun skillin tulos on käytettävissä, malli tekee toisen kutsun — nyt muodostaakseen lopullisen vastauksen asiakkaalle. Esim:

"Lauantaina on vapaana klo 10 ja 11. Kumman valitset?"

Samanaikaisesti worker:

1. Lähettää viestin takaisin WhatsApp API:n kautta.
2. Persistoi täydellisen vuoron (user + assistant + tool calls + kesto) D1:een.
3. Päivittää pitkäkestoisen muistin, jos vuoro tuotti uuden faktan (esim: "asiakas suosii lauantaita").
4. Lähettää havainnointitapahtuman (latenssi­metriikka, token-kustannus, eskalaatioaste).

Kaikki tämä tapahtuu rinnakkain. Persistointi ei estä viestin lähettämistä — asiakas ei odota D1:tä.

---

Missä on puolustus hallusinaatioita vastaan

Agentti, joka hallusinoi tuotannossa, menettää luottamuksen nopeasti. OpenClaw:ssa on 4 puolustuslinjaa:

1. Pakotettu totuuden lähde. Faktatiedot (hinta, aika, nimi) tulevat aina skillistä, eivät koskaan mallilta yksinään.
2. Kaksinkertainen varmistus arkaluonteisille tiedoille. Ajanvaraus vahvistetaan asiakkaalta ennen persistointia. Maksu vahvistetaan ennen pääsyn myöntämistä.
3. Eksplisiittiset kieltosäännöt. Jokaisen agentin persoona sisältää "älä koskaan keksi X, Y, Z" — malli noudattaa.
4. Fallback ihmiselle. Kun mikään skill ei kata kysymystä, agentti sanoo "annan tiimin tarkistaa asian" ja avaa tiketin — ei arvaa.

Viimeisten 6 kuukauden aikana tekemissämme auditoinneissa (manuaalisesti tarkistetut todelliset keskustelut) faktuaalisten hallusinaatioiden osuus jäi alle 0,3 % vuoroista — ja lähes kaikki tapaukset johtuivat konfiguraatiosta (tenant unohti ottaa käyttöön relevantin skillin), eivät mallin virheestä.

---

Kustannus per keskustelu

Hyvä arkkitehtuuri on näkymätöntä, kunnes katsot laskua. Koska jokainen vuoro tekee 1-2 LLM-kutsua + D1-hakuja, tyypillinen kustannus per kokonainen keskustelu (10-15 vuoroa) on: