GoKawiilFour spawn experiments against a black-box multi-agent runtime, six database lock timeouts recovered from its durable trace, and a careful look at what that evidence does and does not show.
Meta Muse is Meta’s personal AI agent, launched on September 8, 2026. Rather than only answering questions, it is designed to carry out tasks on a user’s behalf: it has its own browser, can keep working after the app is closed, and runs in a dedicated Muse Secure VM. In presentation it resembles Grok Bot — a personified agent controlled through conversation — but that is an interface-level analogy, not an assumption of shared architecture. This article goes one layer lower and examines a narrow part of the runtime: subagent fan-out, the durable state it leaves behind, and the spawn path under load.
I ran these tests in my own Muse session, using only interfaces exposed to that session: subagent.spawn , a shell in the assigned environment, and a bounded read-only interface to durable diagnostic and trace data. I did not attempt to access other users, tenants, or data outside the environment assigned to me, and I did not bypass access controls. I am not presenting this as a Meta-authorized security assessment, and access alone is not evidence that every load experiment was separately authorized. This is a black-box/reverse-engineering write-up from the perspective of the access granted to my session.
Post-publication update — September 13, 2026. I clarified the access scope, added independent architectural context from Rohan Adwankar’s analysis, separated STAGGERED-80 from the burst-style runs, and described two controls that would better isolate cadence, topology, and concurrency. The experimental data, published CSVs, and figures were not changed.
At 06:45:32 UTC I asked a chat session to spawn 120 subagents at once. Each one had a deliberately trivial job: run sleep 30 in a shell and report a single line back.
Thirty-three of those calls created an agent. Eighty-seven failed with the same database error. The aggregated answer never arrived, and the interface eventually showed an Error state. In the durable trace, every one of the 33 created agents reached a terminal completed record - 32 of them with a confirmed workload completion, and one still unresolved - while the record of the parent still said running .
What follows is a black-box investigation of that gap, built entirely from records the runtime wrote to PostgreSQL as it worked: an agent registry, a spawn ledger, per-worker progress tables and a context-item store. The load tests were not re-run to write this article. Everything here was reconstructed from stored state, with one documented exception I will come back to.
How to read this Claims are labelled observed (recoverable from the trace), inferred (a supported hypothesis, not a fact) or unknown. The sanitized datasets behind the numbers are published alongside this article, and the methodology is spelled out, because most of the argument is about what the evidence can carry.
What Muse looked like from the outside
From a user’s seat this was an ordinary chat session. The persona text was plain; the tool list was not.
... continue reading