Kako funkcioniše konverzacioni AI agent iznutra

Kako funkcioniše konverzacijski AI agent iznutra (OpenClaw arhitektura)

Kako funkcioniše 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 nazad. Biće tehnički. Vredi ako donosite odluke o arhitekturi proizvoda, ako kupujete rešenje i želite da procenite dubinu, ili ako volite da znate šta se dešava iza razgovora.

TL;DR: svaki potez prolazi kroz 6 faza — ingest, razrešavanje konteksta, selekcija veština, odluka o sledećoj akciji, izvršavanje sa zaštitnim ogradama, čuvanje memorije. Ceo ciklus se izvršava za <2 sekunde na Cloudflare edge-u, bez fiksnog servera.

---

Zašto je arhitektura važna

Konverzacijski agent koji izgleda da funkcioniše u demo verziji ali se lomi u produkciji obično ima jedan od ova 4 problema:

1. Visoka latencija — klijent čeka 8 sekundi na odgovor, razgovor umire.
2. Nekontrolisana halucinacija — agent izmišlja cenu, radno vreme, politiku.
3. Izgubljen kontekst — klijent se vraća posle 2 dana i agent "zaboravlja" sve.
4. Nekontrolisani troškovi — svaki dugi razgovor puni prompt i plaćate bogatstvo u tokenima.

Sva 4 su izbori arhitekture, a ne ograničenja modela. OpenClaw je izgrađen da izbegne sva 4 — a put do razumevanja je da se pogleda ciklus jednog poteza.

---

Ciklus jednog poteza (6 faza)

Zamislite da je klijent upravo poslao poruku "želim da zakažem za subotu ujutru". Šta se dešava između "received" i odgovora agenta?

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

Poruka sa WhatsApp-a stiže preko Meta webhook-a direktno u Cloudflare Worker na najbližoj geografskoj tački prisustva (PoP). U Brazilu, to znači São Paulo ili Rio, latencija mreže < 20ms.

Worker radi tri stvari:

1. Validira potpis webhook-a (HMAC protiv WABA tajne).
2. Identifikuje tenant po broju telefona primaoca (multi-tenant po to_number).
3. Normalizuje payload — audio postaje transkripcija, slika postaje opis, lokacija postaje {lat,lng}, tekst ostaje kakav jeste.

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

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

Agent treba 3 dela konteksta pre nego što odluči:

• Недавна историја разговора (последњих N релевантних размена).
• Дугорочна меморија клијента (преференције, историја куповине, белешке).
• Стање агента (персона, омогућене вештине, правила).

Све долази из D1 (Cloudflare-ов дистрибуирани SQLite). D1 замењује традиционални Postgres/Mongo — без сервера базе података за одржавање, приступ за неколико ms из worker-а, multi-tenant преко tenant_id.

Кључна тачка: не учитавамо цео разговор у prompt. Memory Manager v2 из OpenClaw-а (описан у нашој интерној документацији) бира само релевантне размене за тренутну размену (последњих N + N са високом семантичком релевантношћу). Ово одржава трошак токена предвидивим чак и у разговорима са 100+ размена.

Фаза 3 — Избор вештина (policy engine, ~20ms)

Сваки агент има скуп доступних вештина — функција које може позвати. Примери: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

За поруку "quero marcar pra sábado de manhã", policy engine филтрира:

• Вештине компатибилне са откривеном намером (заказивање).
• Вештине дозвољене за ову фазу разговора (нису све вештине доступне све време).
• Вештине које је овај tenant омогућио (calendar се појављује само ако је tenant интегрисао).

На kraju имате мали подскуп вештина прослеђен моделу — не свих 50 могућих, само 4 које имају смисла овде. Ово драстично смањује шансу да модел позове погрешну вештину.

Фаза 4 — Одлука (LLM позив, 400-1200ms)

Сада улази модел. OpenClaw прави један позив frontier LLM-у (Anthropic Claude, OpenAI GPT, Google Gemini — подесиво по tenant-у) са:

• System prompt = персона агента + правила + доступне вештине.
• History = размене изабране у фази 2.
• User message = порука тренутне размене.

Модел одговара једном од две ствари:

• Коначан одговор (директан текст за клијента).
• Tool call (захтев за извршавање специфичне вештине са параметрима).

У примеру "quero marcar pra sábado de manhã", модел типично враћа:

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

Фаза 5 — Извршавање са guard-rails (варијабилно, ~100-500ms)

Вештина не ради у моделу. Она ради у нашем коду, који:

1. Validira parametre (da li date_range ima ispravan format? da li je u skladu sa pravilima zakupca?).
2. Proverava dozvolu (da li ovaj agent ima pravo da konsultuje ovaj kalendar?).
3. Izvršava poziv (Google Calendar API u ovom slučaju).
4. Vraća strukturiran rezultat modelu.

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

Za slučajeve koji uključuju osetljive informacije (cena, rok, ime klijenta), pipeline forsira tool call — ne dozvoljava modelu da odgovori iz sopstvenog "znanja". Ovo eliminiše klasu halucinacija najčešću kod komercijalnih agenata.

Faza 6 — Odgovor i perzistencija (~50ms)

Sa rezultatom skill-a pri ruci, model pravi drugi poziv — sada da formira konačan odgovor za klijenta. Npr:

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

Paralelno, worker:

1. Šalje poruku nazad preko 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. Emituje događaj posmatračnosti (metrika latencije, troškova tokena, stope eskalacije).

Sve ovo se izvršava paralelno. Perzistencija ne blokira slanje poruke — klijent ne čeka D1.

---

Gde je odbrana protiv halucinacija

Agent koji halucinira u produkciji brzo gubi poverenje. OpenClaw ima 4 linije odbrane:

1. Prinudni izvor istine. Faktički podaci (cena, vreme, ime) uvek dolaze iz skill-a, nikada samo iz modela.
2. Dupla provera osetljivih podataka. Zakazivanje se potvrđuje sa klijentom pre perzistiranja. Plaćanje se potvrđuje pre odobravanja pristupa.
3. Eksplicitna negativna pravila. Persona svakog agenta uključuje "nikada ne izmišljaj X, Y, Z" — model se pokorava.
4. Fallback na čoveka. Kada nijedan skill ne pokriva pitanje, agent kaže "dozvolite da proverim sa timom" i otvara tiket — ne pogađa.

U revizijama koje smo sproveli u poslednjih 6 meseci (stvarni razgovori ručno pregledani), stopa faktičkih halucinacija ostala je ispod 0,3% turnova — i skoro svi slučajevi bili su zbog konfiguracije (zakupac je zaboravio da omogući relevantan skill), a ne greške modela.

---

Trošak po razgovoru

Добра архитектура је невидљива док не погледате рачун. С обзиром да сваки потез прави 1-2 позива LLM-а + претраге у D1, типичан трошак по комплетној конверзацији (10-15 потеза) износи: