An engineer and an orchestrator robot plan work while two agents implement and review changes.

Every software engineer who uses AI should build their own stack when working with AI agents. Let us call this Y(our) Stack, because its tools, skills, and verification steps fit the way you work.

Start by reading Poteto’s post about pstack. Then close the post and try to rebuild the workflow yourself, without looking back at it.

This is like learning from a coding video tutorial in our early days as software engineers. We watch someone build something, then try to build it again on our own. When we have to make the decisions ourselves, we find out which parts we understand and which parts we need to study further.

Rebuilding a stack gives us the same opportunity. We can form an opinion about which parts fit our work. Ask yourself: “Do I need this stack?” “Do I need every part of it?” “How can I add verification?” “What evidence would give me confidence in the result?”

Being critical is part of the exercise. Each question helps you decide what belongs in your own stack.

For workflow, chart is better

I find it easier to understand the general flow when I draw a chart instead of writing every detail in a Markdown file. A chart helps me see how the steps connect and where a decision changes what happens next.

This is the chart that I use for my own personal workflow:

Workflow decisions and retries: independent review and required checks apply to the current commit. Failed checks or requested changes return to fixes and review. After merge, unfinished requirements lead to a follow-up PR; completed requirements lead to cleanup. Start with something small. Verify that it works. Then expand it.

In my case, we started with an agent working on one task. From there, we questioned the quality of the result. Did it meet the requirements? How could we check it? Which problems still needed me to find them?

We added more verification so that the process needed less of my direct involvement. The checks needed to give us useful evidence before we could trust the process with more work.

Let me tell you how I figured out my own stack.

At first, I had to supervise every task. For each task, I defined the work, asked an agent to implement it, and waited for the result. Then I checked the result and gave follow-up instructions. With 10 tasks, I had to repeat this process 10 times.

Today, instead of supervising 10 agents, I can focus on one agent that coordinates the others: the orchestrator. It asks for my attention only when it finds an issue that needs my input. It asks me questions while it continues to coordinate other work.

I no longer need to direct every step for every task. The orchestrator can coordinate several tasks in parallel: one agent defines an issue, another implements a task, and a separate agent reviews completed changes. Each task still needs a defined scope before implementation and completed changes before review. I review the results when they are ready. I still decide the scope and whether to merge the result.

Before: a confused man receives separate requests from many robots. After: a smiling orchestrator lists important questions and completed implementation, verification, and code review tasks.

The orchestrator coordinates work across tasks. Those tasks can run at the same time. My review remains a separate step.

In my stack, I still review my agents’ work. Some people stop reviewing the results after they add many verification steps. I prefer to keep this review because I want to shape the final result.

Once a small workflow works well enough, you can scale it. You can also look for a step that still needs manual work and decide whether to automate it. Check the result of each change before you expand again.

The way I shape my stack is influenced a lot by how I play Factorio. I start with one assembler. I supply its materials and check its output. Once it works, I connect the next part. As the factory grows, I develop the floor plan around the production process.

Start small with one assembler, verify its output, then expand to a connected production line.

I use the same method for my agent workflow. Each expansion builds on a process that I already understand.

Set the scope, implement, verify and review, then review and finish. Requested changes repeat implementation and review. Unfinished work needs a follow-up. I give a request. A coordinating agent checks notifications, selects authorized tasks, and assigns them to available workspaces. Implementation agents make the changes. A separate agent reviews the current changes, and the required checks must pass for those changes. Then I review the pull request and decide whether to merge it. After merge, the agents check that all task requirements are complete and clean the workspace.

This chart shows the main steps. The full workflow grew through several iterations. It now includes rules for parallel tasks, independent review, unfinished work, and cleanup.

Building the process step by step takes time. It gives me confidence because I can explain why each step exists, what evidence lets the agents continue, and when they must wait for me. It also gives me a basis for deciding what to change next.