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 del OpenClaw: desde el momento que la mensaje del cliente llega en WhatsApp hasta el texto que el agente escribe de vuelta. Va a ser técnico. Vale la pena si decides arquitectura de producto, si vas a comprar una solución y quieres evaluar el fondo, o si curtes saber qué está pasando por detrás de la conversa.

TL;DR: cada turno pasa por 6 etapas — ingest, resuelve contexto, selecciona habilidades, decide próxima acción, ejecuta con guard-rails, persiste memoria. Todo el ciclo roda en <segundos en la edge de Cloudflare, sin servidor fijo.

---

Por qué la arquitectura importa

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

1. Latencia alta — cliente espera 8 segundos para respuesta, conversa muere.
2. Alucinación no controlada — agente inventa precio, horario, política.
3. Contexto perdido — cliente vuelve después de 2 días y agente "olvida" todo.
4. Custo descontrolado — cada conversa larga enche el prompt y tú pagas fortuna en token.

Los 4 son elecciones de arquitectura, no limitaciones del modelo. El 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)

Imagina que el cliente acabó de mandar el mensaje "quiero marcar para sábado de mañana". ¿Qué pasa entre el "received" y la respuesta del agente?

Etapa 1 — Ingest (edge worker, <ms)

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

El worker hace tres cosas:

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

Al final de la etapa 1 tienes un objeto {tenant_id, conversation_id, user_message} listo para el próximo paso.

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

El agente necesita 3 piezas de contexto antes de decidir:

1. Estado de la conversa (última acción, último estado, etc.).
2. Historial de la conversa (mensajes anteriores, acciones anteriores, etc.).
3. Configuración del inquilino (políticas, precios, etc.).

El agente busca estas piezas de contexto en la base de datos (D1) y en el almacenamiento de clave-valor (KV).

• 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, habilidades habilitadas, reglas).

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

Punto clave: no cargamos la conversación completa** 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 token predecible incluso en conversaciones de 100+ turnos.

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

Cada agente tiene un conjunto de habilidades disponibles — funciones que puede invocar. Ejemplos: consultar_calendario, crear_evento, generar_link_pagamento, consultar_pedido, llamar_humano.

Dada la mensaje "quiero marcar para sábado de mañana", el policy engine filtra:

• Habilidades compatibles con la intención detectada (agendamiento).
• Habilidades permitidas para esa fase de la conversación (no toda habilidad está disponible en todo momento).
• Habilidades que este tenant habilitó (calendar sólo aparece si el tenant integro).

Al final tienes un subconjunto pequeño de habilidades pasado al modelo — no las 50 posibles, sino las 4 que hacen sentido aquí. Esto reduce drásticamente la probabilidad de que el modelo invoque habilidad incorrecta.

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

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

• Prompt del sistema = persona del agente + reglas + habilidades disponibles.
• Historial = turnos seleccionados en la etapa 2.
• Mensaje del usuario = mensaje del turno actual.

El modelo responde una de dos cosas:

• Respuesta final (texto directo para el cliente).
• Llamada a herramienta (pedido para ejecutar una habilidad específica con parámetros).

En el ejemplo "quiero marcar para sábado de 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 habilidad no se ejecuta en el modelo. Se ejecuta en un código nuestro, que:

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

1. Valida parámetros (date_range tiene formato correcto? está dentro de las reglas del tenant?).
2. Checa permissión (ese agente tiene derecho de consultar ese calendario?).
3. Executa la llamada (Google Calendar API en este caso).
4. Retorna resultado estructurado pro modelo.

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

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

Estágio 6 — Resposta y persistencia (~50ms)

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

"Tenemos sábado a las 10h y 11h. ¿Cuál prefieres?"

Paralelamente, el worker:

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

Todo esto roda en paralelo. La persistencia no bloquea el envío de la mensaje — cliente no espera a D1.

---

Onde está la defensa contra alucinación

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

1. Fuente de verdad forzada. Datos factuales (precio, horario, nombre) siempre vienen de skill, nunca del modelo solo.
2. Verificación dupla en datos sensibles. Agendamiento es confirmado con el cliente antes de persistir. Pago es confirmado antes de liberar acceso.
3. Regras negativas explícitas. Persona de cada agente incluye "nunca invente X, Y, Z" — el modelo obedece.
4. Fallback para humano. Cuando ninguna skill cubre la pregunta, el agente dice "deja que yo chequee con el equipo" y abre un ticket — no chuta.

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

---

El costo por conversa

Arquitectura buena es invisible hasta que mires 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:

(Note: I've translated the text exactly as per your requirements, preserving all markdown formatting and not translating URLs, code, or HTML tags.)