Estado en Redis, contenedores personalizados y MCP: la capa que falta en el despliegue de agentes en producción

La trampa del prototipo

Si has seguido nuestras guías anteriores — empezar con LangChain, Ollama y Mistral, y la comparación de frameworks LangGraph vs. LangChain — ya sabes cómo levantar un agente en local. Has visto cómo orquestar agentes MCP con CrewAI. Puede que incluso hayas diseñado una arquitectura RAG para IA + Web3.

Lo que ninguno de esos patrones resuelve es el momento en que tu agente tiene que salir de tu portátil.

En ese punto, tres problemas aparecen simultáneamente:

1. El estado desaparece cuando el proceso se reinicia
2. El escalado se rompe porque cada réplica mantiene su propia conversación
3. La integración de herramientas se fragmenta a medida que cableas a mano cada servicio externo

MCP, Docker y Redis resuelven cada uno uno de estos problemas. Juntos, forman el patrón de despliegue que convierte un prototipo en infraestructura.

---

Problema 1 — El estado no tiene dónde vivir

LangGraph es explícito al respecto: los agentes son grafos con estado. Cada transición de nodo, cada llamada a herramienta, cada paso intermedio de razonamiento es estado que debe sobrevivir a la siguiente invocación.

En modo prototipo, ese estado vive en memoria. En producción, un estado en memoria significa:

• Un reinicio del contenedor borra la conversación
• Dos réplicas detrás de un balanceador producen dos conversaciones divergentes
• Los flujos de trabajo largos no pueden pausarse ni reanudarse

La respuesta de LangGraph es un checkpointer — una capa de persistencia externa que serializa el estado en puntos definidos. Postgres es la referencia por defecto. Redis es la opción a la que llegan la mayoría de los equipos cuando el throughput se convierte en un problema.

Por qué Redis concretamente:

• Lecturas y escrituras en sub-milisegundo para operaciones de checkpoint
• Semántica TTL para que el estado efímero de las conversaciones se autolimpie
• Notificaciones Pub/Sub que permiten a los workers distribuidos reaccionar a los cambios de checkpoint en tiempo real
• Streams para el traspaso entre agentes y el event sourcing
• Clustering que encaja con los patrones de despliegue en contenedores

Si has leído nuestro artículo sobre arquitectura IA + Web3 + RAG, ya sabes cómo el contexto de recuperación se integra en el prompt. Redis es donde ese contexto, el estado de la conversación y la memoria de trabajo del agente viven todos — recuperables en el mismo ciclo de petición.

---

Problema 2 — Los contenedores te dan aislamiento, no estado

Docker resuelve el problema del empaquetado. No resuelve el problema del estado.

Un contenedor personalizado te da:

• Runtime reproducible
• Límites de recursos por servicio
• Aislamiento de red
• Despliegue estándar OCI

Lo que no te da es persistencia de estado. Mata el contenedor, el estado desaparece. Escala a tres réplicas, tres estados independientes.

La corrección es arquitectónica: el estado vive fuera del contenedor, indexado por thread ID, en Redis. Cualquier réplica puede retomar cualquier conversación. Reinicia el contenedor a mitad de un flujo de trabajo y el agente reanuda desde el último checkpoint.

Es el mismo patrón que describimos en la guía de chatbot CrewAI MCP cuando varios agentes necesitan coordinarse — la capa de estado compartida es lo que permite que los traspasos funcionen de forma fiable.

---

Problema 3 — La integración de herramientas no se estandariza sola

Aquí es donde entra MCP en la conversación.

El Model Context Protocol es un estándar abierto para exponer herramientas, fuentes de datos y prompts a aplicaciones LLM mediante una interfaz JSON-RPC coherente. Su arquitectura separa:

• Host — tu aplicación
• Clients — conectores dentro del host
• Servers — servicios que exponen herramientas y recursos

El detalle operativo importante que la mayoría de las explicaciones de MCP omiten: los servidores MCP se despliegan habitualmente como contenedores Docker.

No es casual. Contenerizar los servidores MCP es lo que hace viable el patrón en entornos empresariales:

El MCP Gateway de Docker va más allá centralizando secretos, autenticación y políticas en cada conexión MCP.

Si has seguido la guía de CrewAI + MCP, esta es la mitad de despliegue de lo que construiste.

---

La arquitectura de referencia

┌─────────────────────────────────────────────────────────────┐
│                    MCP Host (Your Application)              │
│                    MCP Clients (Connectors)                 │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│              Docker Container Runtime                       │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────┐ │
│  │  MCP Server A   │  │  MCP Server B   │  │  LangGraph  │ │
│  │  (Tool Provider)│  │  (Data Source)  │  │   Agent     │ │
│  └────────┬────────┘  └────────┬────────┘  └──────┬──────┘ │
└───────────┼────────────────────┼───────────────────┼────────┘
            │                    │                   │
            ▼                    ▼                   ▼
┌─────────────────────────────────────────────────────────────┐
│                    Redis State Layer                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐  │
│  │  Checkpoints │  │  Agent Memory│  │  Pub/Sub Events  │  │
│  │  (TTL)       │  │  (Semantic)  │  │  (Coordination)  │  │
│  └──────────────┘  └──────────────┘  └──────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Cada componente resuelve un problema distinto. Ninguno resuelve los tres.

---

Qué significa esto para tu pipeline de despliegue

Tres preguntas de adquisición que esta arquitectura responde con claridad:

«¿Dónde viven nuestros datos?» Instancia de Redis que tú controlas, con políticas TTL, cifrado en reposo y pistas de auditoría.

«¿Cómo escala esto?» Escalado horizontal de contenedores con estado compartido en Redis. Sin afinidad de sesión requerida. Cualquier réplica puede servir cualquier conversación.

«¿Qué pasa cuando se rompe?» El estado persiste a través de los reinicios de contenedores. Pub/Sub expone los cambios de checkpoint para monitorización en tiempo real. Los flujos de trabajo fallidos se reanudan desde el último checkpoint en lugar de empezar de cero.

---

Cuándo este patrón es adecuado — y cuándo no

Usa agentes contenerizados con Redis cuando:

• Las conversaciones abarcan varios turnos o sesiones
• Necesitas escalado horizontal detrás de un balanceador
• Los traspasos multi-agente requieren estado compartido
• La integración de herramientas se expone vía MCP

Considera estado respaldado por Postgres cuando:

• Necesitas auditabilidad a largo plazo de cada decisión del agente
• Las consultas relacionales sobre el historial del agente importan más que la latencia

Enfoque híbrido: Redis para estado caliente, Postgres para archivado. La mayoría de los sistemas en producción convergen aquí.

---

Dónde entra Quopa

Los cuatro artículos enlazados arriba cubren los bloques de construcción. El hueco es el despliegue.

Ayudamos a los equipos a pasar de prototipo a producción con:

• Diseño de capa de estado respaldada por Redis para agentes LangGraph, LangChain y CrewAI
• Empaquetado de contenedores personalizados incluyendo despliegue de servidores MCP
• Arquitectura de integración conectando RAG, contexto Web3 y herramientas empresariales a través de una única fábrica de estado

Si has superado la fase de prototipo y el problema del estado ha aparecido, esa es la conversación que hay que tener ahora — no después del primer incidente en producción.

Háblanos de despliegue de agentes de nivel producción →

---