Tu agente AI lleva tres semanas en producción. Responde, ejecuta herramientas, encadena llamadas. Todo parece funcionar. Luego, en el día 22, falla silenciosamente: llama a una herramienta obsoleta, no encuentra contexto de sesiones anteriores, o —lo más costoso— ejecuta una acción destructiva porque el contexto que recibió era parcial y ambiguo. El equipo tarda dos días en diagnosticar el problema. El CTO exige explicaciones. El coste no es solo técnico: es de reputación interna.
Esto no es un caso hipotético. Es el patrón que más se repite en 2025-2026 cuando las empresas escalan de "demo funcional" a "agente en producción real". Y en el 80% de los casos, la causa raíz no es el modelo de lenguaje: es una integración de contexto mal diseñada. Aquí entra el Model Context Protocol (MCP) —y aquí es donde la mayoría lo está implementando mal.
💡 Pro-Tip del CTO: El error más extendido que veo en el mercado es tratar MCP como un simple "wrapper de API". Las empresas conectan sus herramientas, el agente empieza a responder, y dan el proyecto por terminado. Pero MCP no es una capa de integración: es un contrato de estado distribuido. Sin gestión explícita de ciclo de vida de contexto, sin validación de esquemas en tiempo real y sin estrategias de fallback por herramienta, estás construyendo sobre arena. El agente no falla de golpe; falla de forma gradual e invisible.
Qué es MCP y por qué importa ahora mismo
Model Context Protocol es el estándar abierto propuesto por Anthropic —y adoptado rápidamente por OpenAI, Google DeepMind y el ecosistema open-source— que define cómo un agente AI se comunica con herramientas, recursos y prompts externos de forma estructurada y con estado. 🏗️
La arquitectura central tiene tres primitivas:
- Tools: Funciones ejecutables que el modelo puede invocar (APIs, bases de datos, sistemas de archivos).
- Resources: Datos accesibles de solo lectura que el agente puede leer sin efectos secundarios (documentos, configs, esquemas).
- Prompts: Plantillas de instrucciones reutilizables y versionables que el servidor MCP expone al cliente.
La diferencia con una integración ad-hoc de funciones (function calling clásico) es que MCP introduce un servidor MCP como intermediario con estado propio, descubrimiento dinámico de capacidades y gestión del ciclo de vida de la conexión. Esto resuelve el problema de escala, pero introduce una nueva capa de complejidad que la mayoría subestima.
Los Tres Fallos Arquitectónicos Más Comunes en 2026
1. Context Poisoning por Acumulación No Controlada
Cada llamada a herramienta devuelve datos que se inyectan en el contexto del agente. Sin una política explícita de context pruning, en pocas iteraciones el contexto alcanza el límite de tokens y el modelo empieza a ignorar información crítica de las primeras rondas o a alucinar por saturación.
Solución pragmática:
- Implementar un Context Manager dedicado que evalúe relevancia por herramienta y turno.
- Usar summarization progresiva para comprimir historiales de herramientas sin perder estado.
- Establecer límites duros de tokens por herramienta (
max_tokens_per_tool_response).
2. Falta de Idempotencia en Tools Destructivas
Un agente que reintenta una herramienta fallida sin verificar si la acción ya se ejecutó parcialmente puede duplicar transacciones, enviar emails dos veces o sobrescribir datos. El MCP no garantiza idempotencia por defecto.
Solución pragmática:
- Cada tool destructiva debe implementar un idempotency key en su definición de esquema MCP.
- El servidor MCP debe mantener un log de operaciones ejecutadas en la sesión actual.
- Separar explícitamente tools de "lectura" y "escritura" en el manifest del servidor.
3. Descubrimiento Dinámico sin Validación de Esquemas en Runtime
MCP permite que el servidor actualice las tools disponibles en tiempo real. Esto es potente, pero peligroso: si el agente carga un esquema de tool desactualizado y llama a la API real con parámetros incorrectos, el fallo es silencioso en muchos setups. ⚠️
Solución pragmática:
- Forzar schema versioning en cada tool expuesta por el servidor MCP.
- El cliente MCP debe validar el hash del esquema antes de cada ciclo de ejecución.
- Implementar un health check periódico de tools críticas (no solo en el arranque).
Patrones de Resiliencia para MCP en Producción
Más allá de los fallos individuales, la resiliencia sistémica de un agente MCP en producción requiere abordar tres capas:
Capa 1 — Transport y Conectividad:
- Usar
stdiosolo en entornos locales/dev. En producción, HTTP+SSE o WebSockets con reconexión automática y backoff exponencial. - Implementar circuit breakers por servidor MCP. Si un servidor cae, el agente debe degradar gracefully (reducir capacidades) y no bloquearse.
Capa 2 — Observabilidad:
- Loguear cada llamada a tool con: timestamp, parámetros de entrada (sanitizados), respuesta, latencia y tokens consumidos.
- Integrar con OpenTelemetry para trazas distribuidas. Sin esto, depurar un agente multi-tool en producción es como depurar un microservicio sin logs.
- Establecer alertas sobre: tasa de error por tool, latencia p99 por herramienta y consumo de tokens por sesión.
Capa 3 — Evaluación Continua (Evals):
- El rendimiento de un agente MCP no es estático. Cada actualización del modelo base (GPT-5, Claude 4, Llama 4 Scout) puede cambiar cómo se interpretan los esquemas de tools.
- Mantener un eval suite de escenarios críticos que se ejecute automáticamente en cada cambio de modelo o de servidor MCP.
- Los evals deben cubrir: llamadas correctas a tools, manejo de errores, comportamiento con contexto saturado y casos de tools no disponibles.
El Coste Real de Ignorar Esto
Un agente AI que falla silenciosamente en producción no genera un error 500 que alerta a tu equipo. Genera respuestas plausibles pero incorrectas, ejecuta acciones parciales y acumula deuda técnica invisible. El coste de refactorizar una arquitectura MCP mal diseñada a los 6 meses de producción —con datos reales, usuarios reales y procesos de negocio encadenados— es entre 3x y 5x mayor que haberlo hecho bien desde el primer sprint.
Los proyectos de Agentic AI que sobreviven más de un año en producción comparten una característica: trataron la infraestructura de contexto con el mismo rigor con el que tratarían un servicio financiero. No como un experimento de laboratorio que "ya mejoraremos después".
Si este artículo te ha resultado útil, deja una reaccion ❤️ o un 🦄, guarda el post con 🔖 y compártelo con tu equipo de arquitectura. Los comentarios con casos reales de fallos en producción son bienvenidos: aprendemos más de los fracasos documentados que de los éxitos de marketing.
Sobre el autor:
Aurimas Markunas es CTO & Senior Cloud Architect especializado en sistemas distribuidos, Kubernetes, AWS, Go y Python. Dedica su día a día a la integración de inteligencia artificial en entornos de producción, huyendo del hype para construir sistemas escalables y seguros. 🔗 Conecta conmigo en LinkedIn
🚀 En Empleado Inteligente no hacemos chatbots; construimos ecosistemas de Agentic AI y automatización avanzada que operan 24/7 integrados en tu back-office.
Top comments (0)