Anatomía de un AI agent: del MCP al multi-agente

MCP es a las herramientas de IA lo que USB fue a los periféricos: antes, cada framework de agentes tenía su propia manera de definir y conectar herramientas; MCP estandariza eso.

MATTEO DI PAOLANTONIO
CTO Orbitant

Esta es la segunda entrega de una serie de tres dedicada a la arquitectura de un AI agent. En el primer post expliqué cómo funciona un agente por dentro: el bucle, las herramientas y el runtime. Esta entrega recorre lo que vive alrededor: el protocolo por el que se conecta al mundo, los workflows reutilizables que encapsulan trabajo, los guardarraíles que lo mantienen dentro del marco que le has dado, y los patrones para coordinar varios agentes cuando uno solo no basta.

Este segundo post recorre los cinco bloques que viven en torno al modelo y al runtime: MCP como protocolo de conexión, skills como capacidad encapsulada, límites y guardarraíles, sistemas multi-agente, y dónde encaja un caso de uso dentro del espectro entre llamada LLM simple y agente totalmente autónomo. La tercera entrega de la serie se centrará en la operación: observabilidad, evaluación y mejora continua.

MCP: el protocolo que conecta al agente con el mundo

MCP (Model Context Protocol) es un estándar abierto creado por Anthropic, anunciado a finales de 2024 y que se ha ido adoptando a lo largo de 2025 y 2026. Define una manera universal para que los agentes de IA se conecten a herramientas y fuentes de datos externas.

Antes de MCP, cada framework de agentes resolvía esto a su manera. Cada conector era código a medida.

La arquitectura

┌──────────┐    ┌────────────┐    ┌────────────────┐
│ AI Agent │←→│ MCP Client │←→│  MCP Server     │
│ (Claude) │    │ (built-in) │    │  (provides      │
└──────────┘    └────────────┘    │   tools/data)   │
                                   └────────────────┘
                                          │
                                          ▼
                                   ┌────────────────┐
                                   │  Database       │
                                   │  API            │
                                   │  Files          │
                                   └────────────────┘

• Servidor MCP: proceso ligero que contiene capacidades (herramientas, recursos, prompts) a través de un protocolo JSON-RPC estandarizado. Cualquiera puede escribir uno.
• Cliente MCP: integrado en la aplicación. Descubre servidores MCP y se conecta a ellos.
• Transporte: la comunicación viaja por stdio (local) o por HTTP con Server-Sent Events (remoto).

Lo que contiene un servidor MCP se divide en tres categorías:

1. Tools (herramientas): funciones que el agente puede llamar (por ejemplo, query_database, create_jira_ticket).
2. Resources (recursos): datos que el agente puede leer (contenido de ficheros, esquemas de base de datos).
3. Prompts: plantillas de prompt preconstruidas para tareas habituales.

MCP frente a herramientas nativas

Desde la perspectiva del LLM no hay ninguna diferencia entre una herramienta nativa y una herramienta vía MCP. El modelo ve una herramienta llamada query_database con un esquema, la llama y recibe un resultado. No sabe —ni le importa— si la implementación es una función hard-coded o un servidor MCP.

La diferencia vive entera en la fontanería: cómo se descubren, conectan y ejecutan las herramientas.

	Native Tool	MCP (stdio, local)	MCP (HTTP, remoto)
¿Mismo proceso?	Sí	No	No
¿Misma máquina?	Sí	Sí	No
¿Mismo lenguaje?	Obligatoriamente	No importa	No importa
¿Interfaz estandarizada?	No (depende del framework)	Sí	Sí

La frontera real que dibuja MCP es el aislamiento de procesos, no necesariamente la separación de red. Es similar a la diferencia entre llamar a una función directamente y llamar a un sidecar container en Kubernetes: puede estar en el mismo nodo, pero es un proceso separado con su propio ciclo de vida, permisos y dominio de fallo.

La analogía con la ingeniería de software ayuda a fijar el concepto:

• Native tools = funciones helper dentro de tu codebase (utils/formatDate.ts).
• MCP servers = APIs REST que llamas (api.stripe.com/v1/charges).

Ambas dan capacidades. Pero la API REST la mantiene otro equipo, es agnóstica al lenguaje, se despliega de forma independiente, es descubrible (vía su schema) y vive aislada. MCP es esencialmente OpenAPI/Swagger pero diseñado específicamente para agentes de IA.

Las cuatro propiedades por las que importa en producción:

• Write once, use everywhere: un solo servidor MCP funciona con Claude, Cursor, VS Code y cualquier agente compatible.
• Ecosistema: a principios de 2026 hay miles de servidores MCP creados por la comunidad, desde GitHub hasta Kubernetes pasando por Figma.
• Seguridad: MCP incluye patrones para autenticación, permission scoping y sandboxing.
• Composabilidad: un agente puede conectarse a varios servidores MCP a la vez, ganando acceso a múltiples conjuntos de herramientas.

El protocolo

MCP usa JSON-RPC (inspirado en LSP, el protocolo que usan los editores para los language servers). Una conversación se ve así:

// 1. El cliente (agente) pregunta: ¿qué sabes hacer?
→ { "method": "tools/list" }

// 2. El servidor responde con los esquemas de sus herramientas
← { "result": { "tools": [
    {
      "name": "query_database",
      "description": "Run a SQL query",
      "inputSchema": {
        "type": "object",
        "properties": {
          "sql": { "type": "string" }
        }
      }
    }
  ]}}

// 3. El LLM decide llamar a la herramienta; el cliente la reenvía al servidor
→ { "method": "tools/call",
    "params": { "name": "query_database",
                "arguments": { "sql": "SELECT * FROM users LIMIT 5" }}}

// 4. El servidor ejecuta y devuelve el resultado
← { "result": { "content": [{ "type": "text", "text": "..." }] }}

El runtime del agente convierte automáticamente las definiciones de herramientas MCP al mismo formato que las herramientas nativas antes de enviarlas al LLM. El modelo ve una lista plana de funciones que se pueden llamar.

Skills: workflows reutilizables

Una skill es una capacidad reutilizable de más alto nivel que un agente puede invocar: un workflow preempaquetado, no una sola llamada a una herramienta. Aparece cuando un mismo conjunto de pasos se repite con frecuencia y vale la pena encapsularlo en una sola unidad invocable.

Skills frente a tools

Aspecto	Tool	Skill
Granularidad	Una sola llamada de función	Workflow multi-paso
Ejemplo	read_file("main.py")	/commit (revisa cambios, genera mensaje, hace commit)
Complejidad	Operación atómica	Secuencia orquestada
Estado	Stateless	Puede mantener estado entre pasos

Cómo funcionan las skills

Cuando se activa, una skill:

1. Carga instrucciones especializadas (una plantilla de prompt con pasos detallados).
2. Define un workflow concreto (por ejemplo, en /commit: revisa el estado, lee el diff, redacta el mensaje, hace el commit).
3. Puede restringir qué herramientas están disponibles (allowed-tools).
4. Invoca múltiples herramientas en secuencia.
5. Devuelve un resultado estructurado.

Las skills encapsulan el saber hacer de tareas concretas para que el agente no tenga que reconstruir el workflow desde cero cada vez. Son, en esencia, abstracciones a nivel de agente.

Límites de ejecución y gestión del contexto

El bucle agéntico corre «hasta terminar o hasta alcanzar un límite». Sin algún mecanismo que lo detenga, un agente puede entrar en bucles infinitos, gastar todo el presupuesto de tokens o quedarse atascado esperando una herramienta. Para evitarlo existen varios tipos de límites que paran la ejecución, más estrategias para gestionar la ventana de contexto del LLM, que es uno de los recursos más caros del bucle.

Iteration limit

Un tope sobre cuántas vueltas puede dar el agente. Es un mecanismo de seguridad para evitar bucles infinitos.

agent = Agent(
    model="claude-sonnet-4-6",
    tools=[...],
    max_iterations=50  # después de 50 ciclos observe-think-act, parar
)

El motivo: un agente puede atascarse intentando el mismo enfoque fallido una y otra vez, o entrando en una madriguera de la que no sale. Sin un límite, corre eternamente quemando dinero y sin avanzar.

Context window limit

El modelo solo puede «ver» una cantidad finita de texto a la vez. A medida que el agente itera, la conversación crece:

Loop 1: [system prompt] + [user goal] + [tool call] + [tool result] → 5K tokens
Loop 5: ... + 5 rondas más de razonamiento + tool calls + resultados → 30K tokens
Loop 20: ... historial de conversación enorme → 150K tokens
Loop 40: ... rozando el techo → 200K tokens

Cuando se queda sin contexto, el agente no puede seguir pensando: pierde el inicio de la conversación, pierde de vista lo que estaba haciendo, y la calidad se degrada.

Otros límites: coste, tiempo y error

Existen otros tres límites más cortos en su explicación, pero igual de importantes en operación:

• Cost / token budget: cada vuelta cuesta dinero (las llamadas a la «API» se facturan por token). Un agente que dé 50 vueltas con resultados de herramientas grandes puede costar dólares por ejecución.
• Time limit: un timeout de reloj de pared. Si el agente lleva 30 minutos corriendo, parar independientemente del progreso.
• Error limit: cuántos fallos consecutivos se toleran antes de abandonar. Si el agente falla 5 llamadas a herramienta seguidas, algo está fundamentalmente mal.

Estrategias para gestionar el contexto

Uno de los problemas de ingeniería más difíciles al construir agentes es cómo lidiar con el límite de la ventana de contexto. Existen cuatro estrategias habituales:

• Compresión / resumen de conversación: cuando el contexto crece, se resumen las partes antiguas y se descartan los detalles en bruto.
• Sliding window: conservar solo los últimos N mensajes. Simple pero con pérdida: el agente olvida el contexto inicial.
• Memoria a largo plazo / almacenamiento externo: escribir los hallazgos importantes a un fichero o base de datos a medida que avanzan, para releerlos después sin necesidad de tenerlos en el contexto.
• Uso más inteligente de las herramientas: devolver menos datos. En lugar de volcar un fichero de 10.000 líneas al contexto, leer solo las 20 líneas relevantes.

La primera, la compresión, opera del siguiente modo:

Antes (50K tokens):

[resultado detallado de tool en loop 1]
[resultado detallado de tool en loop 2]
[resultado detallado de tool en loop 3]
…

...Después de la compresión (5K tokens):

[resumen: "En los loops 1-10 he explorado el codebase y he encontrado
el bug en auth.py línea 42. Hallazgos clave: …"]
[resultado detallado de tool del loop 11] ← los recientes se conservan intactos
```

El trade-off

Ajustar todos estos límites implica un equilibrio: si son demasiado bajos, el agente abandona problemas que podría resolver; si son demasiado altos, desperdicia recursos en problemas irresolubles o en bucles.

Límites demasiado bajos  → el agente abandona antes de resolver problemas difíciles
Límites demasiado altos  → el agente desperdicia recursos en problemas irresolubles o en bucles

No existe una respuesta universal correcta porque depende del tipo de agente. Un agente de codificación puede necesitar más de 100 iteraciones para una refactorización compleja, mientras que un agente de Q&A debería terminar en 3-5. Cada uno se afina según el caso de uso.

Guardarraíles: humano en el bucle y validación I/O

Los límites del bloque anterior previenen los escenarios de fallo más obvios (bucles infinitos, gasto descontrolado, contextos saturados), pero no cubren todo lo que puede salir mal cuando un agente con autonomía toca sistemas externos. Para eso existen los guardarraíles: controles que se sitúan alrededor del bucle agéntico para evitar que el agente haga algo arriesgado, irreversible o no autorizado.

Checkpoints humanos en el bucle (Human-in-the-Loop)

El agente se detiene y pregunta a un humano antes de hacer algo arriesgado:

• «Voy a borrar 200 ficheros. ¿Procedo?»
• «Voy a hacer push a main. ¿Confirmas?»
• «Esto enviará un email a 500 clientes. ¿Seguro?»

Se puede configurar por tipo de acción:

read files    → siempre permitir (riesgo bajo)
edit files    → preguntar la primera vez, luego permitir (riesgo medio)
run bash      → siempre preguntar (riesgo alto)
git push      → siempre preguntar (irreversible)

Validación de entrada/salida (Input/Output validation)

Comprobar qué entra y qué sale del agente por seguridad:

• Input validation: ¿lo que pide el usuario está permitido? ¿la entrada está bien formada? ¿el usuario tiene permiso?
• Output validation: ¿el código generado tiene vulnerabilidades de seguridad? ¿el agente está intentando acceder a ficheros fuera de su sandbox? ¿la respuesta contiene información alucinada o filtrada?

Estas validaciones suelen implementarse como modelos más pequeños o como chequeos basados en reglas que corren alrededor del agente principal:

User input → [input guardrail] → Agent → [output guardrail] → Action
                  ↓                              ↓
              "blocked"                      "blocked"

Resumen de límites y guardarraíles

Defensa	Lo que previene
Iteration limits	Bucles infinitos, agentes desbocados
Cost controls	Gasto sin tope
Human-in-the-loop	Acciones irreversibles o de alto riesgo
Input/output validation	Comportamiento inseguro, no autorizado o incorrecto

Los cuatro funcionan juntos como capas de defensa. Ninguno por sí solo es suficiente.

Sistemas multi-agente

Un único agente con demasiadas herramientas y responsabilidades puede confundirse o volverse poco fiable. Los sistemas multi-agente reparten el trabajo entre agentes especializados, cada uno con un rol más acotado, y los coordinan con alguno de los patrones que han ido cristalizando en el ecosistema.

Orchestrator-Worker (hub-and-spoke)

Un agente «manager» descompone la tarea y delega subtareas a agentes worker especializados.

              ┌──────────────┐
              │ Orchestrator │  ← Planifica, delega, sintetiza
              └──────────────┘
               /      |      \
              /       |       \
        ┌──────┐  ┌──────┐  ┌──────┐
        │Coder │  │Tester│  │Writer│  ← Workers especializados
        └──────┘  └──────┘  └──────┘

Handoff (sequential pipeline)

Cada agente se ocupa de su parte y pasa el control al siguiente. Es el patrón que usa el SDK de Agents de OpenAI.

Agent A ──handoff──→ Agent B ──handoff──→ Agent C
(Triage)             (Specialist)         (QA)

Collaborative (peer-to-peer)

Los agentes se comunican como pares, debatiendo o revisando el trabajo del otro. Es el patrón de CrewAI y AutoGen.

Agent A ←──messages──→ Agent B
   ▲                      ▲
   │                      │
   └──→ Agent C ←──┘

Supervisor pattern

Un agente supervisor monitoriza a los agentes worker, interviene cuando se atascan y vela por la calidad.

Retos de orquestación

Coordinar varios agentes introduce problemas que no existen en un agente individual. Conviene tenerlos identificados antes de adoptar un patrón multi-agente:

• Compartir contexto: ¿cómo comparten información los agentes sin saltarse los límites de contexto?
• Propagación de errores: si un agente falla, ¿cómo se recupera el sistema?
• Coste: cada llamada a un agente cuesta tokens. Multi-agente multiplica el coste.
• Sobrecarga de coordinación: más agentes implican más comunicación entre ellos.

El espectro: qué arquitectura de un AI agent necesita tu caso de uso

No todo es «agente» o «no agente». Existe un espectro entre una llamada LLM aislada y un sistema totalmente autónomo, con varios niveles intermedios. Esta sección recorre los dos extremos y la gradación entre ellos.

Llamada LLM simple (no agéntica)

Una llamada LLM simple es el extremo determinista del espectro: una petición, una respuesta, sin bucle ni herramientas. Por ejemplo:

User: "Explícame quicksort"
→ LLM procesa el prompt
→ LLM devuelve la respuesta
Done. Un round-trip.

• Una petición, una respuesta.
• Sin uso de herramientas.
• Sin iteración.
• Sin interacción con el entorno.
• Determinista (más o menos): la misma entrada tiende a dar la misma salida.

Workflow agéntico

Un workflow agéntico es el otro extremo: el agente itera, llama a herramientas y decide cada paso. Por ejemplo:

User: "Encuentra y arregla el bug de rendimiento en mi app"
→ El agente lee la estructura del codebase
→ El agente busca código relacionado con rendimiento
→ El agente lee ficheros concretos
→ El agente razona sobre cuellos de botella potenciales
→ El agente ejecuta una herramienta de profiling
→ El agente identifica el problema
→ El agente edita el código
→ El agente ejecuta los tests
→ El agente verifica que el fix funciona
→ El agente informa de vuelta
Done. Muchos round-trips, decisiones autónomas en cada paso.

• Múltiples iteraciones (el bucle).
• Uso dinámico de herramientas (el agente elige cuáles, cuándo y con qué argumentos).
• Adaptativo (cambia de estrategia según los resultados).
• No determinista (ejecuciones distintas pueden tomar caminos distintos).
• Puede fallar, reintentar, auto-corregirse.

El espectro de agencia

Entre los dos extremos hay una gradación:

Llamada LLM simple
        │
        ▼
LLM + salida estructurada (function calling, sin bucle)
        │
        ▼
LLM + una llamada a herramienta (RAG: retrieval-augmented generation)
        │
        ▼
LLM + bucle con herramientas (agente ReAct básico)
        │
        ▼
LLM + bucle con herramientas + planificación + memoria (agente avanzado)
        │
        ▼
Sistema multi-agente
        │
        ▼
Agente totalmente autónomo (ejecución larga, supervisión humana mínima)

La mayoría de sistemas en producción a principios de 2026 viven en el medio: bucles agénticos con uso de herramientas, pero con checkpoints humanos para las decisiones importantes.

Con estas cinco capas —protocolo de conexión, skills, guardarraíles, sistemas multi-agente y posición en el espectro— ya tienes el armazón completo de la arquitectura de un AI agent que puede aguantar producción. La tercera entrega de la serie abordará cómo se opera todo esto en el día a día: observabilidad y tracing sobre lo que hace el agente, evaluación cuando el output no es determinista, y el ciclo de mejora continua que cierra el lazo.