The Pipeline: Stages, Gates, and Artifacts

The ticket lifecycle

Backlog item → Plan → Engineering → Testing → Review → PR/Merge → CI/CD

Each of these arrows represents a gate, basically an enforced state in a state machine. Agents cannot cross gate boundaries without meeting defined criteria.

The image below depicts the core stages, gates, and artifacts in the governed lifecycle. Each stage has specific inputs, outputs, and responsibilities. The gates enforce quality and alignment before allowing progression to the next stage. Perhaps at some point, you might be able to remove human involvement via some smart automation, or require it only if a deviation is detected. (More about this in the Feedback Loops chapter).

This is a good template to start building over the standard "Plan mode" and "Agent mode" once you've discovered the need for more structure and control.

Planning

In case you wonder, this is the 'outer loop' work that happens before any code is written. It sums up the requirements, designs, and whatnot, and turns them into atomic, structured, and ordered tasks that you can feed into your pipeline.

Specialist planning agents can be spawned to create and review planning tasks when needed. For instance, if you're porting an old frontend and need to learn from it and produce designs, you might use a differently instructed agent than for a greenfield feature. Same if you have a layered architecture or microservices; some parts of the system could benefit from a domain-specific agent with specialized knowledge and context. Apply this specialization as you see fit, but remember: the smaller and more focused an agent is, the better it will perform.

For example, a good plan for an agent might include:

Engineering

The engineering stage is where the rubber meets the road and used to be the one with the most attention and often work. An Engineering Agent takes the approved plan and executes it, producing code and unit tests that meet the defined acceptance criteria. This stage is all about execution: translating the plan into a working implementation as you planned, but nothing more.

The primary intent of the engineering agent should contain:

Compressed Indexes: Context Engineering for Documents

One practical tip for controlling the task-specific project context fed to agents is a technique called Compressed Indexes. The basic idea is that instead of chunking everything into your CLAUDE.md or maintaining separate reference sections for all agents, organize your documents into meaningful chunks by theme, backed by an accessible index. Let the agent seek advice from it when needed. It could be something like this:

A good index for LLMs is not just a table of contents; it should be designed to help the agent find the right context efficiently, without consuming unnecessary tokens.

The index should include:

• Document summaries: A brief description of each document's content and purpose.
• Relevance tags: Keywords or tags that indicate which agents or tasks the document is relevant for.
• Sample questions: Example queries that would lead the agent to consult that document. This helps the agent understand when to seek that context.

Check the link below for an open-source implementation of this technique.

Specialist agents

As you learn along the way, you may end up having specialized engineers for different aspects of the work, like frontend and backend engineer agents. For instance, a "critique" agent (think of the guy in your team who is vicious about indentations (the correct answer is 3, spaces btw)) that reads your code and shreds it to pieces can also be a nice touch. Spawn it in a fresh context and with a different model before asking for a human review.

The gate state machine

Here's one example of how you could design your own work tracking engine. Essentially it's the same as we had back in the day as 'Definition of Ready' and 'Definition of Done,' but with more structure and automation; when the feature is clear enough to be worked on, when the code is good enough to be reviewed, and so on.

Whatever the exact gates you erect, in the absence of humans in the inner loop, you need to have something like this to prevent runaways and to maintain traceability.

I've provided a more detailed breakdown of one possible setup that we've been using.

Agent roles and responsibilities

Every governed pipeline needs a set of specialized agent roles. The exact names and boundaries will vary with your stack, but the division of responsibility matters more than the labels. Each role should have a clear mandate, defined inputs and outputs, and explicit criteria for advancing or falling back.

The critical pattern is that each role consumes only the structured artifacts from the previous stage, never the conversational context. This prevents context bleed and keeps each agent's input clean. The reviewer, for example, checks code quality, performance implications, accessibility, functional correctness against spec, architecture alignment, and UI/UX adherence.

How to structure the backlog

Here's a setup I've found to work well in practice.

Having this systematic and well-defined is a bit like programming the workflow. Clear input and output for each stage keeps things on track. With humans, certain degrees of freedom and flexibility are expected, you know, Markku will surely know how to add this cancel button without telling much more, but the agent won't. And you can still fix a single thing without a ticket.

Making your backlog items AI-ready

Traditional agile stories are deliberately lightweight: a sentence of intent, a few acceptance criteria, a conversation placeholder. This works fine when the executor is a human who will ask clarifying questions and fill in the gaps from experience. It works considerably less well when the executor is a Planning Agent that fills gaps probabilistically, i.e. by guessing.

On one of my projects I found out the hard way that the standard 'As a user, I want to...' format was nowhere near enough. The planning agent would produce technically plausible but contextually wrong plans because it had no idea which APIs were available (and what kind of input they'd require and what kind of data you'd get back), what the UI conventions were, or where the architectural boundaries lived.

Naturally these kind of concerns, at least some of them might reside in project documentation, as they should, but in pre-planning stage a good 'Definition of Ready' checklist for the backlog items is a good way to make sure the planning agent has what it needs to produce a good plan, and also coaches the developer in charge of the 'production line' of the agent factory to pay attention.

Think of it as the 'pre flight checklist' for the planning agent. If you have good structure there, even with gaps and just titles, your detailed plans end up looking much more like each other and limit the creativity of the agent in a good way.

So what helped was treating the analysis phase as a proper Definition of Ready checklist before handing anything to the planning agent. For each story, we added:

This is not a requirements document per story. It's maybe ten to fifteen minutes of extra work during analysis, but the downstream impact on plan quality was significant. The agent stopped inventing architecture and started following it.

Bugs discovered later in the process should be judged by the same criteria: if they are big enough to require a plan, they should be treated as a new backlog item and go through the same process. If they are small enough to be fixed without a ticket, then just fix them.

While the details and complexity of your dream setup will certainly be something other than what's above, remember that you need some kind of clear system to maintain traceability and control.

In summary, a good agentic lifecycle is not just about the agents and their capabilities. It's also about how you structure the work, define the stages, and enforce the gates to maintain quality and alignment. A good one lives by these principles:

What not to do

Some things are perhaps not to be GenAI-automated due to several good reasons. I'm the first to admit I do have an 'infrastructure engineer agent' in my toolbox, whose idea really is not to act as a runtime (although it might be used to diagnose!), but to produce scripts and tools for the humans to execute. The risk of letting it execute them is just too high, and the potential benefits are not that great.

So some words of warning of what not to agentize just yet. You may thank me later.

Feedback loops that actually work

The pipeline as described above is mostly forward-flowing: backlog to plan to code to test to review to merge. Rejections loop back one stage, and that's about it. But real delivery needs richer feedback than just "send it back to engineering." I'll cover the broader feedback loop design in Chapter 20, but two loops proved their worth early enough to mention here.

The first was capturing reusable elements. When the tester or reviewer spotted a pattern that kept recurring, a shared call pattern, a common UI control, or a cross-cutting concern, that information got fed back into the architecture context documents that agents read for future tasks. Without this, the agents reinvent the same patterns every time, and you end up fixing the same things over and over.

The second was the revert-to-engineering loop for bugs discovered by the testing agent. Instead of having the tester attempt fixes or the engineer debug within an already cluttered context, the bug report went back to a fresh engineering session with just the failing test and the relevant code. Concerns stayed separated, context stayed clean. Exactly the kind of thing that matters when your executor has a finite context window and no memory between sessions.