PAUSE: One Plan from a Separate Model Before the Agent's First Code Edit

STEP 1: The Executor works as usual (reads, reproduces the bug, tests) → action history
STEP 2: The first edit to a source code file → blocked BEFORE it executes
STEP 3: The Planner (separate call, no tools) reads the task + history → one plan:
        root cause / what to change / how to fix it and why
STEP 4: The plan is added to the dialogue as a user message → the same agent continues
        (with the same context and files; the block doesn't fire again)

In the paper, steps 2–4 are automated inside the agent harness. The authors don't describe any separate manual requests.

Task: You run an online store on WooCommerce. The Stripe payment plugin sometimes fails to confirm orders after payment. You ask an agent (Claude Code or Cursor) to find the cause. The agent is already digging into the webhook handler on its own. You know that a weak agent loves to quickly "patch" the first suspicious spot.

This is a manual version of the method, not taken verbatim from the paper. The Executor is your agent; the Planner is a strong model in a regular chat.

Prompt for the agent (Executor):

Figure out why orders paid through Stripe sometimes stay in the
"Pending payment" status. Study the webhook handler code, logs, and tests, and reproduce
the problem with a script. DO NOT EDIT THE SOURCE CODE. You may create temporary scripts
for reproduction. When you've gathered enough data, stop and write:
what you read, what you ran, what you observed, which hypotheses remain.

Prompt for the Planner (in a new chat with a strong model, along with the report and logs):

You are a senior engineer. Below is the task description and everything the agent managed to study
and run before its first code edit. You cannot run code; rely only
on these materials. Write ONE fix plan:
1. The likely root cause (grounded in specific observations from the report).
2. What code needs to change, and where.
3. Exactly how to fix it and why this way.
4. What the plan is missing for you to be confident (if there are gaps).

Task: {bug_description}
Agent report: {agent_report}

Result: The Planner returns a short, structured plan of a few points, tied to what the agent has already read and run. You paste it to the agent as a message: "Here's the plan. Implement it and verify with tests. If you disagree, explain why." The agent continues in the same dialogue with the same files. It doesn't need to re-learn the project.

The weakness: once an agent starts editing, it clings to its first hypothesis. Each subsequent edit builds on the previous ones. The later it becomes clear the hypothesis is wrong, the more expensive it is to undo. On top of that, deep inside a long tool-use session it's hard for the model to "step back and look at the big picture."

The strength: by the time of the first edit, the history is already full of evidence: code that was read, command output, reproduction results. A separate model that sees only this history can easily pull the evidence together into one diagnosis. It doesn't need tools; it needs text.

How the method uses this: the intervention lands in the window when there's already enough evidence but no changes have been made yet. The authors verified that intervening too early gives the Planner too little material, while intervening too late arrives after the agent has already built on its edits, and the plan has to overturn all of it.

Control levers: - Timing of the intervention → the "first source edit" rule; earlier means too little data, later means the agent has already hit a dead end. - Who the Planner is → the stronger the model, the better the plan. Even a small Executor gets pulled up by a strong Planner. - Plan format → cause / what to change / how and why. Drop the "why" and it's harder for the agent to evaluate the plan critically. - Number of interventions → one. More planning isn't better: periodic checks cost several times more for comparable results.

The accessible text of the paper doesn't include the Planner's exact prompt. The authors only describe the output structure: root cause, code to change, the fix intent with justification. The template below is built from that description.

You are the Planner. You have no access to tools or files.
You see only the task and the agent's investigation history (code it read,
command output, results of its own tests).

<Task>
{task_description}
</Task>

<InvestigationHistory>
{history_before_first_edit}
</InvestigationHistory>

Write one fix plan:
<RootCause>what exactly breaks and why, citing observations</RootCause>
<WhatToChange>files, functions, locations</WhatToChange>
<HowToFix>the specific change and the reasoning behind the choice</HowToFix>

The plan is a recommendation. The agent handles implementation and testing.

Message to the Executor after receiving the plan:

Here's a fix plan from an external reviewer. They haven't seen your environment
and may be wrong. Take it into account, then implement and verify with tests. If you disagree
with a point in the plan, briefly explain why and do it your way.

{plan}

What to fill in: {task_description} — the bug or task text. {history_before_first_edit} — the agent's report or its log, without the source edits themselves.

🚀 Quick start — paste into the chat:

Here's a template for a two-stage "Planner + Executor" workflow (the PAUSE method).
Adapt it to my task: {your_task_and_agent_tool}.
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what agent and environment you use, what the task is, what the agent should study before editing, and in what form you pass it the history. That way the Planner gets enough evidence, and the agent's instructions account for what your tool can do.

⚠️ Implementation requires harness setup: in the paper, intercepting the first edit is built into the agent harness (OpenHands, SWE-agent). Manually, you can only imitate it by asking the agent to stop and copying the history into a chat.

⚠️ Tested only on bug fixing: all results come from SWE-bench tasks (real bugs from GitHub repositories). Results for new features, refactoring, and unusual tasks weren't measured.

⚠️ The Executors are small open models: the main gains come from two mid-sized models (around 30B parameters). How much the method helps the strongest agents isn't clear from the accessible text.

⚠️ No edits, no intervention: if the agent never tries to edit source files (about 5% of runs), the method doesn't fire.

⚠️ The Planner is blind: it doesn't run code or read files; it sees only what the agent managed to read. If the investigation was shallow, the plan will be confident but wrong.

⚠️ Offline recovery after failure: it requires the record to contain the agent's explicit reasoning steps ("think") and the file state to be exactly restorable. Some failed runs don't qualify.

⚠️ The paper is truncated: the accessible text lacks the results of the control experiments (self-revision without an external plan, different intervention points, full regressions). Conclusions about them rest only on the authors' claims in the introduction.

First, the authors analyzed 500 recorded agent runs on SWE-bench Verified. They wanted to understand when it makes sense to intervene. It turned out that the first edit to a source file comes on average at 60% of the trajectory, and in 80.5% of runs it comes after the midpoint. Before that, the agent mostly reads files (31% of actions) and runs commands. That gave rise to the idea: intervene right there, while there's plenty of evidence and no edits yet.

Then the method was tested on two sets: SWE-bench Verified (500 Python tasks) and Multilingual (300 tasks in nine languages), with two small Executors, three agent harnesses, and five different Planners. It was compared with a plain agent and with two oversight approaches: LivePlan (calls an advisor when rules detect looping or stagnation) and SICA (an overseer periodically reviews progress). Online intervention results: gains in solved tasks of +16.8% (OpenHands, Verified), +14.8% and +14.7% (SWE-agent, Verified and Multilingual). Against LivePlan, PAUSE wins by 3.2% and 3.7% at a similar cost. Against SICA the results are comparable, but the Planner costs only 11–15% of what SICA does.

In offline mode, they took runs that had already failed, rolled them back to just before the first edit, added a plan, and let the agent finish. Out of 223 eligible failures, 79 were fixed (35.4%). Resuming from the recorded point used 33–41% fewer Executor tokens than restarting from scratch.

The surprise: a single well-timed intervention is on par with constant oversight and several times cheaper. Practical takeaway: what matters isn't how many times you check the agent, but where in the trajectory the check happens.

These aren't from the paper; they're my own ways of applying the principle.

🔧 Technique: a hard stop signal in the instructions → manual imitation of the intercept

In the agent's instructions file (CLAUDE.md, AGENTS.md), write:

Until you receive the message "Plan approved" from me, DO NOT modify files
in the src/ and app/ folders. You may create temporary scripts for reproduction.
When you've gathered evidence, write a report: what you read, what you ran, what you observed,
which hypotheses remain — and stop.

This replaces the paper's programmatic intercept with a rule in words. It's less reliable: the agent can break the rule. But you get a natural point where you can hand the report to a strong model.

Extrapolation: a strong chat model as the Planner for any "long" job

The same setup works beyond code. In a long research or analysis assignment, ask the agent to stop before an irreversible step (emailing customers, publishing, bulk data changes). Hand its report to a second model with this request:

You can't see the sources, only the agent's report. Tell me: what conclusion suggests itself,
where the evidence is thin, and what needs to be double-checked before publishing.

• PAUSE: Search-Free Steering of Coding Agents Before Their First Source-Code Edit — Viral Patel, Boyin Tan, Jason Xue, Youcheng Sun (Mohamed bin Zayed University of Artificial Intelligence, UAE)
• Benchmarks: SWE-bench Verified, SWE-bench Multilingual
• Agent harnesses: OpenHands, SWE-agent
• Comparisons: LivePlan, SICA, SWE-PRM, SHERLOC