Arquitectura de Asistente de IA: LLM, Memoria, Herramientas, Enrutamiento, Observabilidad

Un asistente de IA en producción no es “un LLM con un prompt”. Es un sistema que acepta la intención del usuario, mantiene el estado, decide cuándo recuperar información o actuar, y expone suficiente detalle en tiempo de ejecución para depurar fallos.

Esta visión a nivel de sistema es lo que explora el clúster de Sistemas de IA cuando los asistentes trascienden una simple invocación de modelo.

OpenAI describe a los agentes como aplicaciones que planifican, llaman a herramientas, colaboran y mantienen suficiente estado para trabajos de múltiples pasos, mientras que Anthropic enmarca el mismo problema como un entorno gestionado que puede ejecutar archivos, comandos, acceso web y código de forma segura.

La arquitectura más limpia divide las responsabilidades en cinco capas: LLM, Memoria, Herramientas, Enrutamiento y Observabilidad. Esta división coincide con las capacidades expuestas por las APIs principales de los proveedores, por MCP, por entornos de ejecución autoalojados como vLLM y llama.cpp, y por sistemas de asistencia reales como OpenClaw y Hermes.

La memoria debe tratarse como algo más que “contexto más largo”. Los sistemas de recuperación transforman el conocimiento externo en memoria no paramétrica explícita, el mismo espacio de diseño cubierto en profundidad por Generación Aumentada con Recuperación (RAG) — y tanto la guía de contexto de Anthropic como el paper “Lost in the Middle” advierten que simplemente meter más tokens en el contexto no garantiza una recuperación fiable.

El uso de herramientas es un límite de contrato, no magia. Las llamadas a funciones de OpenAI, el uso de herramientas de Anthropic y MCP dependen del mismo patrón: el modelo emite una solicitud estructurada, algún entorno de ejecución la ejecuta y el resultado fluye de vuelta a la conversación. Si ese límite es laxo, el asistente se vuelve laxo.

Mi sesgo es simple: empieza por lo básico. Un orquestador, un camino de memoria durable, un trazo por solicitud y una política explícita para la ejecución de herramientas. Los gráficos multi-agente son útiles, pero solo después de que puedas explicar los casos de fallo de tu agente único sin adivinar.

Qué es un sistema de asistente de IA

Una definición práctica es esta: un sistema de asistente de IA es un entorno de ejecución que transforma la intención del usuario en una respuesta o acción combinando una interfaz de modelo, ensamblaje de contexto, ejecución de herramientas, gestión de estado y telemetría. Por eso los documentos útiles no son solo fichas de modelo. Los documentos útiles son referencias de API, contratos de herramientas, guías de recuperación, documentos de enrutamiento y documentos de trazabilidad. La API de Respuestas de OpenAI expone interacciones con estado, herramientas integradas y llamadas a funciones. La API de Claude de Anthropic expone acceso directo a Mensajes así como Agentes Gestionados. OpenClaw y Hermes van un paso más allá y muestran lo que sucede cuando colocas esas capacidades detrás de pasarelas persistentes, canales, sesiones y memoria.

En otras palabras, un sistema de asistente tiene un contrato más amplio que una finalización de chat. Un buen contrato interno se ve algo así:

SolicitudAsistente  = intención del usuario + identidad + sesión + adjuntos + política
RespuestaAsistente = respuesta + acciones + citas + cambios de estado + ID de trazo

Este contrato importa porque cada desacuerdo en producción eventualmente se reduce a una de estas preguntas: qué contexto era visible, qué herramienta se ejecutó, qué modelo respondió, qué memoria se leyó o escribió, y dónde el trazo dice que el sistema pasó el tiempo. OpenTelemetry define los trazos como el camino de una solicitud a través de una aplicación, que es exactamente la abstracción que los asistentes serios necesitan. LangSmith y OpenLIT luego especializan esa idea para LLMs, herramientas, almacenes vectoriales y flujos de trabajo de agentes.

Componentes e interfaces principales

La división de componentes a continuación es la que encuentro más durable. También es la división que mejor se alinea con las APIs oficiales y los entornos de ejecución de código abierto que la gente realmente opera.

La tabla anterior se deriva de las interfaces oficiales de los proveedores, MCP, la documentación de bases de datos vectoriales y la documentación de runtime para vLLM, llama.cpp, OpenClaw y Hermes.

La capa LLM debería hacer tres cosas bien: consumir un contexto de trabajo actual, emitir una respuesta final o una solicitud de acción estructurada, y devolver suficiente metadatos para soportar reintentos y trazabilidad. La API de Respuestas de OpenAI está diseñada explícitamente para interacciones con estado más herramientas integradas y llamadas a funciones. La API de Mensajes de Anthropic expone el mismo ciclo central a través de bloques tool_use y retornos tool_result, mientras que los Agentes Gestionados te dan un entorno alojado si no quieres construir el ciclo tú mismo. Los entornos de ejecución autoalojados como vLLM y llama.cpp importan porque preservan interfaces estilo proveedor familiares mientras te permiten colocar la inferencia dentro de tu propio entorno.

La capa de Memoria debería dividirse mentalmente en tres categorías: memoria de trabajo, memoria simbólica durable y memoria semántica buscable. Las incrustaciones de OpenAI devuelven vectores que pueden indexarse y buscarse; la Recuperación y Búsqueda de Archivos de OpenAI luego superponen búsqueda semántica y por palabras clave sobre almacenes vectoriales. Pinecone, Weaviate, pgvector y Milvus representan cuatro formas de almacenamiento comunes: totalmente gestionado, vectorial nativo de código abierto, nativo de Postgres y base de datos vectorial distribuida. Hermes y OpenClaw añaden un recordatorio útil de que no toda la memoria pertenece en un almacén vectorial: notas respaldadas por archivos, promociones revisadas y instantáneas con alcance de sesión a menudo son el diseño más honesto. Sistemas de Memoria en Asistentes de IA mapea el modelo trans-framework; Sistema de Memoria del Agente Hermes desglosa la memoria central acotada y las instantáneas de sesión congeladas en un producto.

La capa de Herramientas es donde un asistente deja de ser un resumidor y comienza a ser software. Las llamadas a funciones de OpenAI tratan las herramientas como funcionalidad definida por esquema que el modelo puede decidir invocar. Anthropic dice lo mismo de manera más explícita: el uso de herramientas es un contrato entre tu aplicación y el modelo, y el modelo nunca ejecuta nada por sí solo. MCP generaliza ese contrato en un protocolo cliente-servidor donde los hosts se conectan a uno o más servidores que exponen herramientas, prompts y recursos, el mismo límite descrito paso a paso en Servidor MCP en Go. LangChain y LlamaIndex se sienten cómodos aquí como bibliotecas de orquestación: LangChain se centra en una arquitectura de agente preconstruida e integraciones, mientras que LlamaIndex se centra en acceso a datos aumentados por contexto, motores de consulta y flujos de trabajo.

La capa de Enrutamiento existe porque “¿qué modelo?” nunca es la única pregunta. También necesitas “¿qué ruta de proveedor, qué inquilino, qué presupuesto, qué clase de latencia y qué conmutación por error?”. LiteLLM es útil porque su documentación oficial es refrescantemente concreta: selección ponderada, menos ocupado, basado en latencia, basado en costo y conmutaciones por error acotadas son todos patrones de primera clase. OpenClaw extiende el enrutamiento hacia arriba hacia el aislamiento de canales y agentes, mientras que Hermes lo extiende hacia abajo hacia ranuras de modelo para trabajo principal y auxiliar como resumen, compresión de contexto y enrutamiento de herramientas MCP. Ese es el modelo mental correcto: el enrutador elige más que un modelo, elige un carril de ejecución.

La capa de Observabilidad es lo que evita que la arquitectura se convierta en folklore. OpenTelemetry te da la abstracción de trazo. LangSmith te da visibilidad de extremo a extremo sobre los pasos de la aplicación de LLM y soporta formas de despliegue en la nube, híbridos y autoalojados. OpenLIT te da observabilidad de IA nativa de OpenTelemetry con opciones de instrumentación sin código y manual, incluyendo soporte para LLMs, frameworks de agentes, bases de datos vectoriales y GPUs. Para métricas de producción, trazos y patrones de SLO a través de flujos de trabajo de inferencia y agentes, consulta Observabilidad para Sistemas de LLM. Si tu asistente no tiene un trazo por solicitud, un span por llamada de modelo y un historial de eventos para la ejecución de herramientas, realmente no tienes una arquitectura aún. Tienes “vibes”.

Capturar, enriquecer, responder

La secuencia que sigue apareciendo en sistemas reales es capturar -> enriquecer -> responder -> registrar. Diferentes frameworks lo envuelven de manera diferente, pero el flujo es lo suficientemente estable como para tratarlo como la columna vertebral.

sequenceDiagram
    participant U as Usuario o Canal
    participant G as Pasarela o UI
    participant R as Enrutador
    participant M as Memoria y Recuperación
    participant L as LLM
    participant T as Herramientas o MCP
    participant O as Observabilidad

    U->>G: mensaje, archivo o comando
    G->>O: iniciar trazo raíz
    G->>R: solicitud + identidad + sesión + política
    R->>M: cargar estado de sesión y recuperar contexto
    M-->>R: notas, fragmentos, metadatos
    R->>L: prompt + contexto + esquemas de herramientas
    L-->>R: respuesta o llamada a herramienta
    alt llamada a herramienta
        R->>T: ejecutar herramienta o acción MCP
        T-->>R: resultado de herramienta
        R->>L: resultado de herramienta + contexto actualizado
        L-->>R: respuesta final
    end
    R->>M: persistir cambios de sesión y candidatos de memoria
    R->>O: spans, métricas, eventos de evaluación
    G-->>U: respuesta

El paso de captura suele ser más importante de lo que parece. OpenClaw y Hermes ponen una pasarela persistente delante del asistente porque el ingreso no es solo entrada de texto. Incluye metadatos de canal, identidades, autorización, límites de sesión, mensajes directos, grupos, ticks cron y semánticas de entrega. Si saltas esa capa y confías en una abstracción de widget de chat crudo, eventualmente la volverás a montar como middleware ad hoc de todas formas.

El paso de enriquecimiento es donde los sistemas maduros se separan de las demos de juguete. La Recuperación y Búsqueda de Archivos de OpenAI hacen la recuperación explícita a través de almacenes vectoriales y llamadas de búsqueda. LlamaIndex formaliza el mismo patrón a través de conectores de datos, índices, motores de consulta y flujos de trabajo. Hermes va más allá dividiendo el patrimonio de modelos en ranuras principales y auxiliares, delegando trabajo como compresión, resumen y enrutamiento a modelos más pequeños o especializados. Ese es un patrón de diseño que vale la pena robar: no gastes los tokens de tu modelo más caro en tareas rutinarias.

El paso de respuesta no es “generar texto”. Es “cerrar el ciclo actual”. Si el modelo puede responder directamente, lo hace. Si necesita una herramienta, emite una solicitud estructurada. El contrato de uso de herramientas de Anthropic y la guía de llamadas a funciones de OpenAI hacen esto explícito. La razón por la que esto importa arquitectónicamente es que los outputs ahora incluyen tanto lenguaje como flujo de control. Tu objeto de respuesta es parcialmente prosa y parcialmente plan de runtime.

El paso de registro es donde aparecen las semánticas de consistencia. Pinecone separa las rutas de escritura y lectura y procesa escrituras después de un reconocimiento durable. La memoria de Hermes se inyecta como una instantánea congelada por sesión para preservar el rendimiento de la caché de prefijo, lo que significa que las nuevas escrituras no aparecen automáticamente en el prompt de la sesión actual. El sistema Dreaming de OpenClaw solo promueve candidatos revisados y fundamentados a MEMORY.md, y es opcional en lugar de estar siempre activo. La lección práctica es que la memoria rara vez es verdaderamente lectura-después-de-escritura a través de cada capa. Necesitas diseñar para visibilidad escalonada.

OpenClaw y Hermes como sistemas de referencia

OpenClaw y Hermes son casos de referencia útiles porque no son solo wrappers alrededor de una API de proveedor. Ambos presentan un asistente como un sistema de larga duración con pasarelas, sesiones, herramientas, memoria y múltiples backends de modelo.

Este mapeo se basa en la documentación oficial y repositorios de OpenClaw y Hermes. OpenClaw documenta una arquitectura de pasarela, enrutamiento multi-agente, soporte para proveedores personalizados y autoalojados incluyendo vLLM y Ollama, memoria activa opcional y promoción basada en Dreaming. Hermes documenta una pasarela de mensajería, un bucle central AIAgent, ranuras de modelo principal y auxiliar, memoria integrada e integración MCP nativa.

Mi lectura ligeramente opinada es que ambos sistemas hacen el mismo argumento arquitectónico con diferentes acentos. OpenClaw es fuertemente primero-pasarela. Hermes es fuertemente primero-bucle-agente. Pero ambos rechazan la idea superficial de que un asistente es solo “prompt más modelo”. Modelan canales, identidades, semánticas de memoria, superficies de herramientas y heterogeneidad de backend como preocupaciones de primera clase. Eso es exactamente lo que una arquitectura de producción debería hacer.

Un stack híbrido práctico inspirado en ambos sistemas se ve así:

edge:
  gateway: hermes o openclaw

routing:
  proxy: litellm
  policy: consciente de latencia y presupuesto
  tenancy: con alcance de sesión y canal

llm:
  primary: respuestas de openai o mensajes de anthropic
  local_fallback: vllm
  local_dev: ollama o llama.cpp

memory:
  session: sqlite o postgres
  semantic: pgvector o weaviate
  embeddings: incrustaciones de openai o incrustaciones de ollama

tools:
  contract: herramientas de esquema json más mcp
  examples: sistema de archivos, navegador, búsqueda web, APIs internas

observability:
  traces: opentelemetry
  ai_dashboards: openlit o langsmith
  evals: evals de openai más conjuntos de regresión específicos de la aplicación

Ese stack es un patrón de despliegue razonado más que un blueprint prescrito por un vendedor. Funciona porque las interfaces oficiales se alinean: OpenAI y Anthropic exponen APIs orientadas a herramientas, vLLM y llama.cpp emulan puntos finales estilo proveedor, Ollama maneja modelos e incrustaciones locales, MCP estandariza herramientas externas, LiteLLM maneja enrutamiento y conmutación por error, y las plataformas compatibles con OpenTelemetry pueden trazar todo el camino.

Patrones, tablas y compensaciones

Hay algunos patrones de asistente repetibles que vale la pena nombrar. Un asistente gestionado mantiene la mayor parte del runtime dentro de las APIs del proveedor. Un asistente primero-recuperación trata la memoria y la búsqueda como el principal diferenciador. Un asistente primero-herramienta se comporta más como un operador que como un chatbot. Un asistente de pasarela prioriza el acceso siempre activo a través de superficies de mensajería. Una malla de especialistas descompone el trabajo en múltiples agentes o rutas. La documentación oficial a través de OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw y Hermes respalda versiones de estos patrones, incluso si los nombran de manera diferente.

Esta tabla de patrones es una síntesis de la documentación de los proveedores, frameworks y sistemas de referencia, más que una afirmación de un solo vendedor.

Notas de la tabla: La Búsqueda de Archivos alojada de OpenAI es una herramienta gestionada, Anthropic ofrece un entorno gestionado, Pinecone es un servicio vectorial gestionado, mientras que vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith autoalojado y OpenLIT soportan operación autoadministrada o híbrida en diversos grados.

Notas de la tabla: Pinecone documenta un plano de control gestionado y planos de datos regionales. Weaviate documenta vectores e índices invertidos con múltiples tipos de índice vectorial. pgvector añade búsqueda exacta y de vecinos más cercanos aproximados a Postgres. Milvus se posiciona como una base de datos vectorial de alto rendimiento y escalable de código abierto, con Zilliz Cloud como la opción gestionada.

Notas de la tabla: OpenAI documenta Respuestas como su interfaz avanzada para respuestas con estado y herramientas integradas. Anthropic documenta la API de Mensajes y el contrato de uso de herramientas por separado de los Agentes Gestionados. vLLM expone un servidor compatible con OpenAI más soporte para la API de Mensajes de Anthropic. Ollama documenta flujos de trabajo de incrustaciones y modelos locales. llama.cpp documenta rutas de chat, respuestas e incrustaciones compatibles con OpenAI, más finalizaciones de chat compatibles con Anthropic.

Esta matriz de compensaciones es una inferencia arquitectónica de la documentación oficial, no un benchmark de vendedor. La fila de consistencia importa más de lo que muchos posts de blog admiten: Pinecone separa las rutas de escritura y lectura, Hermes congela la memoria en prompts de inicio de sesión, y OpenClaw promueve memoria durable a través de revisión escalonada. Eso significa que “memoria actualizada” y “memoria visible para la respuesta actual” a menudo son verdades diferentes.

Modos de fallo y mitigaciones

La mayoría de los asistentes no fallan porque el modelo base es “malo”. Fallan porque el sistema circundante miente al modelo, lo priva del contexto adecuado, permite que las herramientas se desvíen o hace la depuración imposible.

La base de evidencia para esta tabla es amplia pero consistente. La documentación de herramientas de Anthropic deja claro que el uso de herramientas es un límite de contrato. Los Guardrails de OpenAI incluyen detección de alucinaciones contra una base de conocimiento de referencia vía Búsqueda de Archivos. SelfCheckGPT muestra que la autoconsistencia a través de muestras puede ayudar a detectar afirmaciones sin soporte. Los resultados de “Lost in the Middle” y la guía de contexto de Anthropic refuerzan la misma lección operativa: más tokens no eliminan la necesidad de curación de contexto.

El stack de mitigación preferido podría ser aburrido y repetitivo: traza cada solicitud, versiona prompts, evalúa la recuperación independientemente, mantén herramientas idempotentes y ejecuta evals de regresión antes de cambiar rutas o política de memoria. La documentación y repo de Evals de OpenAI son directos sobre el porqué: sin evals, es difícil y consume tiempo entender cómo los cambios de modelo o prompt afectan tu caso de uso. Eso aplica tanto a enrutadores y recuperación como a prompts.

Más lectura

Si quieres profundizar, estas son las fuentes primarias más útiles para mantener abiertas mientras diseñas o revisas una arquitectura de asistente.

• OpenAI: Vista General de Respuestas, Llamadas a Funciones, Uso de Herramientas, Recuperación, Búsqueda de Archivos, Evals y MCP para servidores de herramientas remotos.

• Anthropic: Vista General de API, Uso de Herramientas, el contrato de uso de herramientas, Agentes Gestionados, Ventanas de Contexto y el conector MCP.

• MCP en sí: la Vista General de Arquitectura y la Especificación valen la pena leerse directamente, porque explican hosts, clientes, servidores, herramientas, prompts, recursos, transportes y negociación de capacidades de forma limpia.

• Frameworks y enrutamiento: Vista General de LangChain, documentación de aumento de contexto de LlamaIndex, documentación de enrutamiento de LiteLLM, documentación de observabilidad de LangSmith.

• Entornos de ejecución autoalojados y sistemas de asistente: vLLM, servidor llama.cpp, incrustaciones de Ollama, documentación y repo de OpenClaw, documentación y repo de Hermes.

• Almacenamiento y observabilidad: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Papers de investigación: Generación Aumentada con Recuperación para Tareas de NLP Intensivas en Conocimiento, Lost in the Middle y SelfCheckGPT.