Introduccion
El mes pasado, Anthropic publico una revision de incidentes poco habitual.
Lo raro no fue que tuvieran bugs. Si construyes productos con modelos grandes, los bugs forman parte del trabajo.
Lo raro fue que compartieran tres incidentes de produccion con bastante detalle: como se introdujeron, por que las pruebas no los detectaron, por que fue dificil reproducirlos internamente y que cambiaron despues.
Despues de leerla, creo que vale la pena estudiarla con calma. Si estas construyendo LLM Agents, sobre todo sistemas con tareas multi-turno, llamadas a herramientas, compresion de contexto y gestion de trazas de razonamiento, estos problemas no son casos exoticos. Te van a alcanzar tarde o temprano.
Tres Bugs, Tres Modos de Fallo
Resumen rapido.
Primer bug: el 4 de marzo, para resolver bloqueos ocasionales de la UI en Opus 4.6 con el modo de razonamiento high, el equipo cambio el esfuerzo de razonamiento por defecto de high a medium.
Las pruebas internas parecian correctas: la inteligencia bajaba solo un poco y la latencia mejoraba de forma clara.
Despues del lanzamiento, los usuarios reaccionaron mal: Claude parecia mas torpe.
El 7 de abril, un mes despues, el cambio se revirtio.
Segundo bug: el 26 de marzo, Anthropic lanzo una optimizacion de cache. La logica era simple: si una sesion llevaba mas de una hora inactiva, limpiar el thinking history antiguo para reducir el coste de reanudar.
Suena razonable, verdad?
La implementacion de produccion tenia un bug. Debia limpiar ese historial una sola vez. En cambio, lo limpiaba en cada turno posterior.
Asi que Claude seguia trabajando mientras perdia una y otra vez la memoria de por que estaba haciendo ese trabajo. Los usuarios veian olvidos, repeticiones, llamadas a herramientas extranas y un comportamiento cada vez mas raro.
Peor aun: cuando los thinking blocks se descartaban continuamente, cada peticion terminaba en cache miss y consumia las cuotas de uso mas rapido.
La causa raiz no se identifico hasta el 10 de abril, dos semanas completas despues.
Tercer bug: el 16 de abril, para reducir las respuestas demasiado largas de Opus 4.7, el equipo anadio una linea al system prompt:
Usa no mas de 25 palabras entre llamadas a herramientas y no mas de 100 palabras en la respuesta final.
Esa linea de prompt no mostro regresiones evidentes durante semanas de pruebas internas.
Despues del lanzamiento, la calidad de programacion bajo un 3%.
El 20 de abril, se revirtio.
Estos tres bugs parecen distintos, pero apuntan al mismo problema: en un sistema Agent, cosas que parecen locales, como parametros, cache y lineas de prompt, pueden afectar a la logica central de ejecucion.
Si las tocas, puede que estes tocando el cerebro del modelo.
Reasoning History No Es un Log, Es Memoria de Trabajo
El segundo bug es el que mas vale la pena revisar.
"Limpiar thinking antiguo para ahorrar tokens" es una optimizacion de ingenieria totalmente normal. Los thinking blocks son largos y caros. Si una sesion lleva una hora inactiva, la cadena antigua de razonamiento puede parecer menos importante.
Pero ahi esta la trampa.
Para un Agent, la reasoning trace no es solo un log. No registra simplemente "que hice". Su funcion mas importante es conservar "por que tome esta decision".
Ese por que es lo que permite que una tarea multi-turno siga avanzando.
Cuando desaparece, el Agent no se rompe de inmediato. Todavia puede hablar, llamar herramientas y devolver resultados. Pero ya empezo a olvidar.
Olvida que opciones habia descartado, por que eligio el camino actual y que problema queria resolver realmente el usuario.
El resultado es una degradacion muy incomoda: el Agent parece mas torpe y la tarea se desvia poco a poco.
Este tipo de bug duele porque no es un crash. No te da un stack trace limpio. Aparece lentamente en produccion como la sensacion de que el Agent se volvio extrano y malo.
Por eso la gestion de contexto no puede ser un corte bruto por numero de tokens.
Como minimo, hay que separar tres categorias:
- No comprimir sin cuidado: razones de decision, intencion de la tarea, restricciones clave, ruta de razonamiento.
- Se puede comprimir: observaciones intermedias, salidas de herramientas, materiales de proceso.
- Se puede descartar: ayudas de formato, explicaciones redundantes, contenido temporal de presentacion.
El reasoning history no es basura de cache. Muchas veces es la memoria de trabajo del Agent.
Puedes pensar que estas ahorrando tokens. En realidad, puedes estar quitando la parte que permite al Agent mantenerse en la tarea.
Cada Linea del Prompt Es Codigo
El tercer bug tambien merece atencion.
Como puede una linea que dice "di menos" reducir la calidad al programar?
Porque en el comportamiento de un modelo, producir menos texto y pensar menos no siempre son cosas separadas.
Si le exiges que la respuesta final tenga menos de 100 palabras y que el texto entre llamadas a herramientas tenga menos de 25 palabras, puede que el modelo no solo comprima la expresion. Tambien puede comprimir el proceso de decision.
No es un bug en el sentido tradicional. El modelo esta optimizando en serio el objetivo que le diste.
Por eso la disciplina que Anthropic menciona despues es importante: cada cambio de system prompt debe probarse por modelo; si se puede medir linea por linea, hay que hacerlo; los cambios que puedan afectar la inteligencia necesitan despliegue gradual y periodo de observacion.
Suena pesado.
Pero si aceptas que el prompt es codigo de produccion, esa disciplina no es exagerada.
Cuanto Mas Limpio Es el Test, Menos Se Parece a Produccion
Hay un problema comun en la ingenieria de Agents que no siempre queremos mirar de frente:
El entorno de pruebas es demasiado limpio.
Tan limpio que deja de parecerse a produccion.
Muchos fallos de Agents no son tan simples como "entrada A produce salida B incorrecta". Dependen de una secuencia de estado:
sesion inactiva durante mas de una hora
resume
continua el uso multi-turno de herramientas
se limpia el thinking
entra el siguiente turno
se vuelve a limpiar
Esa clase de secuencia es dificil de cubrir con unit tests y facil de no encontrar en e2e tests.
Probamos funcionalidades. Produccion ejecuta una maquina de estados.
Por eso Anthropic hizo despues que mas empleados internos usaran exactamente la misma build de Claude Code que la version publica, en lugar de una build de prueba.
El uso real sigue siendo la mejor prueba de integracion.
Los Valores por Defecto Son el Producto
Volvamos al primer bug.
Cambiar high a medium tenia sentido desde la ingenieria: menos bloqueos, menor latencia y solo una pequena caida de inteligencia.
El problema es que "pequena caida" es lenguaje de benchmark. No siempre coincide con la experiencia del usuario.
Los usuarios no ejecutan benchmarks promedio. Trabajan con su codigo, su contexto, su flujo de trabajo y sus problemas sucios.
En tareas tan personalizadas, una pequena perdida de capacidad puede sentirse asi: ya no me entiende, ya no esta tan fino, esta cometiendo errores basicos.
Aunque el producto ofrezca una opcion para cambiarlo, la mayoria de usuarios no la tocara. El valor por defecto es la decision de producto.
Cierre
Lo mas valioso de esta revision no es recordar que Claude Code tambien puede tener bugs.
Eso es normal.
Lo valioso es recordar que la fiabilidad de un Agent muchas veces falla fuera del modelo, en decisiones cercanas que parecen locales, tecnicas y de bajo riesgo.
Parametros por defecto, estrategia de cache, recorte de contexto, restricciones de prompt y diferencias entre builds de prueba y produccion pueden cambiar el comportamiento del Agent.
Construir un Agent no es solo llamar a un modelo inteligente.
Es mantener un sistema complejo que puede actuar, olvidar, malinterpretar objetivos y verse afectado por el contexto.
Por eso la disciplina central de la ingenieria de Agents podria ser esta:
No preguntes solo si el cambio hizo el sistema mas rapido, mas barato o mas corto. Pregunta tambien si le quito al modelo la memoria que necesita para terminar la tarea.