The Five Steps Inside Our AI Delivery Pipeline

This blog describes how the AI delivery pipeline works and what A-CX runs on every engagement. Five steps, from the first client conversation to the tested code merged on the main branch. Seven AI agents, each with one job and a defined idea of the professional it behaves like. And a short list of places where a person signs before anything moves.

Five of the seven agents are the steps themselves: brief, spec, plan, code, review. The other two add no steps at all. They are what drives code and review as a loop when nobody is in the room, and they get a section of their own further down.

What follows is the detail a technical reader actually wants. What each step takes in, what it hands the next one, what each agent decides on its own, and what the whole thing deliberately does not do. Mikko recently set out the five steps and why delivery has this shape. This post opens them up.

Why We Describe the Job and Not the Steps

The first instinct when you put an AI agent to work is to write down the steps. Do this, then check that, then if the check fails do this other thing. It feels like control, and for about a month it works.

Then it compounds. The step instructions need checks that the steps actually ran. The checks disagree with each other, so you write rules for what to do when they do. Every layer exists to patch the layer underneath it, and none of them is about the software you are supposed to be building. We know because we went down that road far enough to see where it ends.

The model is already good at working out how. What it needs from us is what. So each agent is defined by four things and nothing else: its purpose, what it takes in, what it produces, and the professional it behaves like. A contract, in other words, rather than a script. Inside that contract the agent decides its own approach, and a step-level instruction gets written in exactly one circumstance, which is a mistake that has already happened twice.

The fourth item surprises people. Telling an agent it is a principal engineer reviewing a colleague’s work, rather than listing forty review rules, produces a better review. Not because the words are magic, but because a defined professional has consistent judgment in the situations you did not write rules for, and those are most situations.

Brief: Asking Is the Work

deliver-brief behaves like a senior engagement lead. It listens more than it talks, structures what was actually said rather than what it assumed, asks the questions nobody has thought about yet, and stays honest about what is still unknown.

It takes whatever exists. Meeting notes, documents, a recording, an email thread, public information about the business. None of it is mandatory, which matters, because at this stage there is usually no tidy input to hand.

It produces the brief: what we intend to deliver, in language the person paying for it can check. The approver signs that, and the approver is the client on most engagements and A-CX where the client has asked us to run the whole delivery.

The claim underneath this step is the one Mikko makes too. Asking is the work. We are not experts in mining, or trading floors, or heavy machinery, and not pretending otherwise is exactly what forces us to go and ask the people who are. A brief written by someone who assumed they already understood the domain is a confident document about the wrong problem.

Spec: Where an Assumption Costs a Sentence

deliver-spec behaves like a senior product manager with deep engineering understanding. Testable requirements. Must kept separate from should. Ambiguity refused politely rather than resolved by guessing.

It turns the signed brief into two things. The first is the specification: functional requirements, the non-functional ones, business rules, acceptance criteria, written so the approver can sign them and the team can plan from them without a second conversation.

The second is the solution concept, which is the product manager’s description of the solution. Capabilities, actors, boundaries, integrations. It is deliberately not a technology architecture, and saying so out loud saves an argument later, because the technology architecture belongs to the next step and is a different kind of document written for a different reader.

This is the cheapest place in the whole pipeline to be wrong, and it has become the cheapest by a wider margin than it used to be. An assumption caught here costs a sentence. The same assumption caught after the code exists costs everything that was built on top of it, and when agents work through the night that is a great deal more code than it would once have been. Speed does not make a wrong requirement cheaper. It makes it bigger.

Plan: Architecture First, Then Everything Else

deliver-plan behaves like a technical program manager who has shipped software. It decomposes without inventing work, sizes honestly, makes dependencies explicit, and knows the difference between what a machine can do and what a person has to.

Two things happen here, and the order is the point.

First, the architecture. Before any work is broken out, the plan defines how the product is put together and how it gets deployed, which is often to more than one place. That is one overall architecture, plus a sub-architecture for any area that needs its own, each referring to the overall one rather than restating it. Nothing is planned until that document exists, because everything planned afterwards is planned against it, and a late change to an architecture does not add work so much as invalidate it.

Then the plans. With the architecture settled, feature plans run against it, several at once where the features are genuinely independent of each other. Each takes its own slice of the signed specification and turns it into objectives, then into issues that are actually ready to work: acceptance criteria written, dependencies declared, and the ones a machine should not take on marked as such.

This is where our engineers spend their hours, and it is the least glamorous claim we make. We have written before about what a week of delivery produces, and the honest explanation is not the agents. It is that the planning in front of them was good enough that they never had to guess. An underspecified issue does not produce a slow result or a broken one. It produces a fast, well-tested, confident implementation of something nobody asked for, and you find out three weeks later.

Code: Tests Before Claims

deliver-code behaves like a senior software engineer. Reads before it writes. Tests before it claims. Small, clean changes. One precise question when it is genuinely blocked, rather than an essay of options. Plain about what it did not do.

It takes one issue, or one parent issue with its children, and works in its own git worktree on its own branch. That isolation is what lets several of them run at the same time on the same repository without standing on each other, which is most of where the throughput comes from.

It opens as few pull requests as remain reviewable. Not one per issue, and not one per week either. A reviewer who is handed a change too large to hold in their head approves it anyway, and everyone involved knows it.

The honest problem in this step is over-reporting. Left alone, an AI agent examining a codebase will find a great many problems, propose fixes for all of them, and be wrong about which ones matter. Some of what it finds cannot happen without a hostile insider. Some cannot happen at all. So a finding has to clear a bar before it becomes anyone’s work, and the bar is a citation: name something that has already happened, or the finding is recorded and not filed.

Review: The Decision That Makes the Rest Safe

deliver-pr-review behaves like a principal engineer reviewing a colleague. Skeptical but fair. Evidence over taste. Silent on anything a linter should own. It writes the kind of comment a colleague thanks you for rather than the kind they learn to skim.

One design decision in this step carries more weight than anything else in the pipeline: code and review never share a context. The review is not the coding agent looking back over its work. It is a separate run that sees the change and the standards that apply to it, and does not see the reasoning that produced it.

That sounds like a technicality. It is the difference between a review and a justification. An agent asked to check its own work in the same context has every reason it made each decision still in front of it, and it will find those reasons persuasive, because it found them persuasive the first time.

The reviewer holds the verdict. It approves and merges, or it asks for changes and the work goes round again. It states what it approved and why, which is what makes the decision reviewable by a person afterwards. We have written separately about where an agent’s authority stops, and the review is the clearest case of authority that is real, bounded, and written down.

The Two Agents That Are Not Steps

Code and review are a loop, not a line. Something has to drive that loop, decide when a piece of work is finished, and clean up after it. That is the other two agents.

deliver-unit behaves like a tech lead who drives work to done. It takes one issue, or one parent with its children, and runs the code and review cycle until the work is merged. Then it verifies that the thing is actually finished rather than merely merged, closes what should be closed, and leaves no branch, no worktree and no half-open pull request behind. It decides what it can decide and escalates only what it cannot.

deliver-autonomous behaves like a dispatcher on a night shift. Calm, methodical, re-checks the board before every dispatch, never improvises a policy, never wakes anyone for something it can handle itself. It builds a queue of ready work and hands it to deliver-unit one item at a time, each in its own context.It runs in one of three shapes, and which one you pick is a decision about scope:

• overnight takes only the work it was given and stops when every item is merged or parked. The default, and the one to use when you know what you want done.
• drain takes an optional list to work first and then everything ready on the board, and keeps going until nothing qualified is left.
• assigned takes whatever is assigned to that operator, keeps watching the board for more, and stops only when told to.

A run stops for one reason: a decision that belongs to a person. Not for its own mistakes, and not for a problem it can wait out. Work it cannot deliver is parked with a decision issue attached and the run moves to the next item rather than stalling. One person directing this is a different job from writing the software, and it is the job our engineers actually do.

Who the run authenticates as matters as much as what it does. Every commit, review and merge carries the identity of whoever the operator is, and that operator is a person or one of our named AI personas, often both at the same time on the same project.

Where a Person Still Decides

Three signatures and one standing decision. That is the whole list, and it is short on purpose, because a gate nobody has time to hold is not a gate.

• The approver signs the brief. Nothing is specified until what we are building is agreed.
• The approver approves the spec. Nothing is planned until the requirements are ones somebody is prepared to be held to.
• The approver approves the plan. Including the architecture, which is the decision with the longest shadow.
• A person decides what enters the queue, and answers anything an agent raises while it is working.

So nothing reaches a client that a person did not approve the shape of, which is the same claim Mikko makes from the commercial side. What we do not do is put a person in the middle of the code and review loop, waiting to wave each individual finding through. That approval is spent up front, on the plan, where the person has the context to give a real answer. Inside the loop, the reviewer holds the verdict, and it holds it against standards that were agreed before the run started.

The distinction is worth being precise about, because the two get confused. Approving the work is not the same as approving each mechanical decision inside it. The first is judgment and belongs to a person. The second is a rubber stamp, and a rubber stamp held by a tired person at eleven at night is not a control.

What It Takes to Keep This Running

The part nobody publishes. Our skill library runs to seventy-two skills, seven of which are the delivery agents in this post. Behind those five steps and the mechanisms they share sits roughly nineteen thousand lines of written instruction.

That is a real cost, and it is the cost people underestimate when they decide to build this rather than buy it. Instruction is not free. Every line of it is read on some run, some of the time, and a library that nobody can hold in their head stops being an asset and starts being a liability with good intentions.

One rule keeps it usable, and we apply it without exception. Every topic has exactly one owner. Everything else points at that owner by name rather than restating what it says. How a pull request is opened is written down once. What makes an issue ready is written down once. When two agents need the same rule, the rule moves to a shared owner and both point at it.

A rule written in two places is a rule in neither, because the two copies drift and then nobody knows which one a run actually read. The same goes for decision records. A decision record explains why a decision was made and is worth keeping for that. It is not where the rule lives, and a rule that exists only in a decision record is a rule with no owner at all.

What the Pipeline Deliberately Does Not Do

It does not deploy. The pipeline ends at tested code merged to the main branch. Deployment is the step after it, and it sits outside on purpose, because an app store, an Azure tenant and a client’s own cloud have almost nothing in common. A single agent pretending they do would be wrong in three different ways.

It does not plan without a person. No agent decides what the product should be, what the architecture should be, or which trade-off is the right one. It drafts, a person decides, and where an agent hits a question that needs judgment it raises it and waits rather than picking an answer and moving on.

It carries no identity of its own. The agents are not a system with its own login. They run as whoever started them and can do exactly what that operator can do, no more, which means access questions are answered by the account at the moment of access rather than by an instruction somewhere in a prompt. We have written about why that matters and what it buys in security and traceability.

Talk to Us

None of this is a demonstration. It is how software gets built here every week, on real client work, and we publish the mechanics rather than the headline numbers because the mechanics are what you would actually be buying.

The quality does not come from the agents being clever. It comes from planning that leaves nothing to guess at, a review that cannot rationalize its own work, and a person on the decisions that deserve one. A-CX builds and runs AI Workflow Automation for organizations that need software delivered quickly and need it to hold up afterwards. Get in touch and we will walk through what your five steps would look like.