Arrancas un agente de seis horas un martes en la noche. Se supone que va a scrapear la página de precios de un competidor, triar cuarenta tickets viejos en Linear, y correr un dry-run de migración en Postgres mientras duermes. El dashboard dice "autónomo". El marketing dice "long-horizon". Tu tarjeta de crédito dice "bueno, ya qué". Cierras la laptop.

Te despiertas con una tarea a medio hacer, tres tickets duplicados en Linear firmados a tu nombre, y un canal de Slack lleno de preguntas de un compañero que pensó que tú estabas despierto a las 3 a.m. El agente crasheó en la hora cuatro. Nadie —ni tú, ni el vendor— te puede decir si darle clic a "resume" va a duplicar el desastre o arreglarlo.

Bienvenido a abril de 2026, el mes en que los agentes multi-hora se volvieron una métrica de precios antes de ser una garantía de confiabilidad 😹.

Ocho días, tres modelos de persistencia, cero estándares

Entre el 8 y el 15 de abril, los dos vendors más grandes de agentes lanzaron tres formas distintas de mantener un agente de IA vivo más allá de la hora —y ninguna se pone de acuerdo en qué significa "vivo".

El 14 de abril, Anthropic lanzó Claude Code Routines —ejecuciones de agente agendadas o disparadas por webhook, en research preview, encerradas detrás de topes diarios (5/día en Pro, 15/día en Max, 25/día en Team y Enterprise). Intervalo mínimo de agenda: una hora. The Register, muy educadamente, lo llamó "cron jobs medianamente ingeniosos" 😼.

El 15 de abril, OpenAI lanzó Agents SDK v0.14.0 con una nueva superficie SandboxAgent, un backend de sandbox plugueable (Docker, E2B, Modal, Vercel, Cloudflare —escoge el que quieras), y una cosa llamada MEMORY.md —un archivo markdown literal que el agente se escribe a sí mismo entre corridas.

Y el 8 de abril, Anthropic ya había lanzado Managed Agents, que mide el uso en session-hours —una unidad de facturación que asume explícitamente que tu agente va a correr por horas seguidas.

Tres modelos de persistencia. Cero interoperabilidad. Bienvenido a la autonomía long-horizon.

Qué está guardando realmente cada vendor

Un desvío rápido —porque "el agente recuerda" suena simple, y no lo es.

Un agente es un loop: el LLM (large language model —el cerebro detrás de ChatGPT o Claude) lee una tarea, llama a una herramienta (búsqueda web, comando de shell, llamada a API), lee el resultado, decide qué hacer después. Un agente long-horizon es ese loop, corriendo por horas. Un checkpoint es un snapshot guardado del estado del loop, para que si el proceso crashea, puedas reanudar desde el snapshot en lugar de empezar de cero.

Aquí está lo que cada vendor realmente guarda:

  • Anthropic Routines — guarda la conversación y el plan dentro de una sesión. Según los docs, "cada evento de GitHub que haga match inicia una sesión nueva" —las sesiones ni siquiera comparten estado entre triggers. Y: "los eventos que excedan el límite se descartan hasta que la ventana se resetee" —lo que significa que un pico de webhooks pierde trabajo en silencio, sin cola, sin reintento 🙀.
  • OpenAI Sandbox Agents — guarda un archivo MEMORY.md dentro del filesystem del sandbox. Los propios docs de OpenAI dicen que "destila lecciones en archivos legibles en lugar de preservar el estado completo del workspace". En cristiano: recuerda lo que aprendió, no lo que hizo. ¿Lo mataron a media git push? El plan sobrevive. El commit a medio empujar no.
  • Anthropic Managed Agents — factura por session-hour. Qué checkpointea un session-hour está sin documentar.

Ninguno de ellos —ninguno— documenta qué pasa con los side-effects cuando una corrida crashea. Un side-effect es cualquier cosa que el agente tocó fuera de su propia memoria: una llamada a API disparada, un ticket en Linear creado, una fila insertada en tu base de datos, un mensaje de Slack enviado, un git commit empujado. Esas cosas no se rebobinan.

El "ajá" que nadie puso en la landing page

Aquí está la parte silenciosa dicha en voz alta: cuando un agente multi-hora crashea y reanuda, el checkpoint restaura la intención del agente, no el estado del mundo sobre el que el agente estaba actuando.

Tu agente creó un ticket en Linear en la hora tres. Crasheó en la hora cuatro. El checkpoint de la hora 3.5 no sabe que el ticket existe. Reanudar: crea el ticket otra vez. Felicidades, tienes duplicados —y según los docs de Anthropic, "los tickets de Linear… usan tus cuentas vinculadas", así que los duplicados están a tu nombre. Tus compañeros creen que tú les estás haciendo spam 😾.

Esto no es un bug. Es la arquitectura. El análisis de The New Stack sobre las release notes de OpenAI señala que el harness "puede mantener auth, billing, audit logs, human review, y recovery state fuera de cualquier contenedor individual" —lo cual es cierto, y también es una forma educada de decir que el SDK tiene opiniones sobre su propio estado y ninguna sobre el tuyo.

Vertex Agent Engine de Google, para que conste, ya tenía Sessions y Memory Bank en GA desde diciembre de 2025; abril de 2026 solo agregó un preview de Agent Designer. Así que nadie —ni Anthropic, ni OpenAI, ni Google— te resuelve la idempotencia de side-effects.

El precio que nadie puso en la página de precios

La idempotencia —la propiedad de que hacer algo dos veces tiene el mismo efecto que hacerlo una— es ahora enteramente tu problema. Cada llamada a herramienta que tu agente haga hacia el mundo exterior necesita una idempotency key (un ID único por operación, para que el servicio receptor pueda deduplicar reintentos). Cada acción externa necesita un outbox con journal (un log que escribes antes de la acción, para saber qué intentaste aun si crasheas antes de confirmar que salió bien).

Los re-runs cuestan el doble: doble de tokens (los pedacitos de palabra que procesa el LLM, facturados por millón), doble de session-hours, doble del wall-clock que esperaste. Y como ningún vendor ofrece un formato portable de checkpoint, no puedes failover de Anthropic a OpenAI a media tarea. Estás amarrado por la forma de tus bug reports.

El thread de Hacker News sobre Routines lo dijo sin rodeos: "No voy a construir mi negocio sobre cosas que no puedo replicar yo mismo". Otro comentarista apuntó que debuggear una rutina multi-hora sería "enloquecedor". Correcto en ambos casos 🐈‍⬛.

Si vas a mandar esto a producción

Si estás corriendo agentes más allá de la hora en abril de 2026, el checkpoint de la plataforma no es tu historia de recovery. Es un recibo. Necesitas tres cosas que los vendors no construyeron por ti:

  1. Un outbox con journal — cada side-effect externo escribe a un log antes de ejecutar, para que el replay sepa qué intentó el agente.
  2. Idempotency keys en cada llamada a herramienta — GitHub, Linear, Slack, tus propias APIs. Sin excepciones.
  3. Una UI de reanudación manual — para que un humano decida si reintenta, saltea, o aborta después de un crash. No el agente. No el vendor.

Qué cambió realmente este mes

"Los agentes corren por horas" se volvió una unidad de precios en abril de 2026. La plomería debajo sigue en escala de quince minutos. En algún momento del próximo trimestre, una empresa va a escribir el primer post-mortem público sobre un managed agent que nadie pudo rebobinar —y la pregunta interesante no va a ser qué vendor falló, sino por qué alguien pensó que el checkpoint era la garantía 😸.

El consejo del gato: corre tu propio outbox. No confíes en el botón de "resume" de ningún vendor. Y si un sales deck dice "autónomo", pídeles que te definan la palabra por escrito.