Workflows / Pipelines

Planning and questioning establish what should happen. A workflow makes the work repeatable. It fixes how the work begins and what each step produces, then what to check before the next step starts. You can follow one manually before writing any automation. A pipeline implements that flow by passing work between stages. A stage might be an agent investigating code or a script running tests. It could also be you reviewing a proposed change. The handoff matters because the next stage will make decisions using whatever the previous stage left behind.

Follow A Bug From Report To Review

Suppose the pipeline editor now exists and someone reports that saved steps reopen in the wrong order. “Fix the bug” is the overall task. Break it down far enough that you can tell whether each part has produced what the next part needs.

1. Reproduce the problem. Start with the report and the current code. Produce a sequence of actions or a failing test that shows the order changing.
2. Locate the cause. Trace the steps through saving and loading. Record where the order changes. Note the proposed correction and how to verify it.
3. Implement the fix. Make the change in an isolated working copy and add a regression test that detects the reported failure.
4. Verify and review. Run the relevant checks and inspect the changes, then prepare a patch with the evidence review needs.

The trigger here is accepting a bug report for investigation. The exit condition is a reviewed patch ready for a decision about merging. Specify that boundary: a pipeline that prepares a patch and one that merges it have different responsibilities.

Make Each Handoff Useful

The investigator should leave enough evidence for the implementer to reproduce the failure. “Confirmed, looks like storage” is insufficient. Record the input order and the observed output order. Note the command or actions used and the version of the code inspected.

Pass along the relevant requirement and evidence, plus the files. The implementer needs to know what failed and what behavior to preserve. It rarely needs every search result and abandoned explanation from the investigation.

Store these outputs where later stages can read them. A task directory might hold the report and plan, plus the patch and test output. If one stage starts in a fresh session, give it explicit access to those files. Information from another conversation will only help if the system supplies it.

Check Before Advancing

A gate is a check that decides whether work can move to the next stage. Require observable evidence of the reported failure at the reproduction stage. If the agent cannot reproduce it, route the task back for more information instead of starting a speculative fix.

Choose the check according to the decision. A script can compare saved and loaded step order. An agent can inspect whether the patch follows existing conventions, and a person can decide whether a proposed behavior change is acceptable. An agent's review is still a judgment that may need supporting evidence.

The gate must control the transition. If tests fail but the next stage starts anyway, the tests have only reported a problem. A runner should inspect their result and stop or route the failure to a defined repair step.

Some operations need no model judgment. A script can handle creating a task directory, parsing a known file format, or running an established test command. Use the agent where the work requires investigation or interpretation. Keep fixed procedures explicit.

Give Failures Somewhere To Go

A failed check should produce useful input for the next attempt. Pass on the failing command and its output, plus the current patch and the requirement you are testing. Returning only “try again” asks the agent to repeat the work without explaining what went wrong.

Set a limit on repair attempts. For a small local bugfix pipeline, you could allow one repair attempt and then stop for review. Choose the limit deliberately. Stop sooner when the missing input is a product decision or access the agent does not have.

Parallel stages are useful when their work is independent. Documentation review and code inspection can happen at the same time. Two agents changing the saved data format need an agreed interface and a plan for integrating their changes; separate successful outputs do not establish that the combined application works.

September, 2026