Arquitectura de agentes IA en producción

TL;DR

ReAct single-agent funciona para el 80% de casos. No compliques antes de tiempo.
Multi-agent solo tiene sentido cuando tienes tareas con dominios distintos que requieren contexto separado.
MCP resuelve el problema de tools, pero el ecosistema es inmaduro.
La mayoría de “agentes autónomos” que ves en demos no sobreviven 24h en producción sin supervisión.

Qué funciona vs qué es marketing

La palabra “agente” se ha inflado tanto que ya no significa nada. Un chatbot con function calling no es un agente. Un wrapper de API con un system prompt largo tampoco.

Un agente es un sistema que:

Recibe un objetivo,
Planifica pasos para alcanzarlo,
Ejecuta herramientas,
Observa resultados,
Decide si continuar o parar.

Lo que ves en demos: el agente resuelve la tarea a la perfección en 3 pasos.

Lo que pasa en producción: el agente llama a la herramienta equivocada, gasta 40K tokens en razonamiento, y devuelve algo que parece correcto pero no lo es.

Patrones de arquitectura

1. ReAct (Reasoning + Acting)

El patrón más simple y más usado. El LLM piensa → actúa → observa → repite.

User: "Busca los 10 papers más citados sobre RAG en 2026"
Agent:
  Thought: Necesito buscar en Semantic Scholar
  Action: semantic_scholar_search("RAG retrieval augmented generation 2026", limit=10)
  Observation: [resultados]
  Thought: Tengo los papers. Ahora ordeno por citations y formateo.
  Action: format_results(papers, sort_by="citations")
  Observation: [resultado formateado]
  Thought: Tengo la respuesta.
  Final Answer: [lista de papers]

Cuándo usarlo: Tareas bien definidas con 1-5 pasos. La mayoría de chatbots, herramientas de investigación, procesamiento de datos.

Problemas: El modelo puede entrar en loops. Sin límite de iteraciones, un agente puede quemar tokens infinitamente.

2. Plan-and-Execute

Primero genera un plan completo, luego lo ejecuta paso a paso.

User: "Haz un análisis competitivo de modelos de código"
Agent:
  Plan:
    1. Buscar benchmarks de coding (HumanEval, SWE-bench, LiveCodeBench)
    2. Recopilar pricing de cada modelo
    3. Buscar reviews de usuarios reales
    4. Generar tabla comparativa
    5. Escribir conclusión con recomendaciones
  Execute step 1 → result
  Execute step 2 → result
  ...

Cuándo usarlo: Tareas complejas con 5+ pasos donde el orden importa. Análisis, reportes, workflows multi-step.

Ventaja sobre ReAct: No recalcula el plan en cada paso. Más predecible en coste.

3. Multi-agente

Múltiples agentes con roles distintos que colaboran.

Patrones que funcionan:

Router-Workers: Un router clasifica la tarea y la envía al agente especializado. Ejemplo: router → code_agent | research_agent | data_agent.
Drafter-Reviewer: Un agente genera, otro revisa. Iteran hasta converger. Funciona especialmente bien para código y escritura técnica.
Pipeline: Agentes en secuencia donde la salida de uno es la entrada del siguiente. Ejemplo: researcher → writer → editor.

Patrones que NO funcionan:

Debate infinito: Dos agentes “debatienendo” hasta llegar a consenso. En la práctica, convergen al primer punto medio, no al mejor.
Democracia por votación: N agentes votan. Caro y los modelos tienden a estar de acuerdo entre sí (no hay diversidad real de opinión).

MCP (Model Context Protocol)

MCP es el estándar emergente para que los agentes se conecten a herramientas. En lugar de escribir function definitions a mano, usas servidores MCP que exponen tools.

Estado actual (mayo 2026):

Anthropic lo impulsó fuerte. Claude Code y Claude Desktop lo usan nativamente.
OpenAI lo adoptó parcialmente. Codex soporta MCP.
El ecosistema de servidores MCP está creciendo pero es caótico: hay cientos, pocos están mantenidos.

Qué resuelve: Estandarizar la conexión agente→herramienta. Sin MCP, cada framework tiene su formato de tools.

Qué NO resuelve: La calidad del agente. Un agente malo con MCP sigue siendo un agente malo.

Servidores MCP útiles y mantenidos:

mcp-server-fetch — HTTP requests
mcp-server-filesystem — leer/escribir archivos
mcp-server-git — operaciones de git
mcp-server-brave-search — búsqueda web

Memoria

Context window (corto plazo)

Los modelos de 2026 tienen ventanas de contexto enormes: 128K–1M+ tokens. Pero contexto no es memoria:

Coste: meter 100K tokens de contexto en cada llamada es caro.
Atención: el modelo no “recuerda” todo igual. La información en medio del contexto se pierde (lost in the middle).
Práctico: hasta ~30K tokens funciona bien. Más de eso, empieza a degradarse.

Vector DB (largo plazo semántico)

Almacenas embeddings de conversaciones/documentos y recuperas lo relevante. Funciona para RAG pero no para estado de agente:

Los embeddings capturan similitud semántica, no causalidad.
Un agente que “recuerda” que hiciste X ayer no necesariamente entiende POR QUÉ lo hiciste.

Memoria estructurada (lo que funciona)

Guarda hechos, preferencias y estado en formato estructurado (JSON, SQLite):

{
  "user_preferences": { "language": "es", "detail_level": "technical" },
  "session_state": { "current_task": "analisis_competitivo", "step": 3 },
  "learned_facts": ["usuario prefiere tablas sobre listas"]
}

Esto es lo que usan los agentes que realmente funcionan en producción: Hermes, Claude Code, Cursor.

Evaluación

¿Cómo sabes si tu agente funciona? Esta es la pregunta más difícil.

Métodos que funcionan:

Task completion rate: ¿El agente completó la tarea? Sí/No. Mide con un dataset de test.
LLM-as-judge: Otro LLM evalúa la calidad de la respuesta. Funciona si el juez es mejor modelo que el agente.
Human evaluation: Lo más fiable. Lo más lento. Resérvalo para cambios de arquitectura, no para cada iteración.

Métodos que no funcionan:

“Se ve bien”: subjetivo y escala mal.
Benchmarks académicos: MMLU, HumanEval no reflejan tareas de agentes reales.

Métricas que importan en producción:

Latencia p95 (no media)
Coste por tarea completada
Tasa de error (tool failures, timeouts)
Token usage por task
User satisfaction (si tienes feedback loop)

Producción

Cost control

Sin límites, un agente puede quemar $100 en minutos:

Max iterations: Siempre. 10-15 es razonable.
Max tokens per turn: Limita el razonamiento del modelo.
Budget per task: “Esta tarea no puede costar más de $0.50”.
Caching: Si el agente hace la misma sub-consulta dos veces, cachea el resultado.

Latencia

Un agente con 5 pasos, cada uno esperando al LLM: 5 × 2s = 10s mínimo. Con tool execution, 15-30s es normal.

Paraleliza tools independientes.
Usa modelos rápidos para pasos simples (routing, formatting).
Streaming parcial para que el usuario vea progreso.

Error handling

Los agentes fallan. Mucho. Planifica para ello:

Retry con backoff: Tools fallan por rate limits. Reintenta.
Fallback tools: Si la API de X no responde, usa Y.
Graceful degradation: Si el agente no puede completar la tarea, devuelve lo que tiene con contexto de qué falló.

Observabilidad

Necesitas logs de:

Cada paso del agente (thought → action → observation)
Tool calls (entrada, salida, latencia)
Token usage por paso
Errores y retries

Sin esto, debuguear un agente es imposible.

Lo que está sobrevalorado

Agentes 100% autónomos: Ningún agente serio en producción funciona sin supervisión humana para tareas complejas. Los que lo hacen están limitados a dominios estrechos.
Swarm de agentes: 20 agentes “colaborando” suena genial. En la práctica, la latencia se multiplica, el coste se dispara, y la calidad no mejora.
Agentes que “aprenden” solo con observación: Necesitas feedback explícito. Un agente no mejora solo porque se ejecuta muchas veces.

Lectura relacionada

Para la mayoría de casos de uso en 2026:

Usuario → Router (clasifica intención)
  ├→ Simple task → LLM directo (no agente)
  ├→ Single-agent ReAct + MCP tools
  └→ Complex task → Plan-and-Execute con subagentes especializados

Regla práctica: empieza con ReAct simple. Añade complejidad solo cuando tengas evidencia de que lo simple no basta.

Fuentes: OpenAI Agents SDK docs, Anthropic MCP spec, LangGraph documentation, experiencia propia con agentes en producción.