How do I know when a cascade of delegating agents has actually finished?

Why the obvious answers are all wrong¶

“Wait until nothing has happened for N seconds.” This is a bet that no agent in the fleet will ever pause longer than N. It is wrong in both directions: a slow model call makes you declare completion early, and a genuinely finished fleet makes you wait N seconds for nothing. Tuning N does not fix it, because the correct N depends on the run.

“Wait until every agent reports done.” An agent that has spawned children and is awaiting their results is not done, and an agent that returned before its delegate finished is done while its work is not. Local completion does not compose into global completion.

“Wait until the task queue is empty.” An empty queue is a snapshot. A message in flight — dispatched, not yet received — is work that exists and is in neither the queue nor any agent. Sample at the wrong instant and you see zero everywhere while the cascade is very much alive.

“Wait for the stream to close.” A closed stream tells you the transport ended. It does not tell you why. A cancelled task, a crashed peer and a completed one can all present as a closed stream, and treating them alike is how a fleet reports success on work that was killed.

What the problem actually is¶

This is distributed termination detection, and it has a precise definition: the computation has terminated when every process is passive and no messages are in transit. Both clauses are necessary, and the second is the one every homegrown solution forgets.

It is a well-studied problem with known-correct algorithms — the credit and weight-throwing schemes, Dijkstra–Scholten for diffusing computations, the various wave and vector-counter approaches. They differ in cost and in what they assume about the channels, but they share the structure: a conserved quantity that is split when work is delegated and returned when it completes, so that global quiescence is detectable from a local condition rather than inferred from silence.

An agent fleet is a diffusing computation. One root delegates, delegates delegate, and the tree’s shape is not known in advance. That is the exact case these algorithms were designed for. The literature is old, correct, and almost entirely unread by the current generation of agent frameworks.

What a correct answer requires from your system¶

Three properties, and if any is missing no protocol will save you.

1. Delegation is observable. The moment an agent hands work to another, some accounting has to record it. If a sub-agent can be spawned without the system knowing, its work is invisible and quiescence is unprovable.
2. Completion is reported, not inferred. A returning call, a closed connection and an exit code are not completions. An explicit completion signal that names what completed is.
3. Cancellation and failure are distinguishable from success. Otherwise the detector correctly reports that the cascade has stopped, which is true, and you read it as finished, which is not.

Property 3 is where most real systems break, and it is usually a teardown bug rather than a design one. Shutdown paths get less attention than happy paths and are where completion signals are most often lost.

The two things to do¶

Instrument the delegation edges before you build any detector. You cannot detect termination of a graph you cannot see, and most fleets do not currently record who handed what to whom.

Then adopt a real protocol rather than a heuristic. Stillpoint exists because this is a solved problem being re-solved badly: it detects the quiet point of a delegation cascade soundly, rather than waiting out a clock. The related work in that lane also produced a concrete instance of failure mode 3 — a teardown deadlock diagnosed in Google’s A2A reference SDK and fixed upstream, in a2aproject/a2a-python PR #1105, merged on 2026-07-20.