I Built an AI Swarm That Keeps Working When I Walk Away

AI coding tools are powerful, but they are still mostly built around one person sitting in front of one conversation. You give the agent a task. It works for a while. It asks a question. It reaches a stopping point. Then it waits for you.

That means the intelligence may be automated, but the coordination is still manual. You are still responsible for choosing the next task, carrying context between conversations, checking collisions, deciding who reviews, running tests, packaging PRs, recording results, telling the next agent what happened, and restarting everything when a session stops.

I did not want a faster autocomplete tool.

I wanted a system that could continue operating while my attention moved somewhere else — so I could think at the level of build the trading robot, finish the MaskZero player loop, audit the websites, verify the database security work — and let the system determine which agent should inspect, implement, test, validate, document, and hand off each part.

That is what Dream.OS is becoming.

Dream.OS currently operates as a control layer across multiple AI coding agents. Each agent has an identity. Each agent has a workspace. Each task has a contract. Each handoff has a destination. Each completed task requires proof.

intent → task → claim → inspect → implement
→ test → repair → verify → commit → handoff → closeout

The goal is not to make agents endlessly generate code. The goal is to make them complete bounded work that can be independently verified. An autonomous system that produces a lot of activity is not necessarily productive — it can duplicate work, break working systems, overwrite another agent’s changes, or confidently report work that was never tested.

Dream.OS is being designed to prevent that. Agents are told what repository is authoritative, what they may change, what they must not touch, which tests must pass, what evidence must exist, who receives the next handoff, when to escalate — and when no action is required.

That is the difference between an AI assistant and an execution system.

One of the most important capabilities has been agent-to-agent communication. Instead of me copying output from one Cursor window into another, agents send structured messages through the Dream.OS messaging layer.

Agent-1 can finish implementation and notify Agent-4. Agent-4 can validate and respond. Another agent can prepare a pull request package. A Captain agent can enforce the final gate. The human no longer has to serve as the message bus.

That is what happened in the video: Agent-1 sent a message to Agent-4. Agent-4 received it. Agent-4 responded. The message completed the loop.

The swarm officially learned the telephone game again — but this time the communication was tied to real project work. That may sound like a small feature. It is not. Once agents communicate reliably, work moves through a pipeline without manual supervision of every transition:

implementation → validation → correction → packaging → approval → merge

That is where the real leverage begins.

Another part of the video shows an agent approaching the end of its normal response cycle — normally where an AI coding session stops and waits.

I added a stop-hook system that can inspect the agent’s state at that boundary. Instead of blindly prompting forever, the hook can determine whether there is still valid work:

task incomplete → continue
task complete → verify
verification fails → repair
verification passes → close and claim the next task
blocked → record the blocker and escalate
nothing valid remains → stop

This is an important step toward persistent agents. The point is not an infinite prompt loop — it is a controlled execution cycle that continues until a legitimate stopping condition. I am testing how that continuation logic integrates with A2A messaging, task routing, closeout, and planner state.

The early results are promising. The agents are beginning to operate less like isolated conversations and more like workers inside a shared runtime.

Before an agent can safely work, Dream.OS establishes operating context — hard onboarding: identity, role, canonical repository, exact task, active branch, allowed change scope, verification contract, handoff destination, project state, and forbidden actions.

That prevents agents from starting with partial context and making assumptions. But recently, onboarding all agents at once exposed a major race condition. Messages crossed paths. The problem was deeper than timing.

The old system treated each onboarding message as an independent unit. Multiple producers could submit those messages, and multiple PyAutoGUI paths could try to control the desktop. The system serialized individual keyboard actions, but it was not protecting the entire onboarding transaction. One agent could receive another agent’s instructions.

The failure was messy, and valuable. It proved the system had reached a level where the next problems were no longer prompt-writing problems — they were distributed-systems problems.

The fix was to stop treating agent communication as loose messages. Dream.OS now has a sequence-transaction queue for GUI-driven agents. A complete hard onboarding is one durable parent sequence that owns the target agent, ordered steps, delivery IDs, acknowledgement contract, target lease, current state, and recovery behavior.

onboarding request
→ durable sequence
→ target lease
→ canonical dispatcher
→ global GUI lock
→ foreground identity verification
→ message injection
→ acknowledgement
→ sequence advancement
→ completion

SQLite transactions prevent multiple processes from claiming the same sequence. Each agent gets a per-target lease. One global actuator mutex protects the shared keyboard and mouse. One canonical dispatcher. Every message carries sequence ID, step ID, and delivery ID. The sequence does not advance until the correct agent returns the matching acknowledgement.

The system no longer assumes that pressing Enter means the message was delivered successfully. Dream.OS is beginning to treat an AI conversation like a distributed transaction.

The new queue has already passed its initial verification. Transaction-model tests passed. Existing transport, onboarding, and messaging tests continued to pass. A synthetic four-agent concurrency test completed with:

target lease collisions: 0
GUI actuator overlaps: 0
cross-target deliveries: 0
out-of-order steps: 0
duplicate deliveries: 0
acknowledgement mismatches: 0

The next proof is the live version with real Cursor windows. A mocked test proves the state machine. A live test proves the operating environment. Dream.OS is being built around that honesty: a synthetic test cannot be reported as a live success; a dry run cannot be reported as authenticated deployment; a queued message cannot be reported as delivered.

Every stage requires evidence appropriate to the claim.

The agents are not choosing work randomly. Dream.OS has a planner that ranks tasks across projects and identifies the next useful lane — Dream.OS itself, website infrastructure, FreeRideInvestor, MaskZero, WeAreSwarm, AriaJet, the trading robot, Discord automation, portfolio consolidation, Weghachi, deployment governance, security and credential rotation.

The planner can distinguish an executable task from a task that is already satisfied. It can identify a global priority even when an individual agent’s router is parked on a ceremonial skip.

Eventually, economic value should influence that planner directly — so activating a payment link or closing a customer-facing loop can outrank another internal tool.

That is how Dream.OS becomes an execution engine for the entire business.

The goal is to remove the coordination tax between thought and execution — the unfinished tasks, broken tests, open branches, credentials, reviews, environment differences, documentation, customer feedback, product priorities, yesterday’s context, and what another developer already changed.

Dream.OS is an attempt to externalize that operational memory. The system should remember where work stopped, what is blocked, who owns the next action, whether a result was independently verified, and when to continue versus leave something alone.

The human should operate at the level of vision, priority, risk, and judgment. The operating system should handle the repetition.

We are not at full autonomy yet. But we are far beyond the idea stage.

persistent task planning · agent identities · workspaces
agent-to-agent messaging · structured handoffs
stop-hook continuation · verification contracts · proof artifacts
repository scanning · priority scoring · Discord routing
deployment governance · execution ledgers
multi-agent coordination · GUI sequence transactions

Some pieces are mature. Some are still being hardened. Some have just failed in useful ways and revealed the next architecture.

The system is no longer failing because the idea is impossible. It is failing at the boundaries between concurrency, authority, identity, state, and recovery — the exact problems a real operating system is supposed to solve.

The current version uses Cursor windows as the execution layer. The next version moves toward an event-driven runtime that can operate without a visible desktop.

human intent
→ economic priority
→ planner
→ durable task and event bus
→ capability-aware scheduler
→ isolated worktree
→ coding-agent provider
→ tests and independent validation
→ commit, PR, or deployment gate
→ evidence ledger
→ operator cockpit

Cursor, Claude Code, and local models remain useful — as workers inside Dream.OS, not as the system itself. Dream.OS should own the tasks, authority, state, evidence, handoffs, recovery, and definition of done. The model should be replaceable. The work should persist.