Diagrama de arquitectura de un agente de IA: modelo, herramientas, memoria y salvaguardas

La mayoría de los diagramas de agentes de IA muestran un icono de robot junto al logo de un LLM, con una flecha que dice «herramientas». Esa imagen oculta las preguntas que deciden si un agente es seguro de ejecutar: quién elige el siguiente paso, qué puede tocar el agente, por dónde entra el texto no fiable y qué detiene una ejecución que no lleva a ninguna parte.

Este artículo descompone un agente en sus partes, recorre el bucle que lo impulsa, cubre las herramientas y el Model Context Protocol, la memoria, las salvaguardas, los límites y las trazas, y dibuja un agente de soporte al cliente que puede consultar pedidos y emitir reembolsos.

¿Flujo de trabajo o agente?

La guía de Anthropic para construir agentes eficaces traza una línea útil. En un flujo de trabajo, los LLM y las herramientas se orquestan mediante rutas de código escritas de antemano. En un agente, el modelo dirige su propio proceso y decide, paso a paso, qué herramientas usar hasta terminar la tarea.

La misma guía recomienda la solución más sencilla que funcione. Si una tarea sigue siempre los mismos tres pasos, escribe esos pasos en código y llama al modelo dentro de ellos. Recurre a un agente cuando el camino dependa de lo que el agente encuentre por el camino: un caso de soporte en el que la siguiente consulta depende de la última respuesta, o una tarea de programación que necesita varias rondas de edición y prueba.

Las partes de un agente

El modelo es solo una caja. La mayor parte de la ingeniería, y la mayor parte del control de riesgos, vive en el código que lo rodea.

El bucle

Reducido a lo esencial, el runtime es un bucle:

def run(task, user):
    messages = [system_prompt(user), task]
    for step in range(MAX_STEPS):
        reply = llm.generate(messages, tools=allowed_tools(user))
        if not reply.tool_calls:
            return check_output(reply.text)
        for call in reply.tool_calls:
            result = execute(call, user)   # permission check, approval, timeout
            messages.append(tool_result(call, result))
    return stop("step limit reached", messages)

El modelo nunca ejecuta nada por sí mismo. Devuelve o bien una respuesta o bien una petición de llamar a una herramienta con ciertos argumentos, y el runtime decide si la ejecuta y cómo. Ahí está el control: las comprobaciones de permisos, las aprobaciones, los timeouts y los límites están en execute y en el bucle, no en el prompt.

Las herramientas y el lugar de MCP

Una herramienta es una función que el modelo puede solicitar: un nombre, una descripción y un esquema JSON para sus argumentos. Las descripciones importan tanto como el código, porque son todo lo que el modelo sabe sobre cuándo usar una herramienta.

El Model Context Protocol es un estándar abierto para conectar aplicaciones de IA con sistemas externos. Un servidor MCP expone herramientas, datos y prompts; el runtime del agente actúa como cliente. En lugar de cablear cada integración en el código del agente, cada sistema publica un servidor y cualquier runtime compatible con MCP puede usarlo.

Las buenas herramientas comparten algunos rasgos:

• Pocas y específicas. refund_order(order_id, amount, reason) es mejor que un call_api(url, body) genérico.
• Lectura y escritura separadas, para que un rol pueda tener herramientas de lectura sin las de escritura.
• Errores claros con los que el modelo pueda actuar, como «el importe supera el total del pedido».
• Claves de idempotencia en las escrituras, para que un paso reintentado no reembolse dos veces.

La memoria

Los agentes tienen dos tipos de memoria, y los diagramas suelen mezclarlos:

• La memoria de trabajo es el contexto que se envía al modelo en cada paso: instrucciones, la conversación y los resultados de herramientas hasta el momento. Está limitada por la ventana de contexto del modelo y por el coste, así que las ejecuciones largas resumen los pasos antiguos o descartan la salida en bruto de las herramientas una vez usada.
• El conocimiento a largo plazo vive fuera del modelo: documentos, políticas, tickets anteriores. El agente recupera las partes relevantes, a menudo de un índice vectorial, y las añade a la memoria de trabajo. El diagrama de arquitectura RAG cubre en detalle el pipeline de recuperación.

El estado de la tarea que debe sobrevivir a una caída, como qué pasos ya se ejecutaron y qué aprobación está pendiente, va en una base de datos normal, no en el contexto del modelo.

Salvaguardas y permisos

El Top 10 de OWASP para aplicaciones LLM pone la inyección de prompts en primer lugar. Otra entrada, la agencia excesiva, cubre las acciones dañinas que un sistema LLM puede realizar porque tiene más funcionalidad, permisos o autonomía de los que necesita. Los agentes están expuestos a ambas: leen texto no fiable (entradas de usuario, páginas web, documentos recuperados, resultados de herramientas) y pueden actuar.

Reglas que funcionan en la práctica:

• Trata cada resultado de herramienta y cada documento recuperado como datos. El texto de una página web no puede conceder permisos ni cambiar la tarea.
• Actúa con los permisos del usuario, no con una cuenta de servicio que puede ver a todos los clientes.
• Controla las escrituras. Las lecturas se ejecutan libremente; las escrituras por encima de un umbral, o cualquier acción irreversible, esperan a una persona.
• Aísla la ejecución de código en un sandbox: sin credenciales y sin red por defecto.
• Revisa las salidas antes de que lleguen a usuarios u otros sistemas, en busca de datos internos filtrados o contenido inseguro.

El diagrama de flujo de datos para el modelado de amenazas es una buena forma de encontrar dónde el texto no fiable entra en un componente capaz de actuar.

Límites y coste

Un agente que da vueltas sin avanzar quema dinero y paciencia. Pon los límites en el runtime, no en el prompt:

• Pasos: un número máximo de llamadas al modelo por tarea.
• Tiempo: un límite de tiempo real por tarea y un timeout por llamada a herramienta.
• Dinero: un presupuesto en tokens o dólares por tarea y por usuario y día.
• Tasa: límites de peticiones por usuario en la API, como en el diseño de un rate limiter.

Cuando se alcance un límite, para limpiamente: devuelve lo encontrado hasta el momento, indica qué límite detuvo la ejecución y conserva la traza para revisarla.

Trazas y evaluaciones

Registra cada paso: el contexto enviado, el modelo y su configuración, cada llamada a herramienta con argumentos y resultados, tokens, latencia y coste. OpenTelemetry tiene convenciones semánticas para la IA generativa, así que estas trazas pueden ir a los mismos backends que el resto de tu sistema; el diagrama de arquitectura de observabilidad muestra ese pipeline.

Las trazas responden a «¿qué pasó en esta ejecución?». Las evaluaciones responden a «¿el agente mejora o empeora?»: un conjunto fijo de tareas realistas, puntuadas automáticamente, que se ejecuta con cada cambio de prompts, herramientas o modelos.

El diagrama de arquitectura

Cómo leerlo:

• Izquierda: el usuario envía una tarea por la app de chat, que gestiona el inicio de sesión y las sesiones y pasa la tarea, con la identidad del usuario, a las salvaguardas.
• Centro: el bucle del agente envía el contexto y la lista de herramientas al LLM (línea continua) y recibe una respuesta o una llamada a herramienta (discontinua). Lee y escribe la memoria de trabajo; el bloque Markdown enumera los límites.
• Derecha: las llamadas a herramientas van a la búsqueda web, a un sandbox de código y a la API de pedidos. Un reembolso espera al aprobador (discontinuo).
• Abajo: el índice de conocimiento aporta documentos recuperados a la memoria de trabajo y cada paso se registra en trazas y evaluaciones (punteado).

Un ejemplo completo: un reembolso

Un cliente escribe: «El pedido 4411 llegó roto, quiero que me devuelvan el dinero».

1. Las salvaguardas revisan el mensaje y adjuntan la identidad del cliente.
2. El modelo pide get_order(4411). El runtime comprueba que el pedido pertenece a este cliente y devuelve: entregado hace tres días, 180 dólares.
3. El runtime recupera la política de reembolsos del índice de conocimiento y la añade a la memoria de trabajo: los artículos dañados se reembolsan dentro de 30 días.
4. El modelo pide refund_order(4411, 180, "damaged"). El importe supera el umbral de 100 dólares, así que el runtime pausa la ejecución y envía una solicitud de aprobación a una responsable de soporte.
5. La responsable aprueba. El runtime ejecuta el reembolso con una clave de idempotencia y devuelve la confirmación.
6. El modelo redacta la respuesta, las comprobaciones de salida pasan y el cliente recibe su respuesta.

Tres llamadas al modelo, dos llamadas a herramientas, una recuperación, una aprobación y una traza que muestra cada paso.

Qué poner en un diagrama de agente

• Quién decide el siguiente paso: el modelo o el código que escribiste.
• Cada herramienta, con acceso de lectura o escritura y con qué permisos actúa.
• Los puntos de aprobación para acciones arriesgadas.
• Los límites: pasos, tiempo y presupuesto.
• Por dónde entra el texto no fiable: entradas de usuario, páginas web, documentos, resultados de herramientas.
• Las trazas, para que quien revise sepa que las ejecuciones pueden inspeccionarse.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade dos nodos Persona del pack Modelo C4 para el usuario y el aprobador, y un Contenedor para la app de chat.
3. Añade un Marco del pack Básico para el runtime del agente, con un Contenedor para el bucle del agente y dos nodos Componente para las salvaguardas y la memoria de trabajo.
4. Añade un Modelo y un Índice vectorial del pack ML, un segundo Marco con tres nodos Tarjeta de servicio del pack Stack para las herramientas, y Trazas del pack DevOps.
5. Dibuja las respuestas del modelo con línea discontinua y la arista de trazas punteada, y añade un bloque Markdown del pack Básico con los límites. Para que un agente lo dibuje por ti, consulta crear diagramas con agentes de IA mediante MCP.

El ejemplo usa 15 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué diferencia hay entre un agente de IA y un flujo de trabajo? En un flujo de trabajo, tu código decide la secuencia de pasos y llama al modelo dentro de ellos. En un agente, el modelo decide el siguiente paso y qué herramientas usar, dentro de un bucle que tu código controla.

¿Qué es MCP en una arquitectura de agentes? El Model Context Protocol es un estándar abierto para conectar aplicaciones de IA con herramientas y datos. Los sistemas exponen servidores MCP y el runtime del agente se conecta a ellos como cliente.

¿Cómo evito que un agente realice acciones dañinas? Dale solo las herramientas que necesita, ejecútalas con los permisos del usuario, exige aprobación humana para las escrituras por encima de un umbral y trata todos los resultados de herramientas y documentos como datos no fiables.

¿Cómo recuerdan las cosas los agentes? Dentro de una ejecución, mediante el contexto que se envía al modelo en cada paso. Entre ejecuciones, mediante conocimiento almacenado que se recupera cuando hace falta y mediante el estado de la tarea guardado en una base de datos.

¿Cómo mantengo bajo control los costes de un agente? Fija en el runtime límites de pasos, tiempo y tokens por tarea, añade presupuestos por usuario y traza cada ejecución para que los patrones caros salgan a la luz en las revisiones.

Empieza gratis — un puesto, sin tarjeta de crédito.