A private workshop digest from 30 August 2026 is a better guide to multi-agent orchestration than most vendor documentation, because it records what two people ran hard for a week and what actually broke. We read it as a Claude consultancy, and there is a line in it we are not going to skip over.
The session host spent a week running Grok Bot and came out of it having dropped Claude Code as his daily driver. If you sell Claude work for a living, that is either something you bury or something you read carefully. The reasons turn out to be about the harness around the model rather than the model, which makes them useful to anyone building multi-agent workflows on Claude Code.
What made an experienced builder switch daily drivers?
Two harness features, neither of them about answer quality. The first is a shared computer: every bot appears to have its own machine, but they all run on one cloud computer with separate desktop previews, so when one agent writes a file the others can see it. The second is a cloud agent that spins up a separate virtual machine with its own dev server for every task, which lets five tasks run live and be tested in parallel, with each pull request carrying a button that opens that exact machine.
There is a third detail worth quoting plainly. Every machine running the app registers itself under a computer setting, so an agent can copy files from cloud to local and back in the middle of a session. That is the specific gap the host flags in Claude Code and Codex as at September 2026, and it is a fair criticism rather than a marketing line.
The patterns worth stealing into a Claude Code setup
Most of what came out of the week transfers regardless of which harness you run, because the hard parts of multi-agent work are structural. These are the design decisions the session called out as worth copying.
Keep the agent count as low as it will go. Add a sub-agent only when the main one does something badly, not because a new domain appeared.
Skip broadcast channels. Broadcast is token-heavy and is not real parallelism. Use send-to-agent instead, with one main agent per product talking down to sub-agents.
Hold global rules in one place. A chief-of-agents pattern carries rules such as never post to social directly and every pull request ships verification screenshots, and agents created through it inherit the rules rather than having them retyped.
Give agents an isolated inbox rather than your real one.
Route paid data through an open router instead of a pile of per-tool subscriptions.
The inherited-rules point is the one we push hardest with clients. Rules that live in one agent's prompt get copied, drift and then contradict each other three months later. Rules that get inherited at creation time stay one edit away from being fixed everywhere.
Memory is what makes one agent different from another
The Grok Bot model is that tools and files are shared across every agent on the computer, so the thing that differentiates an agent is its memory and its chat session. Memory itself comes in three tiers, each scoped at either the user or the project level.
| Tier | Behaviour | What it suits |
|---|---|---|
| Profile | Always in context | Facts that apply on nearly every turn |
| Log | A rolling daily log | What happened recently, in order |
| Note | A scratch pad where old entries get squeezed out | Working state for the task in hand |
If you are building on Claude Code, that three-way split is a useful audit. Most setups we inspect in Sydney have a single undifferentiated instruction file doing all three jobs at once, which is why they grow to two thousand lines and stop being read carefully by anyone, model or human.
What was actually running always-on
The always-on list from the session is worth noting for how unglamorous it is. None of it is a moonshot.
GitHub issue triage.
A Slack alerts agent that routes by alert type through a hosted webhook.
A daily scan of saved social bookmarks that feeds a wiki.
Search support work.
Small, bounded, and each one replacing a task somebody used to do at 8am. That is the pattern we see work for Australian teams too. The multi-agent setups that survive contact with a real business are the ones where every agent has a single job you could describe to the person whose morning it used to be.
The part nobody puts in the demo
The session closed on an open thread about money. Grok Bot usage bills separately from the Cursor models, heavy use burns the allowance in days, and several members reported their weekly usage report showing zero. An orchestration pattern that is efficient in tokens can still be expensive in allowance, and a usage report you cannot trust is worse than no report at all.
The other session that week came at the same problem from a different angle. A member demonstrated a voice clone of himself that strangers cross-examine before they ever reach him: it answers only from what he has actually shipped, shows what it searched, forgets you when you close the tab, and keeps sensitive context out through role-based access control. Strip the voice novelty and the design contract underneath is the one every agent needs. Show the work, scope the sources, forget by default.
What this costs to set up properly
Moving a team from one agent doing everything to a bounded multi-agent setup usually runs $15,000 to $35,000 of work on our engagements. That covers inherited global rules, a verification step on every change, one job per agent, and a spend ceiling with a report somebody reads weekly. The spend ceiling is the line item clients try to cut and the one that pays for itself first.
For the mechanics of splitting work across agents, our guide to Claude Code subagents and parallel work is the starting point, and why subagents get worse after 200k tokens explains why keeping the agent count low is not just tidiness. If you want us to look at your setup, that is what our consulting services are for.
