Work convergence

Work convergence is BMO’s runtime contract for task closure. A coding agent should not only produce a plausible next response; it should drive the current task toward an observable outcome: a durable workspace change or an honest terminal verdict.

In plain terms: BMO tracks whether the active work frontier is actually closing. If a task keeps reading, explaining, or retrying without moving toward the frontier’s closing condition, the runtime can constrain or stop the next provider turn instead of treating motion as progress.

What it answers

Question	Work convergence answer
”Did the task close?”	A durable mutation or terminal verdict is observed.
”Are these reads progress?”	Only when they advance the active frontier.
”Can the agent loop forever?”	Repeated read-only stalls are not credited indefinitely.
”Can a no-op write count?”	No. Authoring satisfaction requires a goal-relevant durable write.

This is a core distinction between an agent loop and an assistant-shaped REPL. A REPL can answer turns until the operator stops asking. BMO’s task-bearing runtime instead asks whether the frontier closed.

Two frontiers

BMO distinguishes the work shape before deciding whether another provider turn is allowed.

Frontier	What it means	Closing condition
Verifier recovery	The agent is recovering from a failed check, runtime contradiction, or blocked verification path.	A mutation or terminal output that resolves or honestly reports the fault.
Authoring / pipeline	The agent is gathering inputs before producing an artifact, edit, or declared output.	A goal-relevant, non-trivial durable write.

Artifact-producing recipe stages can also carry a typed authoring frontier: the declared input paths, declared output path, and resolved path aliases for that stage. That contract keeps authoring progress tied to the work the stage was actually asked to perform. A successful read of a declared input can advance the frontier; an unrelated read cannot. A successful write to the declared output can satisfy the frontier; an unrelated write cannot.

The distinction matters. If BMO applies the recovery model to authoring work, it can block legitimate read-then-write progress before the write happens. If it applies the authoring model to recovery work, it can permit a read-only diagnostic loop to run forever.

How enforcement works

Provider-turn admission reads convergence facts before allowing the next model turn. The active frontier can be:

pending when more bounded progress is allowed;
satisfied when the frontier has reached its closing condition;
unsatisfied or failed when continuation would hide drift or non-success.

The observable surfaces include:

lifecycle fields named work_convergence_*;
admission source work_convergence;
terminal error work_convergence_unsatisfied;
frontier field work_convergence_frontier;
typed authoring fields such as authoring_declared_input_fingerprints, authoring_declared_output_fingerprint, authoring_observed_input_fingerprints, and authoring_next_action;
constrained actions such as constrain_next_turn or deny_ordinary_continuation;
satisfied authoring actions such as finalize_without_provider_turn.

You usually do not need those fields during ordinary use. They matter when debugging why a long-running task stopped, why BMO refused another turn, or why a benchmark row was classified as non-success. The same facts can surface in run progress readouts, cue ledgers, and trace payloads without exposing raw local paths: authoring evidence is projected as bounded fingerprints and next-action labels.

Anti-gaming edges

Convergence is only useful if it cannot be faked by easy surface changes. BMO’s convergence checks preserve several boundaries:

No-op writes do not satisfy authoring. A durable write must be relevant to the goal, not empty or unrelated churn.
Write results must be observed. A mutating call that errors, is rejected, or has no successful tool result is not credited as a satisfying write.
Typed frontiers bind reads and writes. When a stage declares inputs and an output, only those declared reads can count as authoring progress and only the declared output write can close the authoring frontier.
Repeated reads do not self-certify forever. A read-only authoring phase must keep adding useful information. Re-reading already-observed targets can fall back to the recovery/deadlock model.
Indeterminate work defaults to recovery. Unknown work class does not silently get the more permissive authoring treatment.
Recovery dominates mixed evidence. A live failed-verification signal cannot be laundered into authoring just because an authoring hint is present.
Declarations are checked against behavior. A recipe or stage may declare authoring work, but observed runtime facts still determine whether that declaration is credible.

Relation to stigmergic delivery

Work convergence and Stigmergic Delivery are adjacent loops, not the same loop.

Concept	Governing question	Scope
Work convergence	Did this task close?	Runtime admission and terminalization
Stigmergy	What should future actors notice?	Workspace signals, routing, triage, and compounding

Stigmergy supplies environmental evidence: signals, zone pressure, causal packets, and prior outputs that can help BMO choose what to inspect or route next. Convergence keeps the current task accountable to an observable outcome.

The loops reinforce each other:

converged work can deposit signals that later agents discover;
stigmergic signals can point an agent toward the evidence needed to close a frontier;
multi-branch workflow convergence in the stigmergy COMPOUND stage is about synthesizing outputs, while work convergence is about whether one task-bearing run can keep taking turns.

Why it matters

Work convergence improves BMO’s behavior in places where ordinary chat loops are weak:

long tasks after compaction, where the model might otherwise keep re-establishing context;
verification recovery, where more diagnosis is not enough unless it leads to a fix or verdict;
artifact-producing workflows, where several pre-write reads can be legitimate progress;
benchmark attribution, where work_convergence_unsatisfied is a runtime control-plane outcome rather than a vague downstream failure.

The goal is not to guarantee every task succeeds. The goal is to avoid confusing endless activity with closure.

Boundaries

Convergence is strong but bounded:

It does not override explicit operator stops or approval gates.
It does not force unsafe writes across sandbox, credential, destructive, or policy boundaries.
It treats an honest terminal verdict as a valid outcome when the task cannot safely proceed.
It does not replace run observability; use Run Observability and Agent Debugger when you need the evidence trail for a specific run.

Stigmergic Delivery - workspace signals and indirect coordination.
Session Compaction - continuity across long context windows.
Run Observability - bounded runtime readouts for recent runs.
Agent Debugger - full event timeline for a run.