Cum Funcționează un Agent de IA Conversațional pe Interior

Cum Funcționează un Agent de IA Conversațional pe Dinăuntru (Arhitectura OpenClaw)

Cum funcționează un agent de IA conversațional în practică, tură cu tură? Acest articol deschide cutia neagră a OpenClaw: din momentul în care mesajul clientului ajunge pe WhatsApp până la textul pe care agentul îl scrie înapoi. Va fi tehnic. Merită dacă decizi arhitectura de produs, dacă vei cumpăra o soluție și vrei să evaluezi în profunzime, sau dacă îți place să știi ce se întâmplă în spatele conversației.

TL;DR: fiecare tură trece prin 6 etape — ingest, rezolvare context, selectare skills, decizie acțiune următoare, execuție cu guard-rails, persistare memorie. Întregul ciclu rulează în <2 secunde pe edge-ul Cloudflare, fără server fix.

---

De ce contează arhitectura

Un agent conversațional care pare să funcționeze într-un demo dar se strică în producție are de obicei una din aceste 4 probleme:

1. Latență mare — clientul așteaptă 8 secunde pentru răspuns, conversația moare.
2. Halucinație necontrolată — agentul inventează preț, orar, politică.
3. Context pierdut — clientul revine după 2 zile și agentul „uită" totul.
4. Cost necontrolat — fiecare conversație lungă umple prompt-ul și plătești o avere pe tokeni.

Toate 4 sunt alegeri de arhitectură, nu limitări ale modelului. OpenClaw a fost construit pentru a evita toate 4 — iar calea pentru a înțelege este să privești ciclul unei ture.

---

Ciclul unei ture (6 etape)

Imaginează-ți că clientul tocmai a trimis mesajul "quero marcar pra sábado de manhã". Ce se întâmplă între „received" și răspunsul agentului?

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

Mesajul de pe WhatsApp ajunge prin webhook-ul Meta direct într-un Cloudflare Worker în punctul de prezență (PoP) cel mai apropiat geografic. În Brazilia, asta înseamnă São Paulo sau Rio, latență de rețea < 20ms.

Worker-ul face trei lucruri:

1. Validează semnătura webhook-ului (HMAC contra secretului WABA).
2. Identifică tenant-ul după numărul de telefon al receptorului (multi-tenant prin to_number).
3. Normalizează payload-ul — audio devine transcriere, imagine devine descriere, localizare devine {lat,lng}, textul rămâne așa cum este.

La finalul etapei 1 ai un obiect {tenant_id, conversation_id, user_message} pregătit pentru pasul următor.

Etapa 2 — Rezolvare context (D1 + KV, ~80ms)

Agentul are nevoie de 3 piese de context înainte de a decide:

• Istoricul recent al conversației (ultimele N tururi relevante).
• Memoria pe termen lung a clientului (preferințe, istoric de achiziții, adnotări).
• Starea agentului (persona, skills activate, reguli).

Toate provin din D1 (SQLite distribuit de la Cloudflare). D1 înlocuiește Postgres/Mongo tradițional — fără server de bază de date de întreținut, acces în câțiva ms din worker, multi-tenant prin tenant_id.

Punct-cheie: noi nu încărcăm întreaga conversație în prompt. Memory Manager v2 din OpenClaw (descris în documentația noastră internă) selectează doar tururile relevante pentru turul curent (ultimele N + N cu relevanță semantică ridicată). Acest lucru menține costul de tokeni previzibil chiar și în conversații de 100+ tururi.

Etapa 3 — Selecția de skills (policy engine, ~20ms)

Fiecare agent are un set de skills disponibile — funcții pe care le poate invoca. Exemple: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Având mesajul "quero marcar pra sábado de manhã", policy engine-ul filtrează:

• Skills compatibile cu intenția detectată (programare).
• Skills permise pentru această fază a conversației (nu toate skills sunt disponibile tot timpul).
• Skills pe care acest tenant le-a activat (calendar apare doar dacă tenant-ul a integrat).

La final ai un subset mic de skills transmis modelului — nu cele 50 posibile, doar cele 4 care au sens aici. Acest lucru reduce drastic șansa ca modelul să invoce un skill greșit.

Etapa 4 — Decizia (LLM call, 400-1200ms)

Acum intră modelul. OpenClaw face un singur apel către un LLM de frontieră (Anthropic Claude, OpenAI GPT, Google Gemini — configurabil per tenant) cu:

• System prompt = persona agentului + reguli + skills disponibile.
• History = tururi selectate în etapa 2.
• User message = mesajul turului curent.

Modelul răspunde una din două lucruri:

• Răspuns final (text direct către client).
• Tool call (cerere de a executa un skill specific cu parametri).

În exemplul "quero marcar pra sábado de manhã", modelul returnează de obicei:

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

Etapa 5 — Execuție cu guard-rails (variabil, ~100-500ms)

Skill-ul nu rulează în model. El rulează într-un cod al nostru, care:

1. Validează parametrii (date_range are formatul corect? se încadrează în regulile tenant-ului?).
2. Verifică permisiunea (acest agent are dreptul să consulte acest calendar?).
3. Execută apelul (Google Calendar API în acest caz).
4. Returnează rezultatul structurat către model.

De ce contează asta? Pentru că modelul nu fabrică niciodată rezultatul. Dacă calendarul returnează [10h, 11h], exact asta ajunge la următorul apel. Dacă skill-ul eșuează, modelul știe că a eșuat. Zero risc ca agentul să „inventeze" că are loc disponibil la 9h când nu are.

Pentru cazurile care implică informații sensibile (preț, termen, numele clientului), pipeline-ul forțează tool call — nu lasă modelul să răspundă din propria „cunoaștere". Asta elimină clasa de halucinație cea mai frecventă la agenții comerciali.

Etapa 6 — Răspuns și persistență (~50ms)

Cu rezultatul skill-ului în mână, modelul face al doilea apel — acum pentru a formula răspunsul final către client. Ex:

"Am sâmbătă la 10h și 11h. Pe care o preferi?"

În paralel, worker-ul:

1. Trimite mesajul înapoi prin API-ul WhatsApp.
2. Persistă turnul complet (user + assistant + tool calls + durată) în D1.
3. Actualizează memoria pe termen lung dacă turnul a produs un fapt nou (ex: „clientul preferă sâmbăta").
4. Emite eveniment de observabilitate (metrică de latență, cost de token, rată de escaladare).

Toate acestea rulează în paralel. Persistența nu blochează trimiterea mesajului — clientul nu așteaptă D1.

---

Unde se află apărarea contra halucinației

Un agent care halucinează în producție pierde încrederea rapid. OpenClaw are 4 linii de apărare:

1. Sursă de adevăr forțată. Datele factuale (preț, orar, nume) vin întotdeauna din skill, niciodată doar de la model.
2. Verificare dublă pentru date sensibile. Programarea este confirmată cu clientul înainte de a fi persistată. Plata este confirmată înainte de a acorda acces.
3. Reguli negative explicite. Persona fiecărui agent include „nu inventa niciodată X, Y, Z" — modelul se conformează.
4. Fallback către om. Când niciun skill nu acoperă întrebarea, agentul spune "lasă-mă să verific cu echipa" și deschide un ticket — nu ghicește.

În auditurile pe care le-am făcut în ultimele 6 luni (conversații reale revizuite manual), rata de halucinație factuală a fost sub 0,3% din tururi — și aproape toate cazurile au fost din cauza configurării (tenant-ul a uitat să activeze skill-ul relevant), nu eroare a modelului.

---

Costul per conversație

Arhitectura bună este invizibilă până când te uiți la factură. Având în vedere că fiecare tură face 1-2 apeluri LLM + căutări în D1, costul tipic per conversație completă (10-15 ture) este: