Cadence: adaptive oversight for a coding agent — check less often while things go well, step in harder after a failure

LOOP (until the agent is done):
  agent proposes a step (thought + action)

  if I steps have passed since the last check:
    MONITOR (LLM) reads: task + steps since last check + proposed step
      → verdict: advisory | replacement + hint text

    advisory (healthy or minor slips):
      step RUNS → hint is added to the context
      → interval: I = min(I + 2, 20)

    replacement (lost sight of the goal, repeating failures):
      step is DISCARDED → hint into the context → agent redoes the step
      → interval: I = 5

  otherwise: the step just runs

Starting parameters: base interval 5, increment 2, maximum 20.

You can’t paste the original into a chat as a whole, so here’s the manual version: a monitor in a separate chat. The method shines where the agent takes many steps and can get bogged down: hunting a bug in someone else’s code, integrations, migrations.

Task: You’re using Claude Code to fix a bug in a Django online store. After a payment goes through Stripe, the order stays in “awaiting payment” status. The agent has spent 10 steps editing the webhook handler and rerunning the same tests, and they’re still red. You suspect it’s poking at the wrong file.

Prompt (in the second monitor chat, at the check step):

<Role>
You are a supervisor for a coding agent. You don’t fix the bug yourself.
You assess whether the work is going well and choose the type of intervention.
</Role>

<Task>
Bug: after a successful Stripe payment, the order stays in
“awaiting payment” status. Find the cause and fix it.
</Task>

<RecentSteps>
Agent steps 6–10 (thought → action → result):
6. Decided the webhook arrives with a different signature → edits verify_signature() → tests red
7. Edits verify_signature() again → tests red
8. Added logging to the handler → log is empty
9. Edits verify_signature() again → tests red
10. Proposes changing verify_signature() once more
</RecentSteps>

<HealthDefinition>
Healthy work: there is steady progress toward a solution; minor
slips in individual steps are possible.
Unhealthy work: the agent has drifted from the goal, there’s no progress, and
the same failed attempts keep repeating.
</HealthDefinition>

<Output>
Verdict: advisory OR replacement
Guidance: 2–4 sentences — what the agent should do next
</Output>

Result: The monitor will assess the latest steps and most likely judge the work unhealthy: the same kind of edits keep repeating with no result, and the empty log hints that the webhook may not be reaching the handler at all. You’ll get a replacement verdict and a short hint for the agent — for example, switch hypotheses and check the routing or receipt of the webhook. You don’t let the agent run the proposed tenth step and ask it to redo the step with the hint. You run the next check after 5 steps, not 10.

The weakness. A fixed check schedule has two problems at once. While the agent is doing well, frequent oversight means wasted tokens and distracting hints. Once the agent starts spinning its wheels, an infrequent check arrives too late: early errors drag later ones along, and by then they’re irreversible. Trigger rules (“looping,” “stuck”) catch only external symptoms. They miss errors like “editing the wrong code” or “the fix logic is wrong.”

The LLM’s strength. A model is good at reading a short slice of work and answering a narrow question: is there progress? Failure diagnosis is well represented in training text (debugging write-ups, forums), while long trajectories of recovering from errors are rare. The authors explain the success by the monitor’s job turning from “solve the task” into “assess the health of the latest steps.” That’s their hypothesis; they didn’t test it directly.

How the method exploits this. The monitor gets a narrow slice of the trajectory and a high-level “healthy / unhealthy” definition. The definition is deliberately not tied to error types: different agents handle the same error differently. The verdict also doubles as a “pulse” for the schedule. That gives you knobs:

• Base interval (5): lower it for short tasks, raise it for long and expensive ones.
• Increment and maximum (+2, 20): the interval grows only after advice. The higher the maximum, the lower the spend on a reliable agent.
• Two levels of intervention: if “replacement” is off the table (you can’t undo steps), keep only advice — but you lose the ability to break an error loop.
• Health definition: tailor it to your task type, but keep it at the level of “is there progress,” not “is there no error X.”
• A strong monitor: the authors stress that decomposition doesn’t replace a powerful model. A weak monitor stays weak.

The exact prompt from Fig. 4 of the paper isn’t reproduced in the available text. The template below is built from the description: it keeps the high-level health definition, the two levels of intervention and working with a slice of the trajectory.

<Role>
You are a supervisor for a coding agent. You don’t solve the task yourself:
you assess the health of the execution and choose the type of intervention.
</Role>

<Task>
{task_description}
</Task>

<RecentSteps>
Steps from the last check up to now (thought → action → result):
{recent_steps}
</RecentSteps>

<ProposedStep>
The step the agent is about to take (NOT yet executed):
{proposed_step}
</ProposedStep>

<HealthDefinition>
Healthy execution: the agent is making steady progress toward a solution;
minor slips in individual steps are acceptable.
Unhealthy execution: the agent has drifted from the goal; there’s no progress;
the same failed actions keep repeating.
Don’t judge by a list of specific errors — judge progress toward the goal.
</HealthDefinition>

<ReasoningLogic>
1. Compare the recent steps with the task goal: are they moving toward a solution?
2. Look for repeats: are the same failed attempts recurring?
3. Evaluate the proposed step: does it continue progress or deepen the failure?
4. If health is satisfactory → advisory.
   If unhealthy → replacement.
</ReasoningLogic>

<Output>
Verdict: advisory | replacement
Guidance: 2–4 sentences for the agent
  (advisory — how to proceed;
   replacement — why the step was discarded and what to do instead)
</Output>

Interval rule (for you or the orchestrator):

Start: check every {base_interval} steps.
After advisory: interval + {increment}, but no more than {maximum}.
After replacement: interval = {base_interval} again.

What to fill in: {task_description} — the original problem statement, {recent_steps} — the steps since the last check (copy them from the agent’s log), {proposed_step} — the step the agent wants to take. Intervals from the paper: 5 / 2 / 20.

🚀 Quick start — paste into a chat:

Here is a monitor template for a coding agent (the Cadence method). Adapt it to my task: [your task].
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask about the task goal, what your agent’s steps look like and how many steps a session usually takes. It needs this to tune the “health” definition and pick a starting interval. It will take the structure from the template and adapt it to your work.

⚠️ You need code, not just a prompt: full Cadence is a scheduler plus discarding a step before it runs. In off-the-shelf agents (Claude Code, Cursor) you can’t reproduce this by hand: at best, an imitation via a second chat and manually copying steps.

⚠️ One benchmark and one task type: testing covered only bug fixing in Python repositories. The authors say the method generalizes, but the available text doesn’t show this on other task types (new features, non-Python, untestable tasks).

⚠️ You need a strong monitor: decomposition doesn’t replace a powerful model. A weak supervisor model will misjudge health, and a wrong “replacement” verdict will throw out a good step.

⚠️ Extra tokens and calls: oversight costs money. The method is more economical than its competitors, but pricier than an unsupervised agent.

⚠️ The available text is cut off: the sections with ablations, parameters and failure analysis (RQ2–RQ4) weren’t included in the material. I can’t assess the contribution of individual modules or the failure cases.

First, the authors showed what’s wrong with existing approaches. They took 300 SWE-bench Lite tasks and ran the agent without oversight. That gave 145 solved and 155 unsolved tasks. Two experts manually reviewed every trajectory and confirmed the groups genuinely differ: in one, the agent stayed on task or recovered from minor slips on its own; in the other, irreversible failures piled up. Then they added a monitor with a fixed interval of 3, 5, 9 and 15 steps.

The picture came out as a mirror image. For “healthy” runs, success barely depended on the interval (≥88%), while tokens dropped as the interval grew (0.45M → 0.30M). For “sick” runs, infrequent oversight dragged the solve rate down from 23.87% to 14.19%. Hence the idea: the interval should depend on the agent’s state.

Next, they tested trigger rules using the LivePlan monitor. Of 300 tasks, the agent failed 152, and in 35 of those the monitor didn’t fire even once. Experts analyzed these cases and identified three types of undetected errors: wrong edit location, wrong logic and incomplete edit. All of them are reasoning errors, not external failures.

Cadence was compared against a fixed interval, LivePlan, static rules and an unsupervised agent, on two agents (mini-swe-agent and Moatless). Result: +76 solved tasks (+25.33 pp) on the first and +47 (+15.67 pp) on the second. Token spend per task: 1.03M vs. 1.47M for the strongest alternative on mini-swe-agent, and 0.48M vs. 0.51M on Moatless. An unexpected and useful practical takeaway: the problem isn’t “can the monitor give advice,” but when it gives it.

🔧 Technique: a manual “pulse” in the agent’s instructions → scheduled self-checks

If you use Claude Code or a similar tool, you don’t need a full external monitor. Ask the agent to run a stop-check on itself. This is my adaptation; the paper has no such version, and the effectiveness of self-checking wasn’t measured:

Every 5 steps, stop and run a health check:
1. Have I gotten closer to the goal, or am I going in circles?
2. Have I repeated the same failed action?
3. Am I editing the wrong place?
If all is well — write “ok” and continue; next check in 7 steps (then 9, up to 20).
If not — abandon the last step, switch hypotheses,
and run the next check in 5 steps.

The same “less often while things go well, more often after a failure” principle works for other jobs too: reviewing a long automation, multi-step research, editing contracts section by section.

• Paper: Cadence: Strategic Guidance for Coding Agents
• Authors: Minxing Wang, Yintong Huo (Singapore Management University); He Ye, Earl T. Barr (University College London)
• Benchmark: SWE-bench Lite (300 tasks)
• Agents in the experiments: mini-swe-agent, Moatless
• Compared with: Wink (periodic oversight), LivePlan (rule-based oversight)