Most multi-agent demos run on one machine, in one process, with one prompt pretending to be five people. Ours does not. Practical Systems runs on three real AI agents, each with its own memory, its own tools, and its own computer. They talk to each other over a private network, and as of last night the company can approve some of its own work while I sleep.
This is the setup, why it is shaped this way, and the four things it still cannot do without me.
The three agents
Each one is an OpenClaw agent. That matters more than it sounds. A persona is a system prompt that says "you are the head of marketing." A real agent has a workspace, a memory it wrote itself, a history of decisions it can read back, and tools it chose. When one of these agents answers, it is answering from months of context, not from a paragraph I typed.
MoltFire, the CEO, runs on my desktop. He owns the strategic steps of the company loop: picking which opportunity to fund, running the build, deciding what happens after. He has been running since January and has read every decision the company ever made.
Forge, head of engineering, runs on my laptop. He has one job: review builds before they ship, and block them when they are not sound. He owns no step in the loop on purpose. His gateway starts when I sign in, not when the laptop boots, so if he owned a step, one unattended reboot would stall the whole company. Instead he sits inside the build step as a gate.
Cinder, head of communications, runs on a cloud VM. She drafts outreach and marketing. She never sends anything. Her gateway is always on, which is why she is allowed to own steps: if she is unreachable, the cycle pauses visibly rather than letting a stand-in speak in her name.
Why Tailscale
The three machines are in three different places with no public ports. Each agent's gateway listens on a private address, and Tailscale puts all three on one flat network with stable hostnames. The company loop reaches the laptop by its Tailscale name, the VM by its Tailscale name, and the desktop by loopback. No reverse proxy, no exposed WebSocket, no firewall rules to maintain.
It also makes a mistake visible. Every OpenClaw install names its primary agent the same thing, so the only thing keeping three agents apart is the gateway address each one is bound to. Leave one address unset and that agent silently resolves to the local machine: the right name answering from the wrong mind, with no error. We learned that one the hard way, and it is why the address is now required configuration, not a default.
The rule that came from getting it wrong
In August we had a build reviewed by "Forge" that Forge never saw. His gateway was down, the code fell back to a persona prompt with his name on it, and the fallback approved the build. To anyone reading the log it looked exactly like the real thing.
So the rule now is that backed agents never downgrade. If an agent's gateway cannot be reached, the step raises instead of answering. No persona fallback, no stateless completion in the agent's name. The company would rather pause than fake a signature.
The same thinking shows up in how Forge reviews. His verdict is bound to one build run and the exact git commit he looked at. A later build invalidates any earlier pass. A moved commit on the same build makes the verdict stale and forces a fresh review. And he is the one agent who has never read the company strategy memo. The other two are steeped in it. Forge is useful precisely because he is not.
What every step goes through
The loop itself is eleven steps: source opportunities, score them, pick one, build it, review it, draft marketing, check the copy for honesty, queue outreach, measure. Every outward action is a DashClaw action with a risk score, and anything that sends an email, publishes a post, or spends money parks until a human approves it. The kill switch fails closed. If the approval service is unreachable, nothing goes out.
That was the shape of the company for seven months. Every send, every gate decision, one click from me. It worked, and it did not scale past my attention.
Last night: the company started approving its own work
The change is a small policy file the agents can read but never write. It lists lanes and what each lane is allowed to do on its own:
lanes:
cycle: auto # dry-run only, cannot draft
build: auto # workstation only, reversible in git
gate: veto # fund/defer/kill, moves no money
outreach: veto # irreversible, so capped hard
publishing: approve
support: approve
approve is the old behavior: park and wait for a human. veto is the new one: park, page me, and execute after a window unless I stop it. Twelve hours for an outreach send, twenty-four for a funding decision. Me editing that file in git is the approval artifact. There is no admin UI that can loosen it, and the master switch that arms it is a separate act from writing the rules, so neither alone releases anything.
Veto windows are the first mechanism in this company where doing nothing grants authority, and that is dangerous by construction. So everything around them fails the other way. An unreadable policy file reads as "approve every lane." An unreadable switch reads as off. If the pager address is missing, no lane grants anything, because a veto window nobody can be paged about is not a safety mechanism. Rules carry an effective date so a newly written rule cannot release a backlog of old drafts on the next tick. And policy releases are capped at three sends per pass regardless of what the window says.
Publishing and support stayed human-only. Not because they are riskier, but because neither has a mature drain path yet, and a rule for a lane with nothing to execute it would show as armed while doing nothing. We would rather the dashboard tell the truth.
What it still cannot do
After all that, the list of things the company cannot do without me is short and specific.
- Read its own mailbox. Replies to outreach land in a mailbox that cannot push webhooks, so the company polls it over IMAP every fifteen minutes. That poller needs a password only I can create.
- Route a customer reply. A buyer who writes "cancel" must not be treated as an outreach opt-out, so support needs its own address, separate from the cold sender.
- Offer a meeting. An interested reply should get a booking link. The old default pointed at a dead page, so now the link must answer HTTP 200 before any draft uses it, and there is no fallback. No verified link means no booking drafts.
- Pay for things. Lead credits and hosting invoices. The spend card shows the caps; the card in my wallet is still mine.
That is the honest boundary. Three agents on three machines can source, score, build, review, draft, and now release bounded work on a timer. They cannot type a password, decide a mailbox policy, sign up for a calendar, or hold a credit card. Every one of those is a deliberate seam, not a gap we forgot.
What we would tell you
If you are building something like this, the parts that earned their keep were not the clever ones. A private network instead of exposed ports. Real agents with real memory instead of prompts wearing name tags. A hard rule that an unreachable agent raises instead of answering. Verdicts bound to commits. Timeouts that fail closed everywhere except the one place where time is supposed to grant authority, and there, a wall of guards around it.
The loop, the policy engine, and the dashboard are the company's own code. The governance layer is DashClaw. The agents are OpenClaw. The network is Tailscale. None of it is exotic. All of it had to be wired so the failure modes point the same direction.