My early multi-agent tooling treated coordination as messages.
An engineer agent would leave feedback for a reviewer. A polling loop delivered it. A project-manager agent checked the build and sent another message. Plain files worked surprisingly well because every agent understood them and I could inspect the directory when something stalled.
That setup became harder to reason about once runs had dozens of tasks, separate branches, dependencies, re-reviews, and more than one model provider.
The problem was no longer delivering a sentence. I needed to know what work existed, who owned it, what it depended on, which contract it had promised to follow, and why the reviewer rejected it.
Scry rooms model that structure directly.
A room has a board and a channel
A fleet room belongs to one run and repository. It contains a task board plus a permanent message channel.
Tasks have IDs, titles, descriptions, dependencies, interface contracts, claims, and status. Workers claim tasks atomically before starting. State transitions are explicit:
open -> claimed -> in_progress -> review -> done
\-> abandoned
Abandoning a task clears its claim so another worker can take it. A task can’t quietly become complete because an agent wrote “done” in a chat message.
The channel carries status, handoffs, contract negotiations, and review messages. Posts are threaded by task ID and receive sequence numbers. A reviewer can cite the exact message it is answering.
During a run, this is coordination software. Afterward, the same records describe how the work was split, blocked, reviewed, and finished.
Dependencies record the shape of the work
A task dependency is an edge. So is a claim, a contract, a review, and a rework cycle.
Given enough completed rooms, Scry can answer questions that a transcript makes painful:
- Which task types repeatedly block later work?
- Which interfaces attract the most contract renegotiation?
- How many review rounds does a migration task usually need?
- Which tasks passed their local gate but failed independent review?
- Which model tends to abandon tasks in a particular area?
Scry doesn’t answer all of those as first-class analytics yet. The events are structured, though, so I don’t have to reconstruct a review cycle from a chat transcript later.
The permanent history also feeds global memory. A completed fleet is an episode source with a goal, task structure, iterations, gate results, and final status. The next run can remember that an earlier campaign failed on the same dependency or that a particular contract was frozen for a reason.
Contracts are more useful than shared context
Two autonomous agents can work in parallel when the boundary between them is explicit.
I used this on a build-control project and its terminal client. One agent owned the producer and control plane. Another owned the consumer UI. They worked in separate git worktrees against a frozen versioned command contract. Integration happened later against immutable commits.
The agents didn’t need each other’s entire context. They needed the versioned command contract and the commit each side produced.
Scry rooms let a task publish or negotiate those boundaries in the same place reviewers will later inspect them. If the implementation drifts, the review thread can point at the agreed interface rather than a remembered summary of it.
Both agents stayed in separate worktrees, which also meant one confused edit couldn’t overwrite the other agent’s branch.
Review belongs to the task history
An autonomous implementation isn’t finished when its author says it is.
In the fleet workflow, a separate engine reviews the delivered branch or commit, runs independent checks, and posts a verdict to the task thread. A CHANGES verdict returns the task to active work. The next review can cite the previous findings and verify them against a new immutable commit.
The history keeps the failed reviews as well as the final approval.
That data is useful for future planning. If three tasks involving database migrations all needed a second review because their verification ignored rollback behavior, the next decomposition can add that requirement before work starts.
Without the task graph, those reviews become isolated conversations. The same mistake feels new each time.
Capacity is part of coordination state
Agent fleets also depend on external capacity. A provider can hit a subscription limit halfway through a campaign. Treating that as a transient task failure leads the scheduler to retry the same unavailable engine.
My orchestration layer now persists engine-capacity state and replans future waves across available providers only when enough independent engines remain for cross-review. Usage events are stored separately from prompts.
That decision is remembered globally, while the affected tasks and reviews remain in the room. The memory graph explains the policy. The room history shows how it affected one run.
The global memory graph stores the provider policy. The room stores the tasks and reviews affected by it.
Rooms make failures legible
Multi-agent systems fail in boring ways. A task is claimed and never started. A branch contains no commits. A reviewer checks the wrong revision. A dependency is still in progress. A worker says it finished but leaves test processes behind.
Structured room state makes those conditions visible. An orchestrator can inspect the board instead of asking every agent for a self-report. A reviewer can confirm the claimed branch and commit. Cleanup can check for survivors after the final gate.
The room doesn’t make agents reliable. It lets the orchestrator see that a claim is stuck, a branch is empty, or a review never happened without asking the worker to describe its own failure. Once the run ends, those same task, dependency, claim, and review records remain available for the next plan.