Multi-agent development workflow

Context

A development team shipping features for a multi-tenant HR platform, with several tasks running at the same time.

The challenge

Shipping a feature takes many kinds of work: planning, research, design, code, tests and review. Done one after another by the same person, most of the time goes into waiting and switching between them.

My role

Designed and set up the whole agent workflow.

How I approached it

1. I split the work into the same stages a human team uses and gave each stage to its own specialised agent.
2. I added a CTO agent as the single point of contact: it breaks a request into tasks, assigns them, checks results against the goal of the feature and asks me when a decision really matters.
3. I ran separate chains of agents in parallel, so one task is being tested while the next one is already planned.
4. I kept a review step that can send work back, so that speed does not simply produce more bugs.

What I built

• A CTO agent that manages the whole team and reports back to me
• A vertical structure of subagents: planning, research, design, development, testing and review
• Parallel agents working on separate tasks at the same time
• Clear hand-offs so each agent owns one step and passes its result on

The team: who does what

The workflow follows the same stages a human team would use, and each stage has its own specialised agent:

• CTO agent: the only agent that talks to me. It takes my request in plain language, breaks it into tasks, assigns each one to the right specialist, decides what can run in parallel, checks every result against the goal of the feature and escalates the decisions that change the product, the architecture or the cost.
• Planning agent: turns a request into clear tasks and acceptance criteria.
• Research agent: reads the existing code and documentation, and finds what the change will touch.
• Design agent: proposes the approach before anything is written.
• Development agent: writes the code for one task.
• Testing agent: writes and runs tests for that code.
• Review agent: reads the result like a strict colleague and sends it back if it falls short.

How a feature flows through the team

A typical feature goes through the same path every time:

• I describe the feature to the CTO agent in plain language.
• The CTO agent breaks it into tasks with acceptance criteria, and the planning, research and design agents prepare each one.
• Development agents build the tasks, several at the same time, each on a separate task.
• Testing agents write and run tests, and the review agent checks the result and can send it back.
• The CTO agent checks the whole against the goal of the feature and gives me one summary. I make the final review and the decisions that matter.

What keeps it reliable

Speed is only useful if the result can be trusted. Four habits make the difference:

• Small, specific instructions: an agent with one narrow job is easier to guide and to check.
• A review step that can say no: without it, speed just produces more bugs.
• Clear hand-offs: each agent states what it did, what it assumed and what is left.
• A human in charge: the CTO agent manages the team, and I manage the CTO. I own the decisions, the architecture and the final review.

Why I built it myself

I chose to build my own workflow instead of using a ready-made framework such as Superpowers. My reasons:

• My agents carry the conventions of my codebase and the checks I always run, so they start with context instead of rediscovering it.
• The CTO agent decides how much process a task deserves: renaming a button and designing a payment flow do not need the same ceremony.
• I own every rule: when an agent does something I don't like, I can open its instructions and change them.

What it brought

Productivity went up by 400%. I now spend my time deciding and reviewing instead of waiting, and the CTO agent gives me one summary at the end instead of six outputs to read.