Stress test of Meta's Muse agent: 87 of 120 subagent spawns failed with a database error

Burst of 120 spawns, 87 failures

Meta launched Muse, its personal AI agent, on September 8, 2026. Unlike a plain chatbot, Muse is built to act on a user's behalf: it has its own browser, keeps working after the app is closed, and runs inside a dedicated Muse Secure VM. Days after launch, an independent tester ran a black-box stress test from their own Muse session and published the results on blog.cygankiewicz.com, where the write-up reached the Hacker News front page.

The core experiment was blunt. At 06:45:32 UTC the author asked the session to spawn 120 subagents in a single turn, each with a trivial job: run sleep 30 in a shell and report one line back. Only 33 of the calls created an agent. The other 87 failed with the same database error. The aggregated answer never arrived, and the chat interface eventually showed an Error state.

The more interesting discrepancy came afterwards. In the runtime's durable trace, all 33 created agents reached a terminal completed record — 32 with confirmed workload completion and one unresolved — while the parent agent's record still said running. The children finished; the parent's bookkeeping never caught up.

What the trace exposed

The author did not bypass any access controls. Everything ran through interfaces granted to the session itself: subagent.spawn, subagent.close, subagent.resume, a shell in the assigned environment, and a read-only view of a PostgreSQL database the runtime uses for its own bookkeeping. Tables such as agent.agents, agent.subagent_spawns and agent.subagent_progress_tool_events recorded which agents existed, who spawned them, which tools they ran, and when they finished. As the write-up notes, this is how Muse's multi-agent structure became visible at all: the chat presents one conversation, while the trace shows the fan-out underneath.

Two identifiers surfaced. Every agent row — root, coordinator and all 33 burst workers — carried the same model string, ipnext/avocado-5.16-v4. The author publishes it verbatim but declines to interpret it: it could be an internal build, a routing alias, or something else. Separately, the runtime self-identifies as Muse Spark 1.3, which the write-up flags as self-reported rather than verified.

How the runs were measured

Four configurations, one workload, no retries: PROBE-40, BURST-80 and BURST-120 issued as single-turn bursts from the root agent, plus STAGGERED-80, spread over time through a coordinator agent — though the author concedes that run changed both cadence and topology, so it is not a clean comparison with the burst tests. The calibration run, PROBE-40, created 39 of 40 agents with a peak observed concurrency of 39; its single failure was recovered from the trace rather than the chat, with the error arriving 12 seconds after the call.

The write-up defines concurrency narrowly: an agent counts as active from its first tool call to its terminal record, swept over one-second-resolution timestamps. It is explicit about what this does not show. It measures agent activity windows, not simultaneous inference calls; a peak is an observation, not a limit; and failed spawns leave no registry record at all, which made failure counts the hardest numbers to verify. One further detail from the reconstruction, flagged as weaker provenance: eleven of the 39 probe agents ended with a background-processing status instead of the requested completion line — a reminder that terminal status and finished work are not the same statement.

Independent corroboration, with limits

After publication, the author added architectural context from an independent teardown by Rohan Adwankar, titled "What's in a Muse?". In Adwankar's instance, PostgreSQL ran inside the per-user VM over a local Unix socket, and the harness binary contained both avocado-5.16-v4 and ipnext/... paths. He reads ipnext as Meta's internal transport or gateway and avocado as an internal model family, though mapping avocado to Muse Spark 1.3 remains inference. The author's own probe established KVM visibility, while Adwankar identified Cloud Hypervisor running on KVM in his instance. None of this, the author stresses, identifies the specific lock, table, row, query or transaction responsible for the timeouts.

The write-up is equally careful about scope: it is not a Meta-authorized security assessment, and, as the author concedes, having access is not itself evidence that every load experiment was separately authorized.

Why it matters

Muse is days old and positioned as an agent that works for you in the background, durably, across sessions. Subagent fan-out is not an exotic attack pattern — it is how agents parallelise research and multi-step work. If the control plane's database layer rejects most spawn calls under a burst, and parent agents can be left permanently marked running after their children complete, that is a reliability defect in exactly the layer Muse's secure-VM architecture depends on. The episode also shows how much architectural detail a single read-only trace can reveal about a major vendor's agent runtime — per-user VMs, local PostgreSQL, a spawn ledger — within a week of launch, and it sets a useful example of teardown reporting that separates observed identifiers from inferred ones.