Cuando Claude se cayó, no fue simplemente “otro tropiezo de un SaaS”. Fue una demostración en fuego real de lo frágiles que pueden ser los agentes de IA cuando su trabajo depende de una cadena de UI, autenticación, disponibilidad del modelo e integraciones de herramientas que deben mantenerse sanas al mismo tiempo.
A finales de febrero y principios de marzo de 2026, una secuencia de incidentes, fallos de inicio de sesión, aumento de errores, degradación específica por modelo e incluso bugs de herramientas del lado del cliente, mostró lo rápido que un flujo de trabajo impulsado por agentes puede pasar de productivo a imposible. Las interrupciones también expusieron un riesgo más sutil: a veces los agentes siguen funcionando, pero en un modo degradado o incorrecto que es más difícil de detectar que una caída limpia.
1) Las interrupciones que hicieron visible la “fragilidad de los agentes”
El 11 de marzo de 2026, la página de estado de Anthropic registró un incidente titulado “Errores elevados en claude.ai”, que más tarde se marcó como resuelto, con problemas de inicio de sesión y un despliegue de la corrección anotados. Ese detalle importa porque muchos flujos de trabajo con agentes están, en la práctica, anclados a la interfaz de claude.ai y a su ruta de autenticación, incluso si la infraestructura subyacente del modelo está parcialmente sana.
La cobertura en directo de TechRadar ese mismo día captó el impacto de cara al público: un pico de aproximadamente 1.400 reportes en Downdetector y una cita de la página de estado que indicaba que el problema estaba “Identificado… se está implementando una corrección”. Esta combinación , impacto generalizado en usuarios más una mitigación confirmada en curso, ilustra lo frágiles que se vuelven las “ejecuciones de agentes” cuando requieren acceso interactivo ininterrumpido.
Solo unos días antes, el 2 de marzo de 2026 se produjo una caída mundial de Claude que, según los reportes, estuvo vinculada específicamente a problemas “relacionados con Claude.ai y… rutas de inicio/cierre de sesión”. Ese es un estrechamiento clásico en las pilas modernas de agentes: si se rompe la fontanería de identidad/sesión, puedes incapacitar a usuarios y herramientas aunque algunos componentes del backend sigan respondiendo.
2) La UI y la autenticación son puntos únicos de fallo ocultos
Varios reportes enfatizaron que el evento del 2 de marzo se concentró en el inicio de sesión y el acceso web, descrito como una “interrupción parcial”. Para sistemas agénticos, “parcial” todavía puede significar “total” desde la perspectiva del flujo de trabajo: si un agente requiere una sesión autenticada para obtener contexto, llamar herramientas o solicitar aprobaciones, no puede avanzar.
La reconstrucción de la cronología de BleepingComputer, con el incidente señalado alrededor de las 11:30 UTC y una actualización de “Investigando” a las 11:49 UTC, ayuda a cuantificar lo rápido que las operaciones normales pueden volverse inutilizables. En entornos con agentes, incluso una breve interrupción de autenticación puede dejar planes de larga duración varados a mitad de camino, dejando tareas en estados ambiguos (código a medio escribir, mensajes parcialmente enviados, transacciones incompletas).
La lección clave es que el “tiempo de actividad del modelo” no es lo mismo que el “tiempo de actividad del agente”. Los agentes dependen de las capas delgadas alrededor del modelo: inicio de sesión, sesiones, cookies/tokens, disponibilidad de la UI y, a veces, puntos de control humano en el circuito. Esas capas a menudo fallan de forma distinta (y antes) que el backend central de inferencia, pero son las capas que los agentes tocan con más frecuencia.
3) El acoplamiento de múltiples superficies convierte un incidente en muchos fallos
Un reporte del 2 de marzo describió la interrupción como de más de dos horas y afectando a Claude.ai, Claude Code e incluso a un modelo insignia (Opus 4.6). Desde la perspectiva de un agente, ese es el patrón de pesadilla: un solo incidente del proveedor puede impactar simultáneamente las operaciones basadas en chat, los agentes de programación y el uso en producción.
El 3 de marzo de 2026, en el lapso de unas 24 horas, se reportó otra interrupción con una redacción que abarcaba explícitamente “claude.ai, cowork, platform, claude code”. Esa formulación importa porque describe una cadena de herramientas acoplada en lugar de un componente aislado: chat, superficies de colaboración/coordinación, plataforma para desarrolladores y CLI/app de programación moviéndose juntas en el fallo.
La cobertura del incidente del 3 de marzo también incluyó un ejemplo de marca de tiempo precisa de inicio (~04:43:56 UTC) a partir de reportes del registro de estado. Para equipos que realizan revisiones post-incidente, esas marcas de tiempo son cruciales: permiten correlacionar la degradación del proveedor con fallos internos de agentes (timeouts, errores en llamadas a herramientas, colas atascadas), lo que es el primer paso para diseñar una resiliencia real.
4) Variabilidad de fiabilidad: “errores elevados” no es un caso extremo raro
En febrero de 2026, Forbes señaló una “interrupción parcial” de Claude Desktop y “errores elevados” que afectaban a modelos específicos como Sonnet 4.6 y Opus 4.6. Esto destaca un vector de fragilidad distinto: incluso si “Claude está disponible”, la versión/modelo exacto al que tu agente está fijado puede estar degradado, produciendo fallos que parecen inestabilidad aleatoria.
Forbes también describió picos anteriores en reportes de caídas basados en Downdetector y mencionó problemas de enero, lo que sugiere que la variabilidad de fiabilidad es significativa y recurrente, y no meramente excepcional. Mientras tanto, la cobertura en directo de TechRadar del 22 de enero de 2026 sobre otro episodio de “errores elevados” añade más contexto de que estos incidentes se repiten con patrones reconocibles.
Los agentes, a diferencia del uso casual de chat, se espera que estén disponibles de forma predecible a lo largo del tiempo, a menudo para cumplir SLAs, finalizar planes de varios pasos y producir salidas auditables. Cuando “errores elevados” se convierte en un modo recurrente, socava el determinismo: los agentes pueden fallar a mitad de plan, reintentar con demasiada agresividad o omitir pasos silenciosamente para compensar fallos en llamadas a herramientas.
5) Los bugs de herramientas pueden descarrilar agentes incluso cuando los servidores están bien
La fragilidad de los agentes no se limita a interrupciones del lado del proveedor. El 26 de febrero de 2026, el historial de estado de Anthropic incluyó un bug de Claude Code: “Error de parseo JSON: EOF inesperado” y un problema de “escritura de archivos excesivos en Windows”. Estos son fallos del lado del cliente o de la cadena de herramientas que pueden romper agentes de programación independientemente de la disponibilidad del modelo.
Este es un tipo diferente de radio de impacto: afecta a entornos específicos (por ejemplo, usuarios de Windows) y puede causar efectos secundarios destructivos (escritura excesiva de archivos) en lugar de fallos limpios de solicitudes. Para agentes de programación automatizados que operan sobre repositorios, eso puede significar directorios de trabajo corruptos, diffs ruidosos y ejecuciones de CI rotas, aunque el servicio del modelo en sí pudiera estar respondiendo.
La conclusión operativa es que la “resiliencia del agente” debe incluir todo el perímetro de ejecución: runtime local, CLI, plugins del IDE, permisos del sistema de archivos, proxies de red y robustez de serialización/parseo. Una herramienta que no logra parsear JSON de manera fiable es, en la práctica, tan disruptiva como una interrupción, porque los agentes se comunican cada vez más mediante cargas estructuradas de llamadas a herramientas.
6) El fallo más peligroso: comportamiento degradado que parece éxito
Las interrupciones son obvias: las solicitudes fallan, las páginas no cargan, los usuarios se quejan. Más difícil de detectar son los casos en los que los agentes siguen respondiendo pero con degradación sutil. El postmortem de ingeniería de Anthropic de octubre de 2025 describió cómo aproximadamente el 30% de los usuarios de Claude Code tuvo al menos un mensaje enrutado al tipo de servidor equivocado, lo que llevó a respuestas degradadas.
Para el desarrollo de software impulsado por agentes, las “respuestas degradadas” pueden ser peores que el tiempo de inactividad. Un agente podría generar parches plausibles pero incorrectos, malinterpretar el contexto del repositorio o producir salidas inconsistentes de herramientas, y aun así devolver algo que parezca lo suficientemente válido como para fusionarse si los guardarraíles son débiles.
Aquí es donde la observabilidad se convierte en parte de la seguridad: los equipos necesitan señales que detecten cambios en la calidad del modelo/herramienta (picos de latencia, tasas inusuales de rechazo, anomalías de enrutamiento, aumento de bucles de corrección). Sin eso, las organizaciones pueden confundir “el agente produjo una salida” con “el agente produjo una salida correcta”, especialmente bajo la presión de un incidente.
7) La disponibilidad es solo un eje de fragilidad: el control y la seguridad también importan
Separado de los incidentes de disponibilidad, los reportes han señalado que Anthropic dijo que atacantes usaron Claude en una capacidad agéntica en actividad cibernética. Ese contexto amplía la definición de fragilidad: un sistema de agentes puede estar “disponible” y aun así ser frágil si puede ser coaccionado, mal utilizado o redirigido hacia objetivos dañinos.
La investigación añade otra capa. Un artículo en arXiv sobre pruebas de penetración sistemáticas de sistemas de IA agéntica encontró disparidades de seguridad significativas entre modelos y frameworks. Esto importa operativamente porque las interrupciones a menudo obligan a los equipos a sustituciones de emergencia, cambiando modelos, runtimes o frameworks de agentes para restaurar el servicio, potencialmente alterando la postura de seguridad en el peor momento posible.
En otras palabras, la planificación de resiliencia no puede detenerse en la mecánica de conmutación por error. Debe incluir alternativas seguras por defecto, consistencia de políticas entre proveedores y validación de que los modelos/herramientas de reemplazo no introduzcan nuevas vías de inyección de prompt o abuso de herramientas.
8) Lo que los incidentes de Claude enseñan a los equipos que construyen agentes de IA
El patrón recurrente a lo largo de febrero y marzo de 2026 es que “UI/auth disponible” es una dependencia oculta para muchos agentes. Cuando las rutas de inicio/cierre de sesión se degradan, como se señaló explícitamente en los reportes del 2 de marzo, las aprobaciones con humano en el circuito, las herramientas basadas en sesión y los flujos de trabajo de Claude Code pueden fallar incluso si algunas APIs siguen siendo utilizables.
Un segundo patrón es el acoplamiento de múltiples superficies. La redacción del 3 de marzo que abarca claude.ai, cowork, platform y Claude Code muestra cómo un incidente de un proveedor puede propagarse en cascada a través del chat, la coordinación, las herramientas para desarrolladores y las APIs de la plataforma. Para operaciones basadas en agentes, ese acoplamiento amplifica el radio de impacto: se pierde no solo la inferencia, sino también el pegamento que ejecuta planes y aplica cambios.
En la práctica, esto empuja a los equipos hacia una arquitectura más disciplinada: aislar dependencias, preferir ejecución basada en API por encima de flujos ligados a la UI cuando sea posible, diseñar pasos idempotentes, almacenar estado durable fuera de la sesión del agente e implementar degradación gradual (poner el trabajo en cola, solicitar confirmación humana más tarde o cambiar a modos de capacidad reducida). El objetivo no es “no fallar nunca”, sino “fallar de maneras predecibles y recuperables”.
La secuencia de caídas de Claude no solo interrumpió chats: expuso la realidad de que los agentes de IA son sistemas, no modelos. Cuando interactúan capas de identidad, UIs, herramientas del cliente, versiones de modelos e infraestructura de enrutamiento, el eslabón más débil se convierte en la disponibilidad efectiva de todo el agente.
Las organizaciones que aprendan más rápido tratarán estos incidentes como insumo de diseño: desacoplar flujos de trabajo de rutas únicas de inicio de sesión, instrumentar la salud del agente de extremo a extremo, planificar fallos del proveedor en múltiples superficies y validar la seguridad al intercambiar componentes bajo estrés. La lección es simple: si quieres agentes fiables, tienes que diseñar para la fragilidad, porque ya está ahí.
