Desplegaste agentes autónomos este mes. Crean pull requests, actualizan tickets de proyecto, pushean configuraciones a producción y disparan notificaciones en Slack — todo mientras duermes. El pitch: delega lo tedioso, despierta con una lista de tareas completadas.
El problema: los agentes la cagan. No de vez en cuando — el estudio MAST de UC Berkeley, publicado en marzo de 2025, midió tasas de fallo del 41% al 86.7% en siete sistemas multi-agente de última generación. Y a diferencia de un chatbot que alucina una respuesta incorrecta que puedes regenerar, el error de un agente es un commit mergeado, un ticket de Jira creado, un mensaje enviado. Acciones reales en sistemas reales. No puedes "regenerar" una config deployada.
Entre el 8 y el 17 de abril, las tres plataformas principales lanzaron runtimes autónomos. El 8 de abril, Anthropic lanzó Managed Agents — sandboxing, persistencia de estado, recuperación de errores (o sea: reanudar después de un crash). El 14 de abril, Anthropic agregó Routines — agentes corriendo en su nube, disparados por schedules o webhooks. El 15 de abril, OpenAI lanzó Agents SDK v0.14 con ejecución sandboxed y "snapshotting" — recuperación del estado del contenedor después de fallos. El 17 de abril, Google lanzó Agent Development Kit (ADK) con gestión de estado a nivel de sesión y orquestación multi-agente. Tres plataformas, cero primitivas de rollback — mecanismos que te permitan revertir lo que un agente hizo después de que terminó de hacer la cosa mal.
Escribí sobre la brecha del checkpoint la semana pasada — las plataformas resolviendo la recuperación de crashes a mitad de ejecución. Ese es el problema fácil. Tu agente murió a mitad de tarea, la plataforma restaura su estado, el agente lo intenta de nuevo. Bien. Pero acá está el escenario que nadie resuelve: tu agente completó exitosamente. Corrió hasta el final, reportó checkmarks verdes, y el resultado es basura. El PR mergea lógica rota. El ticket de Jira duplica uno existente. La página de Notion sobreescribe datos correctos con datos alucinados. El agente no crasheó — terminó mal con total confianza.
Cuando un agente mergea un pull request malo, crea tareas duplicadas en Asana, o pushea una página rota de Notion, esto es lo que pasa: tú — el humano — tienes que identificar manualmente cada acción que el agente tomó, rastrear sus efectos downstream (¿otro agente reaccionó al PR malo? ¿se disparó un webhook?), y revertirlas una por una. Esta limpieza escala linealmente con el número de acciones tomadas. Más autonomía significa más desastre que limpiar.
¿Por qué no existe rollback nativo? Dos razones. Primera, la reversibilidad requiere semántica transaccional — acciones compensatorias, llaves de idempotencia, journals de acciones. Las herramientas subyacentes — GitHub, Linear, Slack, Notion — no exponen estas primitivas a los agentes. Tu plataforma de agentes no habla "deshacer" porque las herramientas que llama tampoco hablan "deshacer". Segunda — y esta es la parte que nadie dice en voz alta — no hay incentivo de negocio. Cada acción del agente es una llamada a API facturable. Cada re-ejecución después de un rollback fallido es otra sesión facturable. Los vendors de plataformas lucran con la ejecución append-only. Construir undo significa construir una razón para que los clientes usen menos ciclos de cómputo. Nadie se ofrece voluntariamente a ese modelo de ingresos.
Entran los vendors de backup, llenando alegremente el vacío que las plataformas de agentes se niegan a llenar. El 14 de abril, Commvault lanzó AI Protect — marketizado literalmente como "Ctrl+Z para agentes de IA rebeldes." Mapea el radio de impacto de una sesión de agente, aísla los cambios causados por agentes de los cambios humanos, y habilita la reversión selectiva. Como dijo Pranay Ahlawat, CTO de Commvault: "En entornos agénticos, los agentes mutan estado a través de datos, sistemas y configuraciones de formas que se componen rápido y son difíciles de rastrear." La ironía es tan espesa que se corta con cuchillo: tu proveedor de plataforma de IA no va a construir undo porque afecta sus márgenes; tu vendor de backup sí, porque la incompetencia de tu agente es su mercado direccionable. Dos puntos ciegos, un desastre extremadamente rentable.
La ecuación de productividad de agentes necesita una actualización. Si incluso el 30% de las ejecuciones autónomas requieren reversión manual — y la reversión toma más tiempo que la tarea original — el ROI neto se vuelve negativo para ese workflow. Ahorraste 10 minutos en el happy path y gastaste 40 minutos limpiando el sad path.
La primera plataforma que lance agent.rollback(session_id) gana la confianza enterprise. No porque las empresas necesiten agentes que nunca fallen — todo falla — sino porque necesitan agentes cuyos fallos cuesten menos de lo que sus éxitos ahorran. Hasta entonces, cada plataforma de agentes es append-only: puede hacer cosas, pero no puede des-hacerlas. Tu asistente autónomo no tiene tecla de borrar.
