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 decidís arquitectura de producto, si vas a comprar una solución y querés evaluar el 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, selecciona skills, decide próxima acción, ejecuta con guard-rails, persiste memoria. Todo el ciclo corre en <2 segundos en el edge de Cloudflare, sin servidor fijo.

---

Por qué la arquitectura importa

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

1. Latencia alta — cliente espera 8 segundos para la respuesta, la conversación muere.
2. Alucinación no controlada — agente inventa precio, horario, política.
3. Contexto perdido — 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 elecciones de arquitectura, no limitaciones del modelo. OpenClaw fue construido para evitar los 4 — y el camino para entender es mirar el ciclo de un turno.

---

El ciclo de un turno (6 etapas)

Imaginá que el cliente acaba de mandar el mensaje "quiero reservar para el sábado a 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 San Pablo o Río, latencia de red < 20ms.

El worker hace tres cosas:

1. Valida la firma del webhook (HMAC contra secreto de 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 próximo 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 vienen de D1 (SQLite distribuido de Cloudflare). D1 reemplaza Postgres/Mongo tradicional — sin servidor de base de datos para 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 (descripto 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 token 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, generar_link_pago, consultar_pedido, llamar_humano.

Dado el mensaje "quiero agendar para el sábado a 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 integró).

Al final tenés un subconjunto pequeño de skills pasado al modelo — no las 50 posibles, solo las 4 que tienen sentido acá. Esto reduce drásticamente la chance de que el modelo invoque la skill equivocada.

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

Ahora entra el modelo. 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 (pedido para ejecutar una skill específica con parámetros).

En el ejemplo "quiero agendar para el sábado a 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 un código nuestro, que:

1. Valida parámetros (¿date_range tiene formato correcto? ¿está dentro de las reglas del tenant?).
2. Chequea permiso (¿este agente tiene derecho de consultar este 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 preferís?"

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 escalamiento).

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

---

Dónde está la defensa contra alucinación

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. Agendamiento es confirmado con el cliente antes de persistir. Pago es confirmado antes de liberar acceso.
3. Reglas negativas explícitas. Persona de cada agente incluye "nunca inventes X, Y, Z" — el modelo obedece.
4. Fallback a humano. Cuando ninguna skill cubre la pregunta, el agente dice "dejame chequear con el equipo" y abre un ticket — no tira fruta.

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

---

El costo por conversación

La arquitectura buena es invisible hasta que mirás 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: