Monotonic Progress

Pattern: A named solution to a recurring problem.

Keep an agent’s authorized objective fixed, and require every action to shrink the work or uncertainty that remains.

Also known as: Spiral In, Scoped Convergence

An agent can be busy for hours without getting closer to done. It discovers a weak test, then an awkward helper, then a stale dependency, then a deployment script that could use a rewrite. Every observation is real. None advances the task.

Monotonic Progress applies a stricter test: after each action, the remaining distance to the agreed finish line must be smaller or better understood. If the agent can’t show that change, it stops or asks for a new decision.

Understand This First

• Acceptance Criteria — the checkable finish line that must stay fixed during the run.

• Steering Loop — the act, sense, decide, and adjust cycle that this pattern keeps pointed at the finish line.

Context

This pattern matters when an agent works across many turns, tools, files, or delegated workers. Long tasks expose work outside the original request. Some discoveries are necessary prerequisites. Others belong in another task. The difficult part is telling them apart while work is underway.

A fixed objective doesn’t forbid adaptation. Tests can reveal that the planned implementation is wrong. A missing dependency may need repair before the requested feature can work. The objective stays fixed while the route changes in response to evidence.

Problem

How do you let an agent respond to what it learns without letting every discovery enlarge the task?

Activity is a poor proxy for progress. A larger diff, a longer plan, or another round of research can increase effort while leaving the finish line untouched. Agents are especially prone to this because each new clue offers a plausible next action, and plausibility isn’t the same as necessity.

The failure compounds through delegation. One agent finds a tangent and hands it to another. The second agent treats the handoff as authority, discovers more work, and passes that onward. By the time anyone checks, the chain is solving a different problem with the confidence of a team following orders.

Forces

• New evidence can invalidate the planned route without invalidating the objective.

• Necessary prerequisite work may look unrelated until its causal link is made explicit.

• Useful tangents deserve capture, but pursuing them now steals attention from the authorized task.

• Some completion criteria depend on judgment, so no single numeric measure can prove progress.

• A loop that can’t detect stagnation will convert time and tokens into increasingly polished churn.

Solution

Define the finish line, expose the remaining work, and admit only actions that bring them closer together. Before the run begins, record the authorized objective and its acceptance criteria. Treat changes to either as a new decision, not an implementation detail.

Keep a small progress ledger outside the conversation. For each criterion, record whether it is open, blocked, or satisfied. Put each blocking unknown beside the criterion it prevents. The ledger turns progress into evidence: satisfy a criterion, shrink its remaining work, or resolve an unknown that blocks it.

Before taking a material action, ask which criterion it advances. If the answer is “none,” ask whether it resolves a named blocker. If neither is true, capture the idea once in the project’s backlog and return to the task. Don’t investigate the tangent enough to make the backlog entry impressive; a title and the evidence that exposed it are usually enough.

Necessary prerequisites pass the same test. State the causal link: “Criterion C can’t pass because dependency D is missing; repairing D is required to test C.” Keep the repair no broader than that link requires. Once C can proceed, prerequisite authority ends.

At each steering point, compare the ledger with the previous one. Continue only if a criterion moved closer to satisfied or a blocking unknown became narrower. Stop and escalate when repeated iterations leave the ledger unchanged, the next action needs new authority, or evidence shows the agreed finish line is wrong.

Tip: Ask the agent to finish every progress report with two lines: “Criterion advanced” and “Remaining blocker.” If it can’t fill either line with something concrete, another iteration probably won’t help.

How It Plays Out

A developer asks an agent to add CSV export to an admin report. The acceptance criteria cover column order, escaping, authorization, and a 10,000-row case. While reading the report code, the agent finds duplicated date-formatting helpers across six modules. Consolidating them would improve the codebase, but it advances none of the four criteria. The agent records a refactoring ticket and leaves the helpers alone. It changes the one formatter used by the export, runs the four checks, and finishes with a small diff.

During a database migration, the test suite reveals that the staging fixture has no example of the legacy null value the migration must handle. Adding that fixture isn’t scope creep: the null-handling criterion can’t be verified without it. The agent states the link, adds the narrow fixture, and resumes the migration. When it notices that the fixture factory’s API is clumsy, it records that separately instead of redesigning the factory mid-task.

An outer loop is clearing a set of type errors. The first four iterations reduce the error count from 83 to 19. The next three move errors among the same files without reducing the count or retiring any uncertainty. The loop doesn’t grant itself more time because each diff looks reasonable. Its progress ledger is flat, so it stops and surfaces the architectural dependency cycle that now needs human judgment.

Consequences

Benefits. Work becomes easier to supervise because every material action has a visible relationship to done. Tangents stop disappearing, but they also stop hijacking the current run. Delegated agents inherit a stable objective, and stagnant loops fail loudly instead of consuming their full budget.

Liabilities. The pattern adds bookkeeping, and a crude progress measure can reward the wrong behavior. Error count, lines changed, or checklist items closed are only proxies; an agent can improve the number while harming the system. Criteria that depend on taste or product judgment still need a human decision. The discipline also resists opportunistic cleanup, so teams need a backlog they trust enough to defer into.

The most important cost is restraint. Sometimes the newly discovered problem really should replace the original task. Monotonic Progress doesn’t forbid that change. It requires someone with the authority to make it explicit.

Bounded by: Bounded Autonomy — Autonomy bounds determine which progress-making actions the agent may take without escalation.

Bounds: Delegation Chain — Every link must preserve the original objective instead of enlarging it while passing work downstream.

Depends on: Acceptance Criteria — Acceptance criteria define the fixed finish line that each action must approach.

Informs: Loop Engineering — The monotonicity test distinguishes a converging outer loop from one that merely keeps producing activity.

Mitigates: DWIM — Requiring a causal link to a completion criterion blocks plausible but unauthorized interpretations of the task.

Refines: Steering Loop — Monotonic Progress adds a per-iteration progress test to the steering loop's continue, adjust, or stop decision.

Uses: Externalized State — Externalized state makes the remaining-work measure inspectable instead of leaving it in the agent's context.

Uses: Progress Log — A progress log preserves completed criteria, blocking unknowns, and deferred tangents across turns.

Sources

• Dafny’s termination tutorial explains decreases clauses: bounded measures that must become smaller as a loop runs. Monotonic Progress adapts that structure from program execution to agent work.

• The Agile Manifesto’s principles name working software as the primary progress measure and simplicity as maximizing work not done.

• The Kanban Guide develops the practice of limiting work in progress and finishing started work before pulling more into the system.

• The Project Management Institute’s discussion of scope creep distinguishes unauthorized expansion from an approved scope change.

• The MIT AI Lab’s archived description of yak shaving names a chain of apparently unrelated prerequisites. The causal link to the original task is what separates a necessary shave from a tangent.

• Chieh-En Liao’s 2026 preprint applies the term monotonic progress to autonomous agents and contrasts it with procedural stagnation.