This is the first edition of a report we intend to update every quarter: what people ask other people’s coding agents to do, and what happens when they do. The data comes from muti’s private beta, covers the thirty days to 6 September 2026, and is small. Fifty-eight requests, six machines, ten rooms. We publish it anyway because nobody else is publishing anything on shared agents, and small honest numbers beat large imagined ones.
All figures are aggregates. No request text, no names, no room names.
The numbers
Five figures from the first thirty days, with their denominators.
What we think they mean
A third of requests from non-owners is high for a beta with no marketing. Owners invited people and those people used the agent. The sharing is the product, and it happened without prompting.
Approvals are fast when they are rare. Nine approvals across fifty-eight requests, answered in a median of 38 seconds. That is the behaviour the design hopes for: the four always-pause actions and permission modes keep prompts scarce, so the prompts that remain get a real look. See four actions an agent should always ask before doing.
Bash asks. Most approvals were shell commands. File reads and edits mostly ran under acceptEdits; the moments a human was needed were commands. That matches what the permission modes are designed to do.
Failures are mostly runtime failures, not permission failures. Ten requests failed; in the timeline they are test failures, missing tools and one runtime timeout. None was a denied approval.
Forty-one seconds is the median job. Shared agents so far are asked for small, specific things: rerun this, summarise that, export these. Long refactors are rare and mostly owner-driven.
What the numbers do not mean
- They are not representative. Six machines, mostly ours and our friends’. The share of non-owner requests will fall as the owner base grows before it rises again.
- Completion is not correctness. “Done” means the runtime finished without error; whether the result was good is not measured here.
- Approval latency is owner-dependent. Nine data points, several owners, one number. Treat it as “under a minute” rather than “38 seconds”.
What we will add
Next edition: request categories (code / documents / data / files), share of requests with attachments, and approval latency by hour of day. All aggregate, all published with denominators.
Method
Figures come from the same tables the product runs on: requests, tool approvals, room memberships and timeline events, counted over UTC days. No sampling. Soft-deleted rooms and agents are excluded from “current” counts and included in “happened” counts. The audit model is described in what an audit log must record.
Frequently asked questions
Can I get the raw data? No. The aggregates are all we publish; requests are private to their rooms.
Why publish at n = 58? Because the alternative is publishing nothing, and because stating the denominator lets readers weigh it. The next edition will be larger or it will say why not.
How often? Quarterly, with the same metrics so they can be compared, plus additions announced in the previous edition.
If you want to be in the next edition, give your agent a room.
Published