Com Funciona un Agent d'IA Conversacional per Dins

Com Funciona un Agent d'IA Conversacional per Dins (Arquitectura OpenClaw)

Com funciona un agent d'IA conversacional a la pràctica, torn a torn? Aquest post obre la caixa negra d'OpenClaw: des del moment que el missatge del client arriba al WhatsApp fins al text que l'agent escriu de tornada. Serà tècnic. Val la pena si decideixes arquitectura de producte, si compraràs una solució i vols avaluar el fons, o si t'agrada saber què està passant darrere la conversa.

TL;DR: cada torn passa per 6 etapes — ingest, resol context, selecciona skills, decideix propera acció, executa amb guard-rails, persisteix memòria. Tot el cicle s'executa en <2 segons a l'edge de Cloudflare, sense servidor fix.

---

Per què l'arquitectura importa

Agent conversacional que sembla funcionar en una demo però es trenca en producció generalment té un d'aquests 4 problemes:

1. Latència alta — client espera 8 segons per la resposta, conversa mor.
2. Al·lucinació no controlada — agent inventa preu, horari, política.
3. Context perdut — client torna després de 2 dies i l'agent "oblida" tot.
4. Cost descontrolat — cada conversa llarga omple el prompt i pagues una fortuna en token.

Els 4 són tries d'arquitectura, no limitacions del model. L'OpenClaw va ser construït per evitar els 4 — i el camí per entendre és mirar el cicle d'un torn.

---

El cicle d'un torn (6 etapes)

Imagina que el client acaba d'enviar el missatge "vull reservar per dissabte al matí". Què passa entre el "received" i la resposta de l'agent?

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

El missatge del WhatsApp arriba via webhook de Meta directament a un Cloudflare Worker al punt de presència (PoP) més proper geogràficament. Al Brasil, això significa São Paulo o Rio, latència de xarxa < 20ms.

El worker fa tres coses:

1. Valida la signatura del webhook (HMAC contra secret de la WABA).
2. Identifica el tenant pel número de telèfon del receptor (multi-tenant per to_number).
3. Normalitza el payload — àudio es converteix en transcripció, imatge es converteix en descripció, localització es converteix en {lat,lng}, text es queda com està.

Al final de l'etapa 1 tens un objecte {tenant_id, conversation_id, user_message} preparat per al proper pas.

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

L'agent necessita 3 peces de context abans de decidir:

• Historial recent de la conversa (últims N torns rellevants).
• Memòria a llarg termini del client (preferències, historial de compra, anotacions).
• Estat de l'agent (persona, skills habilitades, regles).

Tots provenen de D1 (SQLite distribuït de Cloudflare). D1 substitueix Postgres/Mongo tradicional — sense servidor de base de dades per mantenir, accés en pocs ms des del worker, multi-tenant per tenant_id.

Punt clau: no carreguem la conversa sencera al prompt. El Memory Manager v2 d'OpenClaw (descrit a la nostra documentació interna) selecciona només els torns rellevants per al torn actual (últims N + N d'alta rellevància semàntica). Això manté el cost de token previsible fins i tot en converses de 100+ torns.

Estadi 3 — Selecció de skills (policy engine, ~20ms)

Cada agent té un conjunt de skills disponibles — funcions que pot invocar. Exemples: consultar_calendario, crear_evento, generar_enlace_pago, consultar_pedido, llamar_humano.

Donat el missatge "vull reservar per dissabte al matí", el policy engine filtra:

• Skills compatibles amb la intenció detectada (programació).
• Skills permeses per a aquesta fase de la conversa (no tota skill està disponible sempre).
• Skills que aquest tenant ha habilitat (calendar només apareix si el tenant l'ha integrat).

Al final tens un subconjunt petit de skills passat al model — no les 50 possibles, només les 4 que tenen sentit aquí. Això redueix dràsticament la probabilitat que el model invoqui una skill errònia.

Estadi 4 — Decisió (LLM call, 400-1200ms)

Ara entra el model. OpenClaw fa una crida única a un LLM de frontera (Anthropic Claude, OpenAI GPT, Google Gemini — configurable per tenant) amb:

• System prompt = persona de l'agent + regles + skills disponibles.
• History = torns seleccionats a l'estadi 2.
• User message = missatge del torn actual.

El model respon una de dues coses:

• Resposta final (text directe per al client).
• Tool call (petició per executar una skill específica amb paràmetres).

A l'exemple "vull reservar per dissabte al matí", el model típicament retorna:

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

Estadi 5 — Execució amb guard-rails (variable, ~100-500ms)

La skill no s'executa al model. S'executa en un codi nostre, que:

1. Valida paràmetres (date_range té el format correcte? està dins de les regles del tenant?).
2. Comprova permís (aquest agent té dret a consultar aquest calendari?).
3. Executa la crida (Google Calendar API en aquest cas).
4. Retorna resultat estructurat al model.

Per què això importa? Perquè el model mai fabrica el resultat. Si el calendari retorna [10h, 11h], és exactament això el que va a la propera crida. Si la skill falla, el model sap que ha fallat. Zero risc que l'agent "inventi" que hi ha horari a les 9h quan no n'hi ha.

Per a casos que impliquen informació sensible (preu, termini, nom del client), el pipeline força tool call — no deixa que el model respongui del seu propi "coneixement". Això elimina la classe d'al·lucinació més comuna en agents comercials.

Etapa 6 — Resposta i persistència (~50ms)

Amb el resultat de la skill a les mans, el model fa la segona crida — ara per formar la resposta final al client. Ex:

"Tinc dissabte a les 10h i 11h. Quin prefereixes?"

Paral·lelament, el worker:

1. Envia el missatge de tornada per l'API de WhatsApp.
2. Persisteix el torn complet (user + assistant + tool calls + durada) al D1.
3. Actualitza la memòria de llarg termini si el torn ha produït un fet nou (ex: "client prefereix dissabte").
4. Emet esdeveniment d'observabilitat (mètrica de latència, cost de token, taxa d'escalació).

Tot això s'executa en paral·lel. La persistència no bloqueja l'enviament del missatge — el client no espera el D1.

---

On està la defensa contra l'al·lucinació

Agent que al·lucina en producció perd confiança ràpidament. L'OpenClaw té 4 línies de defensa:

1. Source-of-truth forçada. Dades factuals (preu, horari, nom) sempre vénen de skill, mai del model sol.
2. Verificació doble en dades sensibles. L'agendament es confirma amb el client abans de persistir. El pagament es confirma abans d'alliberar accés.
3. Regles negatives explícites. La persona de cada agent inclou "mai inventis X, Y, Z" — el model obeeix.
4. Fallback a humà. Quan cap skill cobreix la pregunta, l'agent diu "deixa'm comprovar amb l'equip" i obre un tiquet — no endevina.

En auditories que hem fet els últims 6 mesos (converses reals revisades manualment), la taxa d'al·lucinació factual ha quedat per sota del 0,3% dels torns — i gairebé tots els casos van ser per configuració (tenant va oblidar habilitar skill rellevant), no error del model.

---

El cost per conversa

Arquitectura bona és invisible fins que mires la factura. Atès que cada torn fa 1-2 crides de LLM + lookups a D1, el cost típic per conversa completa (10-15 torns) queda en: