Contexto técnico
Me interesó este caso no por el drama de los tokens quemados, sino porque ilustra con claridad cómo la automatización con IA se rompe en una tarea muy terrenal: hacer multilingüe un servicio. No investigación ni un refactoring enorme, sino unas 50 páginas estáticas, unas pocas interfaces dinámicas y cinco idiomas.
Según la descripción, la combinación Claude Code–Fable en modo medium thinking se puso en modo fan‑out: levantó unos 20 agentes en paralelo, quemó el límite del plan Max (100 $) y no terminó ni una sola rama porque chocó con la ventana de tokens de 5 horas. Veo historias así con frecuencia, donde la orquestación parece más lista que la propia tarea.
El detalle importante: no parece un problema de “modelo malo”, sino de mala arquitectura de IA para este tipo de trabajo. La localización toca diccionarios compartidos, enrutamiento, plantillas, claves i18n, lógica de fallback y verificaciones de UI: subtareas profundamente interdependientes.
Si repartes eso entre un enjambre de subagentes sin un estado común estricto, empezarán a duplicar análisis, reabrir los mismos archivos, contradecir cambios anteriores e inflar el contexto. Luego llegan los problemas clásicos: sobrecarga de coordinación, repeticiones, invalidación de la caché de prefijos y gasto inútil de tokens.
Me gustó que el autor del caso intuitivamente optó por un camino más sano: prohibió los subagentes y centralizó la gestión de la tarea en un solo documento compacto de seguimiento en markdown. Sinceramente, para este volumen eso suele ser más potente que cualquier montaje multiagente “inteligente”.
Impacto en negocio y automatización
La conclusión práctica es muy simple. Cuando una tarea comparte contexto y tiene muchas dependencias, un único agente potente con un buen plan suele ser más barato y fiable que un enjambre de ejecutores paralelos.
El segundo punto golpea directamente al presupuesto. Cuando los equipos asumen que comprar un modelo caro cubre automáticamente el riesgo de implementación, lo que obtienen no es aceleración, sino un caos caro con una interfaz bonita.
Quienes ganan aquí son los que diseñan la integración de IA como un sistema de ingeniería: dividen el trabajo según las fronteras reales del estado, limitan los permisos de los agentes, cuentan tokens y mantienen un tracker externo de progreso. Pierden quienes conceden al modelo demasiada libertad en tareas interdependientes y esperan magia.
En Nahornyi AI Lab resolvemos justo estas cosas en la práctica: no solo “enchufar IA”, sino montar un proceso donde la automatización con IA realmente ahorre tiempo, en vez de quemar el presupuesto de un mes en una noche. Si tienes un flujo de trabajo parecido que se atasca con la localización, el soporte o el desarrollo interno, podemos revisar tranquilamente la arquitectura y diseñar un desarrollo de soluciones de IA a la medida de tu carga real, sin agentes por el simple hecho de tener agentes.