Executing a plan and reviewing its results

Stay in the loop while an agent runs the plan

An agent can run a plan from start to finish. The researcher who owns the question still has to understand what was done and why, and the agent still needs the researcher's judgment about what matters.

Steering. Each pause is a point to redirect: reorder the remaining experiments, add a control, or drop a branch whose answer no longer matters. Steering is cheapest before execution, which is why the preview comes first.

Course correction. An agent can finish a job that measured the wrong thing, and a clean exit does not reveal it. Reviewing each result before the next experiment starts catches the defect while it costs one experiment instead of a campaign.

Understanding in both directions. Dialogue carries the researcher's intent to the agent: which result would be surprising, which shortcut would invalidate the test. Stepped execution and walkthroughs carry the agent's work back. The agent explains each design before revealing its result, so the listener can predict the outcome first and notice when it surprises them. A researcher catching up on work that ran unattended learns the evidence that way. A student learns the method along with it: why this control, why this order, what would have counted as a null. The same pauses let the student question the agent.

When the design is settled and the work is routine, use continuous execution followed by a walkthrough.

Preview the proposed work

A plan preview explains the question, proposed experiments, dependencies, controls, decision rules, and expected resource use. It identifies assumptions worth challenging before execution. Previewing is read-only: it does not promote the plan, edit its files, submit jobs, or acquire responsibility for executing it.

Use research-lab-notebook to preview PLAN_PATH. Explain its objective, experiments, controls, dependencies, decision rules, costs, and uncertainties. Do not execute it or change any files.

Ask what observation could distinguish the competing explanations, what would count as a null result, and whether the instrument can reach the phenomenon.

A resource and spend preview reports the baseline estimate, conditional branches, and uncertainty in units, and derives incurred and committed spend from plans/spend/. Check headroom against the approved ceiling before proposing additional work. A read-only preview can discuss those records but cannot update them or reserve paid resources.

Execute interactively and pause after each experiment

Choose stepped when you want the conversation to shape the next experiment. It suits a plan whose later experiments depend on judgment about earlier ones, and a researcher or student who wants to learn the method while the evidence arrives. The agent performs the authorized work and records its results in the notebook before presenting them. It explains the original design and setup before revealing the findings, then stops until you say to proceed.

Use research-lab-notebook to execute PLAN_PATH in stepped mode. After each experiment, explain its original design and setup before its findings. Discuss validity, limitations, and the proposed next action, then wait for me. Do not queue the next experiment while waiting.

The pause is per experiment, not automatically per job. One experiment can contain a pilot, several execution attempts, or a sweep. Request additional job-level checkpoints if you need them. Parallel work must not start the next experiment before your reply.

Use the pause to ask: did the code implement the intended design? Did that design measure the intended quantity? Does the result support the proposed conclusion?

Execute continuously within the approved scope

Continuous execution removes routine conversational pauses. It still stops at missing authority, required human review, scientific gates, and resource limits. Calling a run autonomous does not approve additional spend, a changed design, or a larger study.

narrated is the default execution mode: the agent reports each result and what it changes without waiting for a reply. Choose handoff for a terminal report, or unattended for notebook-only reporting. Name the mode explicitly to set the reporting and pause behavior.

Use research-lab-notebook to execute PLAN_PATH in narrated mode within its approved scope and budget. Report each result without waiting for a reply, but respect all required gates. When execution stops, begin a results walkthrough using the saved records and outputs. Do not rerun jobs during the walkthrough. Pause after each experiment for discussion.

This request authorizes execution followed by a read-only results walkthrough. Asking only for a walkthrough or replay authorizes no execution. A blocked or partly complete plan can still be reviewed using the available evidence, with missing work identified.

Preparing a script can itself use an autonomous review/repair cycle. That cycle's permission to edit and review does not authorize an experiment run. Its execution and scientific-decision handoffs remain explicit, even when the surrounding plan uses continuous reporting.

Walk through existing results

A results walkthrough, also called a replay, uses saved records and outputs. It never launches, retries, or reruns jobs. It also does not repair scripts or recompute measurements to fill gaps in the account. A walkthrough can cover an incomplete or completed plan without executing it first.

Use a walkthrough to understand work that ran without you, to check an interpretation before it becomes a claim, or to bring someone joining the project through the plan's evidence in the order it was built.

Use research-lab-notebook for a results walkthrough of PLAN_PATH. Use existing records and outputs only. State how many experiments are available, then take them in dependency order. Explain each original design before its findings, and stop after each experiment for discussion. Do not run jobs, recompute results, or change files.

1. Establish the inventory. Identify the experiments, their dependencies, and any missing records or artifacts. Say how many experiments the walkthrough will cover.
2. Recover the original design. Explain the question, setup, controls, predictions, and what would have counted as a null. Distinguish the proposed method from what actually ran. Use the record from before the results, where available.
3. Present the findings. Show the observed result, uncertainty, validity checks, and limitations. Explain what became apparent during execution or only afterward. Identify the records and artifacts behind the account.
4. Discuss the interpretation and possible repairs. Separate established evidence from retrospective explanations and untested proposals. Stop here until the user asks to continue to the next experiment.

If the original design or an output is missing, the agent says what it cannot establish. It does not infer a preregistration from the results or silently regenerate missing output. Dependency order explains why later experiments were undertaken; it need not match the order in which jobs finished.

Decide which repairs to authorize

A walkthrough can uncover a coding defect, an inadequate design, a mistaken interpretation, or a claim that exceeds the evidence. Discussing a possible repair does not authorize executing it.

Decide separately whether to record a review correction, revise the design, or run a new experiment. Record an authorized correction with its reason and effects on downstream claims. Preserve the original prediction and distinguish planned from executed work. Follow the evidence-repair workflow for updates and the experiment-review workflow before collecting new evidence.