Cómo Funciona un Agente de IA Conversacional por Dentro

Cómo Funciona un Agente de IA Conversacional por Dentro (Arquitectura OpenClaw)

Cómo funciona un agente de IA conversacional en la práctica, turno a turno? Este post abre la caja negra de OpenClaw: desde el momento en que el mensaje del cliente llega a WhatsApp hasta el texto que el agente escribe de vuelta. Va a ser técnico. Vale la pena si vos decidís arquitectura de producto, si vas a comprar una solución y querés evaluar a fondo, o si te gusta saber qué está pasando detrás de la conversación.

TL;DR: cada turno pasa por 6 etapas — ingest, resolver contexto, seleccionar skills, decidir próxima acción, ejecutar con guard-rails, persistir memoria. Todo el ciclo corre en <2 segundos en la edge de Cloudflare, sin servidor fijo.

---

Por qué la arquitectura importa

Un agente conversacional que parece funcionar en un demo pero se quiebra en producción generalmente tiene uno de estos 4 problemas:

1. Latencia alta — el cliente espera 8 segundos para la respuesta, la conversación muere.
2. Alucinación no controlada — el agente inventa precio, horario, política.
3. Contexto perdido — el cliente vuelve después de 2 días y el agente "olvida" todo.
4. Costo descontrolado — cada conversación larga llena el prompt y pagás una fortuna en tokens.

Los 4 son decisiones de arquitectura, no limitaciones del modelo. OpenClaw fue construido para evitar los 4 — y el camino para entenderlo es mirar el ciclo de un turno.

---

El ciclo de un turno (6 etapas)

Imaginá que el cliente acaba de mandar el mensaje "quiero agendar para el sábado en la mañana". ¿Qué pasa entre el "received" y la respuesta del agente?

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

El mensaje de WhatsApp llega vía webhook de Meta directo a un Cloudflare Worker en el punto de presencia (PoP) más cercano geográficamente. En Brasil, esto significa São Paulo o Río, latencia de red < 20ms.

El worker hace tres cosas:

1. Valida la firma del webhook (HMAC contra secreto de la WABA).
2. Identifica el tenant por el número de teléfono del receptor (multi-tenant por to_number).
3. Normaliza el payload — audio se convierte en transcripción, imagen se convierte en descripción, ubicación se convierte en {lat,lng}, texto queda como está.

Al final de la etapa 1 tenés un objeto {tenant_id, conversation_id, user_message} listo para el siguiente paso.

Etapa 2 — Resolver contexto (D1 + KV, ~80ms)

El agente necesita 3 piezas de contexto antes de decidir:

• Historial reciente de la conversación (últimos N turnos relevantes).
• Memoria de largo plazo del cliente (preferencias, historial de compra, anotaciones).
• Estado del agente (persona, skills habilitadas, reglas).

Todos provienen del D1 (SQLite distribuido de Cloudflare). D1 sustituye a Postgres/Mongo tradicional — sin servidor de base de datos que mantener, acceso en pocos ms desde el worker, multi-tenant por tenant_id.

Punto clave: nosotros no cargamos la conversación entera en el prompt. El Memory Manager v2 de OpenClaw (descrito en nuestra documentación interna) selecciona solo los turnos relevantes para el turno actual (últimos N + N de alta relevancia semántica). Esto mantiene el costo de tokens predecible incluso en conversaciones de 100+ turnos.

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

Cada agente tiene un conjunto de skills disponibles — funciones que puede invocar. Ejemplos: consultar_calendario, crear_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Dado el mensaje "quiero agendar para el sábado por la mañana", el policy engine filtra:

• Skills compatibles con la intención detectada (agendamiento).
• Skills permitidas para esta fase de la conversación (no toda skill está disponible todo el tiempo).
• Skills que este tenant habilitó (calendar solo aparece si el tenant lo integró).

Al final se tiene un subconjunto pequeño de skills que se pasa al modelo — no las 50 posibles, solo las 4 que tienen sentido aquí. Esto reduce drásticamente la probabilidad de que el modelo invoque una skill incorrecta.

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

Ahora el modelo entra. OpenClaw hace una llamada única a un LLM de frontera (Anthropic Claude, OpenAI GPT, Google Gemini — configurable por tenant) con:

• System prompt = persona del agente + reglas + skills disponibles.
• History = turnos seleccionados en la etapa 2.
• User message = mensaje del turno actual.

El modelo responde una de dos cosas:

• Respuesta final (texto directo para el cliente).
• Tool call (solicitud para ejecutar una skill específica con parámetros).

En el ejemplo "quiero agendar para el sábado por la mañana", el modelo típicamente retorna:

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

Etapa 5 — Ejecución con guard-rails (variable, ~100-500ms)

La skill no corre en el modelo. Corre en código nuestro, que:

1. Valida parámetros (¿date_range tiene formato correcto? ¿está dentro de las reglas del tenant?).
2. Verifica permiso (¿ese agente tiene derecho a consultar ese calendario?).
3. Ejecuta la llamada (Google Calendar API en este caso).
4. Retorna resultado estructurado al modelo.

¿Por qué esto importa? Porque el modelo nunca fabrica el resultado. Si el calendario retorna [10h, 11h], es exactamente eso lo que va a la próxima llamada. Si la skill falla, el modelo sabe que falló. Cero riesgo de que el agente "invente" que hay horario a las 9h cuando no lo hay.

Para casos que involucran información sensible (precio, plazo, nombre del cliente), el pipeline fuerza tool call — no deja que el modelo responda desde su propio "conocimiento". Esto elimina la clase de alucinación más común en agentes comerciales.

Etapa 6 — Respuesta y persistencia (~50ms)

Con el resultado de la skill en mano, el modelo hace la segunda llamada — ahora para formar la respuesta final al cliente. Ej:

"Tengo sábado a las 10h y 11h. ¿Cuál prefiere?"

Paralelamente, el worker:

1. Envía el mensaje de vuelta por la API de WhatsApp.
2. Persiste el turno completo (user + assistant + tool calls + duración) en D1.
3. Actualiza la memoria de largo plazo si el turno produjo un hecho nuevo (ej: "cliente prefiere sábado").
4. Emite evento de observabilidad (métrica de latencia, costo de token, tasa de escalación).

Todo esto corre en paralelo. La persistencia no bloquea el envío del mensaje — el cliente no espera al D1.

---

Dónde está la defensa contra alucinación

Un agente que alucina en producción pierde confianza rápido. OpenClaw tiene 4 líneas de defensa:

1. Source-of-truth forzada. Datos factuales (precio, horario, nombre) siempre vienen de skill, nunca del modelo solo.
2. Verificación doble en datos sensibles. El agendamiento se confirma con el cliente antes de persistir. El pago se confirma antes de liberar acceso.
3. Reglas negativas explícitas. La persona de cada agente incluye "nunca invente X, Y, Z" — el modelo obedece.
4. Fallback a humano. Cuando ninguna skill cubre la pregunta, el agente dice "déjeme verificar con el equipo" y abre un ticket — no adivina.

En auditorías que hicimos en los últimos 6 meses (conversaciones reales revisadas manualmente), la tasa de alucinación factual quedó por debajo de 0.3% de los turnos — y casi todos los casos fueron por config (el tenant olvidó habilitar la skill relevante), no error del modelo.

---

El costo por conversación

Una buena arquitectura es invisible hasta que ves la factura. Dado que cada turno hace 1-2 llamadas de LLM + lookups en D1, el costo típico por conversación completa (10-15 turnos) queda en: