Termination and Budget

In one line: a single agent has one stopping problem, and a multi-agent system has one per participant plus a global one nobody is holding.

The problem multiplies

Each worker is an agent, so each has the termination problem from the single-agent chapter: it cannot reliably tell whether it is making progress, and its stopping condition must come from code rather than from its own judgement.

Now there are several, running possibly at once, plus a supervisor deciding whether the overall goal is met. Four ways this goes wrong:

A worker that never stops consumes the shared budget while others wait.

A worker that stops too early returns a partial result that the supervisor treats as complete, because nothing in the handoff said otherwise — which is the missing "what I couldn't do" field from the interface lesson.

A supervisor that keeps dispatching because each round produces something and nothing declares the goal met.

A producer-critic pair looping, since a critic asked to find fault always can.

One owner

The structural answer, and it is the strongest argument for the star topology.

Exactly one component owns the goal. It holds the original request, decides whether it has been met, and is the only thing that can say the task is finished. Distributing that produces a system where each part reports success and nobody can answer whether the whole thing worked.

The same component owns the budget. Total steps and total spend, allocated to workers rather than held by them. A worker gets an allowance for its sub-task; exceeding it returns a partial result rather than continuing.

That allocation is the mechanism. Without it each participant reasons locally about its own effort, and local reasonableness sums to global excess — the same shape as any resource shared without a quota.

Allocating

Three approaches, in increasing sophistication and cost.

Equal shares. Simple, and wrong whenever sub-tasks differ in difficulty — which is always.

Estimated at decomposition. The supervisor assigns a budget per sub-task when it creates them. Better, and it depends on the supervisor estimating difficulty, which it does poorly.

Reserve and top up. Give a modest initial allowance; a worker that needs more requests it and the supervisor decides against what remains. More round trips, and it puts the decision where the global view is.

The third is usually right, with one refinement: a top-up request is information. A worker asking for double its allowance is telling the supervisor that the sub-task was underspecified or harder than assumed, and that signal is worth more than the budget decision itself.

Detecting global non-progress

The single-agent detectors work per agent. The system needs one more, because a set of agents can each be making local progress while the whole makes none.

The shapes:

Circular delegation. A hands to B, B finds it needs something from A. Each is working; nothing advances.

Repeated decomposition. The supervisor keeps splitting the same problem into slightly different sub-tasks, each of which returns something plausible and none of which closes the goal.

Oscillation. A producer-critic pair alternating between two states — the critic objects, the producer changes it back.

The detector for all three is the same one as in the single-agent chapter, raised a level: has the state of the overall task changed? Not whether agents are busy — whether the assembled result is closer than it was N rounds ago. Agents being busy is precisely what makes this hard to see.

Partial results

The output that matters when the budget runs out, and multi-agent systems have an advantage here worth using.

A single agent that fails mid-task has a trajectory. A multi-agent system has completed sub-results — three of five workers finished, and their outputs are independently useful.

So budget exhaustion should return the assembled partial: what was completed, what was not, and what remains. That is frequently most of the value, and a system that discards it because the whole did not finish has thrown away work that was already paid for.

Which is an argument for the interface carrying enough structure to assemble partially — a set of typed sub-results can be presented incompletely; a conversation cannot.

Cancellation

Briefly, because parallelism makes it non-trivial.

When the supervisor decides to stop — budget exhausted, user cancelled, a worker returned something that invalidates the plan — other workers are still running. Three requirements:

Workers must be cancellable between steps, which is the same discipline as the single-agent chapter.

In-flight work should be collected, not discarded. A worker cancelled at step four has four steps of results that may be useful.

Side effects must be reported. If any worker took an action that changed something, the final report enumerates it. A cancelled multi-agent task that quietly left three side effects is worse than one that ran to completion.

That third point is why write-capable workers should be rare and their actions ordered late — the same write-last discipline as the single-agent chapter, and more important here because several participants can be acting at once.

Next: what all this costs.