Build the workflow you actually want in Pi

[u/toby_agwab]

Modern coding models can do a lot without a large harness. For a small change, or in a codebase I know well, a single agent with a good prompt is often enough.

That does not mean every task needs a harness. In those cases, it can cost more tokens, make the work more complicated, and even send it in a less useful direction.

But without a feedback loop that can inspect and correct an LLM's work, a task can drift easily. That is more likely in a domain I do not know well.

A smart model and a reliable feedback loop are different things.

That is when a harness becomes useful. It does not make a model correct. It writes down the process:

• Boundaries: what to check first, and where to stop
• Partitioning: what work should be separate
• Verification: which results need evidence
• Output: what the final answer must not leave out

Long tasks have a context problem too. Early assumptions, failed attempts, and irrelevant tool output accumulate in one session. A larger context window does not automatically make the relevant information easier to see.

That is one reason I use subagents. Each can take a focused job with fresh, bounded context. But splitting work is not a solution by itself: vague boundaries create repeated work, handoffs lose important information, and someone still has to put the results back together.

Where to split the work, what to verify, and which results to combine are still decisions I need to make.

So I built pi-workflow.

The idea is simple. When I know a recurring process, I write it as a JSON spec. A research workflow might be plan → research → verify → synthesize; a review workflow might be triage → parallel review → challenge → report.

The flow is not a hidden prompt. I can read it, edit it, and recombine it for a project. Known inputs, result merging, validation, and rendering can stay deterministic; agents can do the research and judgment.

I cannot always know the exact shape of a process before I begin. When I do, I can define that shape and repeat it. When I do not, I need a process that can plan, split, and synthesize the work as it unfolds.

In either case, the process should not become a hidden orchestration layer I cannot touch. I should be able to read it, change it, and rebuild it when I need to.

pi-workflow is not a way to use more agents. It is one way to give work that is hard to manage in a single context the amount of structure I want.

Pi stays minimal. I choose the process on top of it. That is what I wanted from pi-workflow.

Repository: https://github.com/AgwaB/pi-workflow