Multi-agent orchestration advances durable work through agents, workflows, gates, and recovery while processes come and go. Agent work management supplies the durable work, relationships, and readiness underneath it. Keeping execution coherent across both layers is the architecture problem.
The cleanest design puts work outside the sessions. Gas City runs configured coding-agent workflows on a durable Beads graph, so each agent can discover what is ready, claim one item, record progress, and leave a recoverable state behind.
The system question is what must remain true while workers start, stop, and fail. The coordination guide applies those guarantees to one concrete repository workflow.
Start with the failure model
Multiple agents create value when the work can separate. They create confusion when the system has no answer for ordinary failures.
| Failure | Missing mechanism | Observable symptom |
|---|---|---|
| Two agents take the same task | Atomic ownership | Conflicting changes and duplicate effort |
| An agent begins blocked work | Dependency-aware routing | Rework based on an unfinished prerequisite |
| A process dies mid-step | Durable work state | A human reconstructs the job from chat and code |
| Parallel edits touch the same files | Workspace isolation | Merge conflicts become the coordination protocol |
| Output reaches the repo unchecked | Explicit quality gates | Completion means “the agent stopped” |
A model upgrade may improve the implementation. These system properties still have to come from the surrounding architecture.
The agent work graph guide explains the work representation. The evaluation rubric turns the same failure model into a repeatable test.
Use a durable coordination loop
A sound loop begins with ready work, meaning an open bead with no active blocker. An agent claims the bead atomically, works in an appropriate project scope, records decisions and newly discovered work, and closes or hands off the bead. The next dependent step enters the ready frontier only after its blockers close.
That loop separates the agent’s life from the job’s life.
Beads supplies the durable objects, relationships, ready query, and claim operation. Gas City supplies the configured workflow that materializes those objects, routes them to agent pools, retries expected failures, and drives the graph outside the initiating session.
For current mechanics, read How Gas City works, Understanding formulas, and the Beads coordination guide.
Recovery should be a normal transition
The most revealing orchestration test takes less than an hour: stop an agent while it owns active work.
After the process exits, inspect four things:
- Does the work item still exist with an unambiguous owner and status?
- Are its blockers and dependent steps unchanged?
- Can a replacement session read the recorded decisions without the old transcript?
- Does the workflow still know which gate comes next?
Recovery may include retrying, releasing a stale claim, or assigning the bead to another agent. The important property is that nobody has to invent the state from scratch. The coding-agent crash recovery guide goes deeper on that handoff.
Gas City’s event surface helps an operator see that a session crashed and another woke. Events are operational signals. Beads remains the durable work record. A graph-workflow run has a durable root bead and step beads; Gas City’s local run view folds their retained lifecycle events and adds live execution detail. It is not a second, separately governed team record.
Pick the architecture by the job
There are several valid places to coordinate agents.
A shell script or terminal multiplexer works for a personal experiment with independent tasks. The operator becomes the scheduler and recovery system.
An agent SDK or graph runtime fits when you are building an application whose agents live inside your code. You own the application’s state model and write the control flow.
A no-code automation tool fits business workflows whose important actions already exist as connectors and forms.
A software factory platform fits coding work across real repositories when the method should be inspectable configuration. Gas City starts with coding-agent CLIs, workflows, projects, Beads, and local operation. The software factory reference architecture maps those components without making the event stream a second work store.
Choose by asking who holds the long-lived work, where dependencies are evaluated, how concurrent ownership is settled, and what remains after a process disappears.
Quality gates belong in the graph
An agent saying “done” is a status report, not an acceptance test.
Put the expected evidence in the workflow. A code-delivery graph may require an implementation step, focused tests, review, and a final human decision. A formula gate creates a real blocking bead, but Gas City does not ship type-specific watchers for the accepted gh:run, gh:pr, timer, human, or mail labels. A person can close the gate manually, or customer automation can close it after the external condition is satisfied. The exact posture belongs to the customer.
This structure lets parallel work remain parallel without letting results bypass review. A fan-in step waits on every required child. A failed check can open a repair path. For code delivery, a reviewed pull request ready for human review is a sensible default outcome.
The worked pattern in Coordinate multiple AI coding agents shows how planning, isolated implementation, testing, and review fit together.
Run the kill test
Choose a small workflow with two parallel steps and one review gate. Start it against a disposable repository. Once an agent has claimed a bead and recorded some progress, terminate the process.
Do not restart the original chat first. Ask a fresh session to inspect ready, active, and blocked work. Watch whether it can explain the next move from the shared record.
That exercise will tell you where the orchestration actually lives. If recovery depends on one operator remembering the conversation, you have parallel agents. The orchestration system has not arrived yet.
Related articles
- Coordinate multiple AI coding agents: Apply the architecture to a feature split across worktrees, tests, and review.
- Agent orchestration evaluation rubric: Turn the failure model into a repeatable product test.
- Recover agent work after a crash: Follow the lease, reclaim, and replacement-agent sequence in detail.
- Software factory reference architecture: See where durable work, control, sessions, repositories, and events live.