Automation

Automation lets a workflow run when you are not there to provide the next instruction. That requires decisions you have been making informally. Is a result good enough to continue? What does the next step need? When should a failed attempt stop?

The previous pages established a plan and resolved its assumptions. They defined handoffs and checked the results. Start automating a workflow you have already walked through. Each intervention you made during that walkthrough is a decision the runner must handle or bring back to you.

Choose A Small First Boundary

Begin with a manually selected report for the bugfix workflow and stop at a patch ready for review. Let the runner gather context and reproduce the failure. It can then request a fix and run checks. Keep merging as a separate decision while you learn which reports this workflow can handle.

Start by invoking the runner yourself. Once you can inspect its results and understand its failures, connect it to a suitable trigger such as an issue receiving a particular label. Record which issue and revision a run belongs to. Have the runner check for an existing run before starting another. It should reserve the task before launching work so simultaneous events cannot both claim it.

Choose access according to the work the agent performs. An agent preparing a patch needs a working copy and a test environment. Give a separate step responsibility for merging if and when you automate that action, because preparing a valid patch does not by itself authorize changing the shared branch.

Separate Fixed Procedures From Agent Decisions

The runner is the program that starts stages and passes their inputs. It evaluates their results and records progress. Put fixed procedures there. The runner creates a task directory and launches the configured test command. It checks the exit status, then decides whether to allow another attempt.

The agent can investigate why the saved step order changes and propose a correction. It does not need to invent a new way to run the same test command on every attempt. Reusing a script makes the procedure inspectable and lets you test how the runner behaves when that procedure fails.

Instructions still explain what you want the agent to do. Enforce critical boundaries outside its discretion where possible. For example, the runner can require a successful test result before advancing. Repository permissions can prevent an implementation stage from merging its own patch.

Keep Progress Outside The Conversation

A new agent session needs you to supply the task's current state. Store the requirement and relevant decisions in a file or database the runner can read. Add the current code revision and completed stages, plus the check results and any unresolved work. Those records also let you investigate an interrupted run.

Attach the working branch and exact tested revision to a record like this, along with paths to the evidence. Record new check results against the new code after further edits. This lets you tell which result applies to the patch you are reviewing.

The agent may propose that a stage is complete. Have the runner advance the recorded state only after the required checks pass. A checked box in an agent-written plan is insufficient evidence for that transition.

Compare the saved record with the actual working copy and any external action already taken before resuming an interrupted run. A process can stop after creating a branch but before recording that it did so. Recovery must account for completed actions so restarting does not repeat them blindly.

Bound The Repair Loop

A verification failure sends the failing output and current patch to a repair attempt, along with the original requirement. Keep the acceptance criteria fixed during that attempt. If the requirement needs to change, stop and decide that explicitly.

One repair attempt is a reasonable starting choice for an initial local runner. Set time and usage limits as well and enforce them in the runner. A process that keeps launching fresh sessions can otherwise continue spending resources even though it has stopped making progress.

Distinguish failures that call for different responses. A reproducible test failure can go to the repair stage. Missing credentials or an unavailable service may require restoring the environment, while an unresolved product decision needs your input. Repeating the implementation step will not resolve all three.

On exhaustion or a blocked decision, stop with a useful record. Note what failed and what you attempted, plus the current code and where you stored the evidence. Make the status visible in a log or the local control panel. You should be able to tell a finished run from one waiting for review, and from one that stopped unexpectedly.

Test The Runner's Failure Behavior

Feed the workflow a failing test result before leaving it unattended and confirm that the next stage does not start. Try a missing input and an exhausted retry limit. Interrupt a local run, then check whether the stored state is sufficient to resume or stop it deliberately.

Inspect repeated failures across runs. If the implementer keeps missing an existing storage helper, improve the context supplied to that stage. If a defective patch passes, strengthen the relevant check. Fixing only the latest output leaves the same weakness in the next run.

September, 2026