En este caso no hay cliente. Se rompió de nuestro lado, y las cifras salen del tablero de trabajo.
Qué es lo que funciona
Grow2.ai lleva la producción de contenido como un sistema multiagente sobre Paperclip: un editor crea tareas, un autor escribe el material maestro, un distribuidor lo adapta por plataforma, un publicador lo sube y un agente aparte reúne las métricas. Una configuración parecida la analizamos en el caso de los cuatro agentes en la gestión : aquí va la misma lógica, aplicada al contenido propio. Cada etapa es un agente separado con su contexto, su ejecución y su tarea en el tablero. La transición entre etapas está formalizada mediante el estado de la tarea y una dependencia de bloqueo: el agente cierra su tarea en done, y eso despierta al siguiente.
La escala al 13 de agosto de 2026: el tablero lleva una numeración continua de AUSA-14 a AUSA-2417, y la primera tarea se creó el 12 de marzo. En la parte de contenido hay 165 materiales, 82 de ellos publicados. Cinco meses alcanzaron para ver qué se rompe de verdad.
La observación principal: los agentes no se caían
La expectativa era que los problemas estarían dentro de los agentes. Alucinaciones, JSON malformado, un agente que entendió mal la tarea, un agente en bucle. Esas cosas pasaron, y son baratas y visibles: el agente escribe un comentario, uno lo lee y lo corrige; y es justamente para eso que se arma la capa de protección habitual.
Las fallas caras se veían de otra manera. El agente funcionaba con éxito, informaba con éxito, cerraba la tarea con éxito, y el trabajo desaparecía. No se perdía en el sentido de un archivo borrado, sino que se volvía invisible para la etapa siguiente. El material está en el disco, la tarea cerrada, todas las métricas en verde, y la publicación no existe.
Los tres patrones de abajo son los más caros que encontramos; el más duradero se sostuvo 24 días. Lo que tienen en común no es la tecnología, sino que ninguno se diagnostica con la pregunta «¿el agente funciona?».
Patrón 1: material aprobado que nunca salió
La aprobación pasa por Telegram: llega una tarjeta con el material, la persona toca «Approve», y un servicio de enlace capta la decisión y crea una tarea de publicación.
Después vino un error de supuesto. El enlace creaba la tarea hija «publicar», pero la tarea de aprobación en sí no la pasaba a done : sencillamente no tenía permisos sobre una tarea ajena. Y la etapa siguiente, que cada mañana busca qué publicar hoy, condicionaba la publicación justo a ese estado de la aprobación: done o no. La aprobación quedaba en in_review, a los siete días hábiles la política de tareas obsoletas la movía a backlog, y el material se volvía invisible para siempre.
El estado en el momento en que lo encontramos (escaneo del 9 de julio de 2026, 2 010 tareas en el tablero):
Indicador | Valor |
|---|---|
Tareas de publicación creadas por el enlace entre el 12 de marzo y el 9 de julio | 82 |
De ellas, aprobación no en | 34 |
— atascadas en | 18 |
— colgadas en | 15 |
— en | 1 |
Es decir: 34 materiales aprobados por una persona real y, al mismo tiempo, invisibles para el sistema. El subgrupo más molesto son esos 18 en backlog: la política de obsolescencia los marcaba puntualmente como «lleva más de una semana sin decisión», cuando la decisión se había tomado el primer día. El sistema informaba lo contrario de lo que había pasado.
Lo arreglamos así: cerrar la aprobación pasó a ser un paso propio del editor en la corrida diaria. Escanear todas las tareas de publicación con marcador de aprobación y, si la aprobación padre no está cerrada, cerrarla. El comprobante de la aprobación es la propia existencia de la tarea hija de publicación.
Si el comprobante de una decisión lo escribe un componente y lo lee otro, lo que hay que verificar no es que el componente haya funcionado, sino que el comprobante apareció realmente donde alguien lo va a buscar.
Patrón 2: un agente en silencio es un motor roto, no un problema de accesos
El publicador tenía un bloqueo real y documentado: parte de los tokens de redes sociales estaban muertos. La tarea para restablecer los accesos estaba abierta desde junio.
Por eso, cuando las tareas de publicación dejaron de moverse, el diagnóstico parecía obvio. Las tareas AUSA-2084 y AUSA-2085, creadas el 13 de julio, quedaron en todo, no hay publicaciones, el publicador no tiene tokens: causa encontrada, esperamos los accesos.
La respuesta correcta apareció el 6 de agosto, 24 días después. Esas tareas tenían cero comentarios.
Un agente que choca con accesos faltantes deja un comentario: enumera las plataformas que fallaron y se detiene. Un agente que no dejó ni un comentario nunca arrancó. Lo que estaba roto no era el acceso, sino el motor de sesión: el agente moría en la inicialización, antes de ver la tarea. La cura no estaba en los tokens sino en la configuración del modelo; después de pasar los agentes a un modelo nuevo, el publicador publicó un material ese mismo día. Que el comportamiento de un agente dependa no solo del prompt sino del armado que lo rodea es algo que analizamos aparte, en por qué un mismo agente de IA da resultados distintos.
Antes de atribuir un estancamiento a un bloqueo conocido, abra la tarea y fíjese si hay un comentario del agente. Si no hay comentario, arregle el arranque y no la integración. En el tablero, «el agente lo intentó y no pudo» y «el agente no despertó» se ven idénticos, y esa distinción costó veinticuatro días.
Otro detalle que tampoco conocíamos: el publicador despierta con la creación de una tarea, y no vuelve a invocarse solo para tareas viejas que están en todo . Después de arreglar el motor hay que despertarlas de forma explícita.
Patrón 3: el filtro que descarta a los suyos
La revisión diaria de «qué publicamos hoy» selecciona materiales con la condición fecha de publicación == hoy. La igualdad estricta no es casual: aflojarla a <= hoy hace que un material con fecha pasada y con la tarea de publicación ya cerrada reciba una tarea nueva cada mañana, y la creación de tareas no es idempotente. Duplicados a diario es peor que una omisión.
La consecuencia que de esa regla no se desprende de forma obvia: un material sin campo de fecha nunca coincide con la fecha de hoy. Es invisible por tiempo indefinido, y puede estar completamente listo, con las adaptaciones por plataforma completas y una aprobación real.
El 10 de agosto había 32 materiales así. El análisis por estado de la aprobación mostró que «32 perdidos» es una formulación imprecisa, y que cada subgrupo se trata distinto:
Subgrupo | Cantidad | Qué significa |
|---|---|---|
Aprobación en | 19 | Aprobado por la persona, no saldrá nunca: se arregla con las fechas |
Aprobación | 2 | Requiere una decisión manual |
Aprobación en | 2 | Requiere una decisión manual |
Sin enlace a una aprobación | 9 | Otro defecto, se resuelve con el procedimiento de búsqueda de «huérfanos» |
Al 13 de agosto quedan 26 materiales sin fecha: 17 con enlace a una aprobación y 9 sin él.
No es un error de código. La condición está escrita exactamente como se pensó, y aflojarla no se puede. El error está en el supuesto de que la fecha siempre existe: el campo es opcional y un material puede llegar a estar listo sin ella.
Al lado vivía otro defecto de la misma naturaleza, y costó un día aparte. Esos mismos escaneos al principio se escribieron como un recorrido de la carpeta del mes en curso. La carpeta corresponde al mes de creación del material, mientras que la fecha del archivo es el mes de publicación, y esas dos cosas se separan con regularidad. El escaneo sobre la carpeta de agosto informaba honestamente «no hay nada para publicar», mientras dos materiales listos con fecha de hoy estaban en la de julio.
Qué tienen en común los tres patrones
- En el primero, el enlace hizo exactamente aquello para lo que tenía permisos, y el comprobante de la decisión no apareció donde se lo leía.
- En el segundo, el agente no existía como proceso, pero su estado en el tablero era un estado válido de «antes del trabajo», imposible de distinguir de «esperando su turno».
- En el tercero, el filtro descartó correctamente todo lo que no coincidía con la condición, incluido lo que debía pasar.
El denominador común: que un agente informe éxito y que el trabajo llegue a la etapa siguiente son dos eventos distintos. El monitoreo que verifica el primero no sabe nada del segundo.
Esta formulación no es un descubrimiento nuestro. El trabajo Why Do Multi-Agent LLM Systems Fail? (Cemri y otros, NeurIPS 2025) analizó más de 1 600 trazas de ejecución anotadas de siete frameworks multiagente populares y construyó la taxonomía MAST: 14 modos de fallo en tres categorías. Una de esas tres categorías es inter-agent misalignment, es decir, la falla en la transmisión de información crítica entre agentes y no dentro de ellos. La frecuencia de fallos en los frameworks analizados fue de entre 41% y 86,7%. Nuestros tres patrones caen justo en esa categoría, y que se hayan reproducido en nuestro propio stack sin conocer la taxonomía es más una confirmación que una casualidad.
Qué monitorear en los traspasos
El mínimo práctico al que llegamos. No es un framework universal, sino lo que cubre nuestros tres patrones.
Verificar el artefacto, no el estado. Después de escribir debe aparecer un archivo; después de publicar, una URL o el ID del registro en la plataforma. Una tarea en done no demuestra que el trabajo ocurrió: nuestro publicador cierra honestamente la tarea en done también cuando saltea un material por la condición de fecha.
El silencio de un agente es un estado propio. Tarea asignada, pasó un día, cero comentarios: eso no es «en curso», es «no arrancó». En el tablero ambos se ven igual, así que hay que distinguirlos de forma explícita.
Los filtros estrictos deben informar lo descartado: no solo qué pasó adelante, sino cuánto no pasó y por qué. Un filtro de fecha == hoy que descarta en silencio 26 materiales listos informa «hoy no hay nada para publicar».
Y aparte, lo que no tiene que ver con el código. El más caro de los tres errores no fue técnico: durante veinticuatro días armamos un plan alrededor de una explicación verosímil, en lugar de gastar una consulta en comprobarla. Un bloqueo conocido en el sistema es una respuesta cómoda a la que los síntomas se pegan solos. Esto vale también para las conclusiones propias de ayer, y lo comprobamos con nosotros mismos: la premisa «las aprobaciones no se pueden cerrar en lote, van a salir duplicados» la cargamos una semana, hasta que un escaneo mostró que no habría ni un duplicado.
El límite honesto de este material
Aquí no hay resultados de clientes ni afirmaciones de que esto sea universal. Son cinco meses de trabajo de un sistema: 18 agentes en una plataforma de orquestación, cinco de ellos en la cadena de contenido. Los tres patrones son lo que encontramos en casa, no una lista exhaustiva de modos de fallo; MAST cuenta catorce.
Grow2.ai construye agentes de IA a medida del proceso del cliente, y publicar la lista de las propias roturas es una manera algo incómoda de hablar de eso. Pero el consejo «monitoreen los traspasos, no los agentes» sin tres historias concretas donde no lo hicimos no valdría nada.
Cómo construimos agentes y dónde trazamos el límite entre lo que conviene automatizar y lo que no — en grow2.ai.