Kako Funkcionira Konverzacijski AI Agent Iznutra

Kako Funkcionira Konverzacijski AI Agent Iznutra (OpenClaw Arhitektura)

Kako funkcionira konverzacijski AI agent u praksi, od poteza do poteza? Ovaj post otvara crnu kutiju OpenClaw-a: od trenutka kada poruka klijenta stigne na WhatsApp do teksta koji agent piše natrag. Bit će tehnički. Vrijedi ako odlučujete o arhitekturi proizvoda, ako namjeravate kupiti rješenje i želite procijeniti pozadinu, ili ako volite znati što se događa iza razgovora.

TL;DR: svaki potez prolazi kroz 6 faza — ingest, razrješavanje konteksta, odabir vještina, odluka o sljedećoj akciji, izvršavanje sa zaštitnim ogradama, trajno spremanje memorije. Cijeli ciklus se izvršava u <2 sekunde na Cloudflare edge-u, bez fiksnog poslužitelja.

---

Zašto je arhitektura važna

Konverzacijski agent koji izgleda da funkcionira u demu ali se ruši u produkciji obično ima jedan od ova 4 problema:

1. Visoka latencija — klijent čeka 8 sekundi za odgovor, razgovor umire.
2. Nekontrolirane halucinacije — agent izmišlja cijenu, radno vrijeme, politiku.
3. Izgubljeni kontekst — klijent se vraća nakon 2 dana i agent "zaboravlja" sve.
4. Nekontrolirani troškovi — svaki dugi razgovor puni prompt i plaćate bogatstvo u tokenima.

Sva 4 su arhitektonski izbori, ne ograničenja modela. OpenClaw je izgrađen kako bi izbjegao sva 4 — a put do razumijevanja je pogledati ciklus jednog poteza.

---

Ciklus jednog poteza (6 faza)

Zamislite da je klijent upravo poslao poruku "želim zakazati za subotu ujutro". Što se događa između "received" i odgovora agenta?

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

WhatsApp poruka stiže putem Meta webhoka direktno u Cloudflare Worker na najbližoj geografskoj točki prisutnosti (PoP). U Brazilu to znači São Paulo ili Rio, latencija mreže < 20ms.

Worker radi tri stvari:

1. Validira potpis webhoka (HMAC protiv WABA tajne).
2. Identificira tenant po telefonskom broju primatelja (multi-tenant po to_number).
3. Normalizira payload — audio postaje transkripcija, slika postaje opis, lokacija postaje {lat,lng}, tekst ostaje kakav jest.

Na kraju faze 1 imate objekt {tenant_id, conversation_id, user_message} spreman za sljedeći korak.

Faza 2 — Razrješavanje konteksta (D1 + KV, ~80ms)

Agent treba 3 dijela konteksta prije nego donese odluku:

• Nedavna povijest razgovora (posljednjih N relevantnih izmjena).
• Dugoročna memorija klijenta (preferencije, povijest kupnje, bilješke).
• Stanje agenta (persona, omogućene vještine, pravila).

Sve dolazi iz D1 (Cloudflare-ovog distribuiranog SQLite-a). D1 zamjenjuje tradicionalni Postgres/Mongo — nema poslužitelja baze podataka za održavanje, pristup u nekoliko ms iz workera, multi-tenant putem tenant_id.

Ključna točka: ne učitavamo cijeli razgovor u prompt. Memory Manager v2 iz OpenClaw-a (opisan u našoj internoj dokumentaciji) odabire samo relevantne izmjene za trenutnu izmjenu (posljednjih N + N visoke semantičke relevantnosti). To održava trošak tokena predvidljivim čak i u razgovorima s 100+ izmjena.

Faza 3 — Odabir vještina (policy engine, ~20ms)

Svaki agent ima skup dostupnih vještina — funkcija koje može pozvati. Primjeri: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

S obzirom na poruku "quero marcar pra sábado de manhã", policy engine filtrira:

• Vještine kompatibilne s otkrivenom namjerom (zakazivanje).
• Vještine dopuštene za ovu fazu razgovora (nisu sve vještine dostupne cijelo vrijeme).
• Vještine koje je ovaj tenant omogućio (calendar se pojavljuje samo ako je tenant integrirao).

Na kraju imate mali podskup vještina proslijeđen modelu — ne svih 50 mogućih, samo 4 koje ovdje imaju smisla. To drastično smanjuje vjerojatnost da model pozove pogrešnu vještinu.

Faza 4 — Odluka (LLM poziv, 400-1200ms)

Sada ulazi model. OpenClaw izvršava jedan poziv LLM-u na granici (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurabilan po tenantu) s:

• System prompt = persona agenta + pravila + dostupne vještine.
• History = izmjene odabrane u fazi 2.
• User message = poruka trenutne izmjene.

Model odgovara jednom od dvije stvari:

• Konačni odgovor (tekst izravno klijentu).
• Tool call (zahtjev za izvršavanje specifične vještine s parametrima).

U primjeru "quero marcar pra sábado de manhã", model obično vraća:

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

Faza 5 — Izvršavanje s guard-rails (varijabilno, ~100-500ms)

Vještina ne radi u modelu. Radi u našem kodu, koji:

1. Validira parametre (ima li date_range ispravan format? je li unutar pravila tenanta?).
2. Provjerava dozvolu (ima li ovaj agent pravo pristupiti ovom kalendaru?).
3. Izvršava poziv (Google Calendar API u ovom slučaju).
4. Vraća strukturirani rezultat modelu.

Zašto je to važno? Jer model nikada ne izmišlja rezultat. Ako kalendar vrati [10h, 11h], to je točno ono što ide u sljedeći poziv. Ako skill ne uspije, model zna da nije uspio. Nula rizika da agent "izmisli" da ima termin u 9h kada ga nema.

Za slučajeve koji uključuju osjetljive informacije (cijena, rok, ime klijenta), pipeline forsira tool call — ne dopušta modelu da odgovara iz vlastitog "znanja". To eliminira klasu halucinacija najčešću kod komercijalnih agenata.

Faza 6 — Odgovor i perzistencija (~50ms)

S rezultatom skilla u rukama, model izvršava drugi poziv — sada za formiranje konačnog odgovora klijentu. Npr:

"Imam subotu u 10h i 11h. Što preferirate?"

Paralelno, worker:

1. Šalje poruku natrag putem WhatsApp API-ja.
2. Perzistira kompletan turn (user + assistant + tool calls + trajanje) u D1.
3. Ažurira dugoročnu memoriju ako je turn proizveo novu činjenicu (npr: "klijent preferira subotu").
4. Emitira event za observability (metrika latencije, trošak tokena, stopa eskalacije).

Sve to radi paralelno. Perzistencija ne blokira slanje poruke — klijent ne čeka D1.

---

Gdje je obrana protiv halucinacija

Agent koji halucinira u produkciji brzo gubi povjerenje. OpenClaw ima 4 linije obrane:

1. Forsirani source-of-truth. Činjenični podaci (cijena, termin, ime) uvijek dolaze iz skilla, nikada samo iz modela.
2. Dvostruka provjera osjetljivih podataka. Zakazivanje se potvrđuje s klijentom prije perzistiranja. Plaćanje se potvrđuje prije odobravanja pristupa.
3. Eksplicitna negativna pravila. Persona svakog agenta uključuje "nikada ne izmišljaj X, Y, Z" — model se pokorava.
4. Fallback na čovjeka. Kada nijedno skill ne pokriva pitanje, agent kaže "dopustite da provjerim s timom" i otvara ticket — ne pogađa.

U auditima koje smo proveli u posljednjih 6 mjeseci (stvarni razgovori ručno pregledani), stopa činjeničnih halucinacija bila je ispod 0,3% turnova — i gotovo svi slučajevi bili su zbog konfiguracije (tenant je zaboravio omogućiti relevantni skill), a ne greške modela.

---

Trošak po razgovoru

Dobra arhitektura je nevidljiva dok ne pogledate račun. S obzirom da svaki potez čini 1-2 poziva LLM-a + pretraživanja u D1, tipični trošak po cijelom razgovoru (10-15 poteza) iznosi: