Construiste un agente. Lo probaste en tu laptop. Funcionó — hasta bonito, la verdad. Así que lo pusiste en producción como se desplegaban sitios web en 2003: editar el archivo en el servidor, guardar, rezar.

Entonces a las 2 AM, tu agente empieza a alucinar llamadas a herramientas, mandando correos a gente que nunca pidió correos, y quemando tu presupuesto de API como marinero borracho en puerto. Buscas el botón de rollback. No hay botón de rollback. No hay versión anterior. Tu agente no tiene versiones — es un system prompt en un campo de texto, un par de configs de herramientas, y lo que sea que tengas en la cabeza.

Bienvenido al deploy de agentes en abril de 2026.

Las Plataformas Salieron. Los Pipelines No.

Entre el 8 y el 22 de abril, los tres hyperscalers lanzaron sus plataformas de agentes uno tras otro: Managed Agents de Anthropic (8 de abril) con sandboxes hosteados y un CLI ant, el Agents SDK v0.14 de OpenAI (15 de abril) con seis point releases en diez días, y el ADK 1.0 de Google presentado en Cloud Next (22 de abril) con SDKs multi-lenguaje y un dashboard de monitoreo. Ya cubrimos las comparaciones de features antes. Lo que ninguno lanzó: disciplina de deploy.

Como lo puso la comparación de xpander.ai el 24 de abril: "Lo que no ofrecen: portabilidad multi-cloud, CI/CD nativo para agentes, versionado, rollback ni deploys canary." Todos los hyperscalers calificaron como "DIY" en ciclo de vida de agentes.

Para ser justos, Anthropic fue el que más se acercó — el CLI ant promete promoción de staging a producción. Pero su propio post de ingeniería tiene cero menciones de rollback, deploys canary o switching blue-green. El versionado existe; la disciplina de deploy no.

Por Qué los Agentes Rompieron CI/CD

CI/CD — integración continua y despliegue continuo — es como se despliega software normal. Tienes un artefacto deployable (una imagen Docker, un binario compilado), lo pruebas en staging (una copia segura de producción), le haces canary (mandas el 5% del tráfico a la versión nueva), y si se rompe, haces rollback con un solo comando.

Los agentes no tienen un solo artefacto. El comportamiento de un agente vive en al menos cuatro superficies:

# Superficie 1: Código (versionado en git)
agent = Agent(model="claude-sonnet-4", tools=[search, email, calendar])

# Superficie 2: System prompt (frecuentemente editado en un dashboard, no en git)
SYSTEM_PROMPT = "Eres un asistente de agendamiento que..."

# Superficie 3: Configs de herramientas (permisos, rate limits, API keys)
# Superficie 4: Memoria / contexto aprendido (vive... en algún lado)

El system prompt y las descripciones de herramientas son los componentes más críticos para el comportamiento, pero viven fuera del control de versiones por defecto. Simon Willison lo demostró el 18 de abril construyendo manualmente un historial de Git con fechas de commit falsas solo para rastrear cambios en prompts — haciendo ingeniería inversa de un versionado que debería ser una feature de la plataforma.

Como los propios Anthropic reconocieron: "Desplegar un agente de grado productivo requiere que los equipos de software construyan no solo el agente en sí, sino también una cantidad significativa de scaffolding."

La Era del Tape de Ductos

Existen workarounds. Puedes versionar tus archivos de prompt en git. Puedes hacer blue-green swap manualmente. Puedes poner feature flags en tu lista de herramientas. Aquí va el "versionado de agentes" mínimo viable:

# Versionado de agente del pobre
agent_config = {
    "version": "1.4.2",
    "prompt_sha": "a3f8c1d",  # hash de git del archivo de prompt
    "tools": ["search_v2", "email_v1"],
    "permissions": {"email": {"max_per_hour": 10}},
    "model": "claude-sonnet-4",
}
# Deploy: cargar config → validar → cambiar tráfico
# Rollback: cargar config anterior → cambiar de vuelta

Pero esto es tape de ductos que requiere disciplina que ninguna plataforma te obliga a tener. Y se desmorona en el momento en que la memoria del agente — contexto aprendido acumulado entre sesiones — entra en escena. No puedes hacer rollback de lo que un agente recuerda.

¿Qué tan mal puede ponerse? Un post-mortem de Reworkd de marzo de 2026 documentó cómo un solo deploy de prompt malo disparó 14,000 llamadas erróneas a la API en 47 minutos — $2,300 dólares en tokens antes de que alguien se diera cuenta. Sin canary. Sin rollback. Solo una alerta de Slack que llegó demasiado tarde. Multiplica eso por los miles de equipos que ahora construyen agentes sin guardarraíles de deploy, y empiezas a ver la forma del problema.

Lo Que Deberías Hacer Ahora Mismo

Si estás construyendo agentes hoy: trata cada prompt, config de herramienta y política de permisos como infrastructure-as-code. Mantenlos en control de versiones. Nunca actualices un agente de producción sin probar una copia en staging primero. Presupuesta tiempo para construir la plomería de deploy que tu proveedor de plataforma se saltó. Esto no es opcional — es la diferencia entre un demo y un producto.

La Capa Que Falta

Recuerda, empezaste este viaje editando un archivo en un servidor. Ahí es exactamente donde están los agentes ahora — la era pre-Docker de "en mi máquina sí jala". La plataforma que lance CI/CD de agentes como primitiva por defecto — staging, canary, rollback, con el agente como artefacto versionable — captura la capa operacional que está por encima de la calidad del modelo y la cantidad de herramientas. Ese es el verdadero premio, y al 26 de abril de 2026, nadie lo ha reclamado todavía.