Make Multi-Agent Stage Boundaries Explicit and Restartable

A multi-agent workflow can look complete while leaving the next worker with no reliable basis for action. A message says that a stage is finished. A file exists somewhere. The next agent starts anyway. Then a missing field, stale assumption, or placeholder artifact appears much later, when the cost of finding the mistake is higher.

The useful design question is not only how agents divide work. It is how a workflow knows that one stage has produced enough evidence for another stage to begin, and how it can recover when that evidence is missing or no longer valid.

A stage boundary is a small contract between two pieces of work. It says what must already be true, what artifact proves it, who owns the next decision, and what should happen if the contract is not satisfied. Making that contract explicit turns a handoff from a conversational courtesy into a reviewable operating state.

Completion messages are not evidence

A completion message is useful as a notification, but it is not proof that the promised work exists in the required form.

Google Cloud described this sharply in its report on an autonomous film-crew experiment. A pilot agent reported completion with a 94-byte placeholder file. The experiment used verification gates at each of seven production stages, and its report says that shared files helped preserve decisions across crashes and restarts. The lesson is practical: a confident status update can be wrong even when the workflow appears to be moving.

The next worker should not have to infer readiness from tone, message order, or the existence of a filename. It should be able to inspect a bounded record that answers a few direct questions:

• Which prerequisite stage or stages are complete?
• Which exact artifact is being handed over?
• Does the artifact contain the required fields and content?
• When was the underlying information checked, and is it still fresh?
• Who owns the next transition?
• What may happen next, and what remains prohibited?

This is not a demand for a huge audit log. It is a request for enough durable evidence to make the next decision intelligible.

Treat waiting as a real state

Many workflows treat an agent that cannot proceed as failed, idle, or in need of another prompt. A better model distinguishes waiting for a declared dependency from being stuck.

The SyncPlan research preprint separates planning from execution and gives agents explicit wait primitives. It represents dependencies as a wait graph, detects deadlocks, and uses a Plan Staleness Detector to trigger selective replanning when execution or environmental state invalidates the remaining plan. Its experiments use Overcooked and Honor of Kings, so the reported results do not establish how the approach performs in a knowledge-work organisation. The useful idea is the boundary discipline, not a benchmark promise.

A waiting stage should name what it is waiting for and who can satisfy it. That prevents two common errors. One is premature execution, where an agent acts on a partial artifact because no one recorded that a prerequisite was still open. The other is busy coordination, where agents repeatedly send status messages without changing the underlying dependency.

A small stage record might distinguish blocked, waiting, ready, accepted, superseded, and rejected. Those labels should describe the state of the work, not the mood of the conversation. A worker can be healthy while its stage is waiting. A worker can report success while its artifact is rejected.

Make the artifact prove its own readiness

A stage boundary should validate the handoff artifact before it wakes the next stage. The validation can be modest: required fields are present, the format is parseable, the source references are attached, the result matches the requested scope, and the artifact has a stable digest. The important point is that the checks are declared before the handoff rather than invented after a later failure.

Google Cloud's account of its agent-team work describes messages containing file paths as a connection between active workers and durable state. Its ADK discussion also describes externalising high-cardinality schemas into a metadata registry and passing data through a deterministic validator before a handoff or downstream release. The report's claims about compliance and hallucination reduction are provider claims from a proposed architecture, not independent evidence. Still, the boundary is valuable: a downstream worker should receive a checked object, not merely an instruction to trust an upstream explanation.

The validator should not decide questions it cannot answer. A schema check can establish that a field exists. It cannot establish that the field is true, that a source is authoritative for the decision, or that a person has accepted a consequential action. Those are separate evidence and authority questions.

Preserve the prior plan when replanning

Replanning is sometimes necessary, but an unconstrained restart can erase the evidence needed to understand why the original path was abandoned.

A useful replan has an explicit trigger: a dependency deadlock, failed validation, stale external information, a changed constraint, or an owner decision. It retains the prior plan and records which condition caused the transition. The new plan can then be compared with the old one rather than presented as if it had always been the intended route.

This matters because a changed plan is not automatically a failed plan. An external fact may have moved. A participant may have added a constraint. A worker may have discovered that the selected tool cannot perform the required task. These cases call for different responses. Replanning can repair the path, recruit a bounded capability, or stop the workflow. It should not silently broaden authority or hide the point where the assumptions changed.

Restartability also changes what belongs in the durable record. Conversational history may help an agent understand context, but recovery should begin from the accepted artifact, stage state, dependency status, and validation result. If the original worker disappears, a replacement should be able to determine what has been completed without reconstructing every message that led there.

Keep human review at the meaningful boundary

A stage gate is not necessarily a person approving every intermediate sentence. It is a place where the workflow has enough evidence for a meaningful decision. Human review is especially important before an artifact becomes a shared plan, changes a participant's commitment, exposes private context, or triggers an external action.

The stage record should make the reviewable question explicit. Is the artifact complete enough to pass? Is the source current enough for this decision? Does the proposed next step stay within the granted scope? Has the responsible person accepted the business consequence? A technical readiness flag should not answer all four questions at once.

This separation keeps automation useful without treating a successful tool call as permission. A worker may have produced a valid file and still need a person to decide whether it should be shared. A stage may be technically ready and still be unsuitable because a constraint is unresolved.

Test the boundary before scaling the workflow

The smallest useful experiment is a short pipeline in which every stage produces a reviewable artifact and a machine-checkable readiness record. Start with a known task and inject ordinary failure modes:

• a worker crashes after writing part of an artifact;
• the artifact is present but missing a required field;
• two stages wait on one another;
• an external fact changes after planning; and
• a valid result reaches the boundary without business acceptance.

Compare the stage-based workflow with an ordinary message-driven handoff. Measure false completion, invalid handoffs, duplicate work after restart, detection of stale plans, time to owner intervention, unnecessary replanning, and whether a reviewer can explain the next permitted transition. These measures test recoverability and reviewability. They do not prove that a multi-agent workflow produces better substantive results than a simpler design.

For a future PatOS workflow, this is a bounded product hypothesis across Rides, Films, and Trips. Each stage could carry its prerequisite digest, required fields, freshness condition, owner, permitted transition, and acceptance state. That is a design to test, not a claim that the capability already exists. Any booking, payment, message, or other external action would remain separately authorised.

The useful unit is a restartable handoff

Multi-agent systems do not become dependable merely because they have more workers or more status messages. They become easier to operate when each stage has a clear boundary: wait for a named dependency, validate the artifact, preserve ownership, and record the reason for any replan.

The goal is not to prevent every interruption. Interruptions are normal. The goal is to make recovery start from evidence rather than optimism. When a worker fails, a fact changes, or a reviewer disagrees, the next person should know what is real, what is provisional, and what decision remains theirs.

That is the difference between a workflow that merely moves forward and one that can stop, explain itself, and continue safely.