Meta Muse: 72.5% de fallos al lanzar 120 subagentes a la vez

Cómo una prueba de 120 subagentes rompió a Meta Muse

A las 06:45:32 UTC, el ingeniero Marek Cygankiewicz pidió a una sesión de Meta Muse — el agente personal de IA lanzado por Meta el 8 de septiembre de 2026 — que lanzara 120 subagentes a la vez con una tarea trivial: ejecutar sleep 30 en un shell. Resultado: 33 intentos crearon un agente, 87 fallaron con el mismo error de PostgreSQL — canceling statement due to lock timeout — y la respuesta agregada nunca llegó al usuario. La interfaz mostró Error.

Lo notable no es que un sistema cayera bajo carga. Es que cayó de una forma que dejó un rastro legible: un registro de agentes, un libro de spawns, tablas de progreso y un almacén de ítems de contexto. Cygankiewicz reconstruyó todo desde el estado durable, y publicó los CSVs y un script de verificación en su blog. El patrón es demasiado consistente como para ignorarlo si estás construyendo — o vendiendo — agentes.

Lo que el rastro de PostgreSQL cuenta

El experimento forma parte de una batería de cuatro configuraciones, cada una ejecutada una sola vez:

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Configuración	Intentos	Creados	Fallos	Tasa de fallo	Pico de concurrencia
PROBE-40	40	39	1	2.5%	39
BURST-80	80	75	5	6.25%	72
BURST-120	120	33	87	72.5%	33
STAGGERED-80	80	80	0	0%	38

Los seis fallos que se pudieron recuperar del tool trace traían exactamente el mismo payload:

{"error_code":"spawn_failed","error_message":"database error: sqlx error: error returned from database: canceling statement due to lock timeout"}

Todos llegaron sin crear fila de agente hijo ni fila en el spawn ledger. La latencia fue de 12 segundos para la prueba de calibración y ~58 segundos para los cinco fallos del burst de 80. La latencia de los 87 fallos del burst de 120 nunca se registró: solo se guardaron el resultado y la clase de error.

Cygankiewicz deja explícito lo que el dato no establece: no identifica qué lock, tabla, fila, índice, query o transacción estuvo contendida. Los picos (39, 72, 38, 33) son observaciones únicas, no mediciones de un límite. La política de admisión, el ordenamiento y si hubo queue interno siguen siendo desconocidos.

Por qué se rompió donde se rompió

El detonante es estructural: 87 de 120 intentos nunca se convirtieron en agentes, mientras que los 33 que sí se crearon ejecutaron su carga trivial sin problema (32 confirmados con sleep 30 completo, ventanas de actividad de 32 a 43 segundos). La contención está en el camino de escritura del spawn, no en los workers.

Esto encaja con lo que el resto del ecosistema está aprendiendo sobre planos de control de agentes. Uber quemó todo su presupuesto de IA de 2026 en cuatro meses porque unos 5.000 ingenieros ejecutaron sesiones de Claude Code sin topes de gasto, con usuarios pesados llegando a USD 500–2.000 al mes, según reportó Databricks al presentar Omnigent, su meta-harness open source liberado el 13 de junio de 2026. Una empresa sin nombre llegó a gastar USD 500 millones en un solo mes antes de que finanzas cortara. Gartner proyecta que más del 40% de los proyectos de agentes IA se cancelarán antes de 2027 por costos y falta de controles, según recogió el anuncio.

La pregunta que deja la prueba de Cygankiewicz es la misma que persiguió a esas organizaciones: ¿qué pasa cuando el plano de control no escala al ritmo de los intentos del agente?

Evidencia dura, inferencia honesta

Lo que el rastro permite afirmar y lo que no, traducido del original:

Soportado por los registros:

Una sesión de chat ejecutó un runtime multi-agente con traza durable en PostgreSQL, registro explícito padre/hijo y delegación a profundidad 1 y 2.
Las tasas de fallo de spawn observadas fueron 2.5%, 6.25% y 72.5% — una ejecución por configuración, reportadas como observaciones, no como ley de escalado.
Contención en el camino de escritura del spawn es una hipótesis fuertemente respaldada.
Los resultados durables de los workers pueden existir aunque la respuesta agregada final nunca llegue al usuario.

No establecido por los registros:

Qué lock, tabla, fila, índice, query o transacción estuvo contendida.
El timeout configurado del lock.
Ningún límite del scheduler o de admisión.
El paralelismo real del backend de inferencia.
Si un agente hijo sobrevive a un fallo del padre (ese experimento nunca se corrió).

Hay además una pieza externa útil: el teardown independiente de Rohan Adwankar ("What's in a Muse?") confirma en su entorno que PostgreSQL corre dentro de la VM por usuario sobre un socket Unix local, y que el binario del harness contiene paths avocado-5.16-v4 e ipnext/.... Encaja con varias observaciones de Cygankiewicz pero no cambia el límite de su evidencia.

Qué significa esto para tu startup

Si construyes agentes o vendes a equipos que los construyen, la lectura operativa es directa:

El control plane va a ser tu cuello de botella antes que el modelo. Los fallos de carga aquí ocurrieron en la admisión, no en la inferencia. Los 33 workers creados corrieron su tarea sin drama. Audita el camino de escritura del spawn antes de tocar el backend.
Los registros durables ganan a los flags de estado. La interfaz decía Error, el padre decía running, los workers completed. Solo la traza permitía reconstruir qué pasó después. Si tu runtime no escribe lo que hizo, estás perdiendo la opción de diagnosticar.
Cuenta los fallos como ciudadanos de primera. Un spawn fallido no deja fila de agente ni fila de ledger. Sin tu propio libro de experimentos, no podrías contar los 87.
"Status terminal" no es éxito semántico. El worker C-85 terminó con completed pero su outcome es irrecuperable. Estado terminal y trabajo confirmado no son la misma cosa.
Declara el artefacto canónico. Cygankiewicz tuvo un primer reporte autogenerado que afirmaba que el padre había fallado mientras los workers seguían corriendo. La traza no lo soportaba; la corrección llegó en una versión HTML posterior. Para artefactos asíncronos, define qué fuente es la verdad y haz auditorías cruzadas.

Y si tu agente se queda 32 minutos sin eventos de progreso, no lo mates: en la prueba de Cygankiewicz ese silencio terminó en una compilación exitosa. Los eventos de progreso son una pista, no un latido.