Cómo Funciona un Agente de IA Conversacional por Dentro
Los 6 estágios de un turno de conversa en OpenClaw — con latencia real, costo por conversa y las 4 líneas de defensa contra alucinación.
Equipe OpenClaw · Time de Engenharia & Produto
A Equipe OpenClaw é formada por engenheiros, designers e especialistas em IA dedicados a construir a melhor plataforma de agentes conversacionais para negócios brasileiros. Combinamos expertise…
Como 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 preta del OpenClaw: del 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 usted decide arquitectura de producto, si va a comprar una solución y quiere evaluar el fondo, o si curte saber lo que 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 quebra en producción generalmente tiene uno de esos 4 problemas:
- Latencia alta — cliente espera 8 segundos pra respuesta, conversa muere.
- Alucina no controlada — agente inventa precio, horario, política.
- Contexto perdido — cliente vuelve después de 2 días y agente "olvida" todo.
- Custo descontrolado — cada conversa larga enche el prompt y usted paga 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)
Imagine 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:
- Valida la firma del webhook (HMAC contra secreto de la WABA).
- Identifica el inquilino por el número de teléfono del receptor (multi-inquilino por
to_number). - 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 tiene un objeto {tenant_id, conversation_id, user_message} listo para el próximo paso.
Etapa 2 — Resuelve contexto (D1 + KV, ~80ms)
El agente necesita de 3 piezas de contexto antes de decidir:
- Estado de la conversa (D1): ¿qué pasó antes? ¿qué se dijo?
- Historial de la conversa (KV): ¿qué se dijo antes? ¿qué se respondió?
- Configuración del inquilino (KV): ¿qué configuración tiene el inquilino?
El agente busca estas piezas de contexto en la base de datos y las almacena en un objeto {conversation_state, conversation_history, tenant_config}.
Etapa 3 — Selecciona habilidades (D2 + KV, ~80ms)
El agente necesita seleccionar la habilidad adecuada para responder al mensaje del cliente. La habilidad es una función que toma el contexto de la conversa y devuelve una respuesta.
El agente busca la habilidad adecuada en la base de datos y la almacena en un objeto {skill_id, skill_params}.
Etapa 4 — Decide próxima acción (D3 + KV, ~80ms)
El agente necesita decidir qué acción realizar después de seleccionar la habilidad. La acción puede ser enviar una respuesta, realizar una tarea o llamar a una API.
El agente busca la acción adecuada en la base de datos y la almacena en un objeto {action_id, action_params}.
Etapa 5 — Ejecuta con guard-rails (D4 + KV, ~80ms)
El agente necesita ejecutar la acción seleccionada con los guard-rails adecuados. Los guard-rails son reglas que limitan la acción y evitan que se realice algo que no sea permitido.
El agente busca los guard-rails adecuados en la base de datos y los almacena en un objeto {guardrail_id, guardrail_params}.
Etapa 6 — Persiste memoria (D5 + KV, ~80ms)
El agente necesita persistir la memoria de la conversa para que se pueda acceder a ella en el futuro. La memoria es un objeto que contiene el estado de la conversa y el historial de la conversa.
El agente almacena la memoria en la base de datos y la actualiza en el objeto {conversation_state, conversation_history, tenant_config}.
Al final del ciclo de un turno, el agente ha respondido al mensaje del cliente y ha actualizado la memoria de la conversa. El ciclo se repite para cada turno de la conversa.
- 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: a gente no carga la conversación completa en el prompt. El Memory Manager v2 del 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 él puede invocar. Ejemplos: consultar_calendario, crear_evento, generar_link_pagamento, consultar_pedido, chamar_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, solo las 4 que hacen sentido aquí. Esto reduce drásticamente la posibilidad de que el modelo invoque habilidad errada.
Etapa 4 — Decisión (LLM call, 400-1200ms)
Ahora el modelo entra. El OpenClaw hace una llamada única a un LLM de frontera (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:
...
- Valida parámetros (date_range tiene formato correcto? está dentro de las reglas del tenant?).
- Checa permissão (ese agente tiene derecho de consultar ese calendario?).
- Executa la llamada (Google Calendar API en ese caso).
- 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.
Estadio 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:
- Envía la mensaje de vuelta por la API de WhatsApp.
- Persiste el turno completo (user + asistente + llamadas de herramienta + duración) en D1.
- Actualiza la memoria de largo plazo si el turno produjo hecho nuevo (ex: "cliente prefiere sábado").
- Emite evento de observabilidad (métrica de latencia, costo de token, taxa de escalación).
Todo esto roda en paralelo. La persistencia no bloquea el envío de la mensaje — cliente no espera a D1.
Donde está la defensa contra alucinación
Agente que alucina en producción pierde confianza rápido. El OpenClaw tiene 4 líneas de defensa:
- Fuente de verdad forzada. Datos factuales (precio, horario, nombre) siempre vienen de skill, nunca del modelo solo.
- Verificación dupla en datos sensibles. Agendamiento es confirmado con el cliente antes de persistir. Pago es confirmado antes de liberar acceso.
- Regras negativas explícitas. Persona de cada agente incluye "nunca invente X, Y, Z" — el modelo obedece.
- Fallback para humano. Cuando ninguna skill cubre la pregunta, el agente dice
"deja que cheque 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
La buena arquitectura es invisible hasta que uno mira la factura. Dado que cada turno hace 1-2 llamadas de LLM + consultas en D1, el costo típico por conversación completa (10-15 turnos) queda en:
Nota: No se traducirán URLs, código o etiquetas HTML.
Equipe OpenClaw
Publicado el 31 de mayo de 2026
