Agentic DevOps: por qué creo que los servidores MCP son la abstracción correcta

El LLM es el cerebro. Las herramientas son las manos. El runtime es lo que evita que el agente se haga daño a sí mismo, y a ti. Aprendí esto después de que un agente tomara una decisión que no pude explicar ni reproducir.

He estado pensando mucho sobre runtimes agenticos mientras experimento con servidores MCP y motores de workflow. El término lo usan los vendedores, pero la idea es útil: un runtime es la capa que gestiona el ciclo de vida, estado, herramientas y permisos de un agente.

Construí un agente sin un runtime. Era un script de Python que llamaba a una API de LLM, parseaba la respuesta, y ejecutaba comandos de shell. Funcionaba para tareas simples. Luego tomó una decisión que no entendí. Borró un archivo temporal que resultó ser importante. No tenía logs de por qué tomó esa decisión. No tenía traza del razonamiento. No pude reproducir el incidente. Fue entonces cuando me di cuenta de que necesitaba un runtime.

Este post es mi modelo mental para esa capa. Está basado en algo que construí, algo que se rompió, y algo que estoy reconstruyendo con mejores fundamentos.

Qué hace un runtime agentico

Como mínimo, un runtime necesita manejar:

• Ciclo de vida: iniciar, pausar, reanudar, detener una sesión de agente.
• Ejecución de herramientas: ejecutar herramientas de forma controlada.
• Estado: recordar contexto entre turnos.
• Seguridad: reforzar permisos en cada acción.
• Observabilidad: registrar lo que el agente hizo y por qué.

Sin estos, un agente es solo una llamada a LLM con ambición. Con ellos, se convierte en algo que puedes ejecutar en producción sin contener la respiración. Contuve la respiración mucho antes de entender esto.

Los cinco componentes de los que realmente me importan

1. Gestor de ciclo de vida

Una sesión de agente no debería ser una petición de disparar y olvidar. Es un proceso de larga duración que puede pausarse para aprobación humana, reanudarse después de un reinicio, o detenerse limpiamente.

Mi primer agente era un script. Ejecutaba, tomaba decisiones, y salía. No había pausa. No había reanudación. No había apagado. Si quería detenerlo, presionaba Ctrl-C. Si estaba en medio de algo importante, mala suerte.

Ahora uso Temporal para gestión de ciclo de vida. Un workflow de agente puede pausarse, reanudarse, e inspeccionarse. Si algo sale mal, puedo ver exactamente dónde estaba y qué estaba haciendo. Esto no es un lujo. Es un requisito para cualquier cosa que toque producción.

2. Sandbox de herramientas

Las herramientas son la parte más riesgosa de cualquier agente. Ejecutar comandos de shell, consultar APIs, o modificar infraestructura desde un bucle de LLM es peligroso.

Mi primer agente no tenía sandbox. Ejecutaba comandos de shell directamente. El LLM dijo “borra temp.txt” y el agente borró temp.txt. No verificó si temp.txt era realmente temporal. No pidió aprobación. Solo ejecutó el comando.

Un runtime debería ejecutar herramientas con:

• Listas de permiso explícitas. Solo herramientas pre-aprobadas pueden ejecutarse.
• Timeouts. Una herramienta que se cuelga no debería colgar al agente.
• Defaults de solo lectura. El agente no debería escribir a menos que se le permita explícitamente.
• Aislamiento por llamada. Un fallo de herramienta no debería caer al agente.
• Filtrado de salida. La salida de la herramienta debería ser sanitizada antes de llegar al LLM.

Prefiero rechazar una llamada de herramienta válida que permitir una destructiva por accidente. Aprendí esto después del incidente de temp.txt.

3. Persistencia de estado

Los agentes necesitan memoria. Eso significa historial de conversación, resultados intermedios, y hechos de largo plazo.

Mi primer agente no tenía persistencia. Ejecutaba en memoria. Si el script se reiniciaba, la conversación se perdía. Si quería referirme a algo de hace diez minutos, tenía que incluirlo en el prompt. La ventana de contexto se llenaba rápido.

Ahora separo el estado en tres buckets:

• Contexto a corto plazo: La conversación actual. Almacenada en Redis con TTL de 1 hora.
• Resultados intermedios: Salidas de llamadas de herramientas. Almacenados en el estado del workflow (Temporal).
• Memoria a largo plazo: Hechos sobre el entorno, preferencias, patrones aprendidos. Almacenados en un almacén simple de clave-valor.

El runtime decide cómo se almacena y recupera ese estado. Una versión simple usa una base de datos. Una versión más inteligente separa el contexto a corto plazo de la memoria a largo plazo y gestiona límites de ventana de contexto explícitamente. Todavía no estoy en la versión más inteligente. Pero estoy más allá de la versión “sin persistencia”.

4. Frontera de seguridad

El runtime refuerza quién es el agente, qué puede hacer, y qué puede ver. Esto incluye autenticación, autorización, auditoría de logs, e inyección de secretos.

Mi primer agente no tenía frontera de seguridad. Ejecutaba como mi usuario. Tenía mis permisos. Podía ver todo lo que yo podía ver. Si se comprometía, el atacante tenía mi acceso.

Ahora ejecuto agentes con cuentas de servicio dedicadas. El agente tiene su propio ServiceAccount de Kubernetes, sus propias reglas RBAC, y su propio rol de Vault. Solo puede acceder a los namespaces y secretos que yo permito explícitamente. Cada llamada de herramienta se registra con la identidad del agente, el nombre de la herramienta, y los argumentos.

Cada llamada de herramienta debería ser atribuible. Si algo sale mal, quiero saber exactamente qué prompt llevó a qué acción. El incidente de temp.txt no fue atribuible. Sabía que el archivo fue borrado, pero no sabía qué respuesta del LLM lo causó.

5. Colector de observabilidad

No puedes depurar un agente solo por su respuesta final. Necesitas trazas del bucle de razonamiento, logs de llamadas de herramientas, métricas de latencia y costo, y atribución de costo por sesión.

Mi primer agente no tenía observabilidad. Imprimía a stdout. Si quería saber qué pasó, leía la salida del terminal. Si el terminal se cerraba, el historial se perdía. Si el agente tomaba una mala decisión, no tenía forma de entender por qué.

Ahora recojo:

• Trazas: El bucle de razonamiento completo, incluyendo cada llamada a LLM, cada llamada de herramienta, y cada decisión.
• Logs: Logs estructurados de llamadas de herramientas con argumentos y salidas.
• Métricas: Latencia por llamada de herramienta, costo por sesión, uso de tokens por llamada a LLM.
• Atribución de costo: Cuánto cuesta cada sesión de agente. Esto me mantiene honesto sobre el gasto de API.

Sin observabilidad, los agentes son cajas negras. Con ella, son solo sistemas distribuidos complejos, lo cual es suficientemente malo. El incidente de temp.txt habría sido depurable si hubiera tenido trazas. No las tenía. Ahora sí.

Runtime vs Framework

Lo pienso así:

• Un framework como LangGraph o CrewAI te ayuda a definir agentes.
• Un runtime mantiene esos agentes ejecutándose de forma segura.

Algunos productos difuminan la línea. Eso está bien. Lo que importa es si las preocupaciones de producción están manejadas, no cómo se llama el producto.

Mi primer agente no usaba framework ni runtime. Era un script. Mi agente actual usa LangGraph para el framework y Temporal + MCP + observabilidad personalizada para el runtime. El framework me ayuda a definir el agente. El runtime lo mantiene seguro.

Conclusión

Un runtime agentico no es una sola herramienta. Es un conjunto de responsabilidades. Gestión de ciclo de vida, sandboxing de herramientas, persistencia de estado, fronteras de seguridad, y observabilidad.

Si estás construyendo agentes, empieza decidiendo cómo manejarás esas cinco cosas. La elección de LLM es secundaria. Pasé meses optimizando mis prompts de LLM mientras mi agente no tenía runtime. Eso estaba al revés. El incidente de temp.txt me enseñó que un buen runtime con un LLM mediocre es más seguro que un mal runtime con un gran LLM.

Estoy reconstruyendo mi agente con estos cinco componentes. Es más lento de construir. Es más complejo. Pero es algo que puedo ejecutar sin contener la respiración. Y esa es la meta.