The Agent Pipeline
A closed loop where a sales lead, an operations lead, or anyone with a real problem files a requirement in a structured form, an agent reviews it, a coding agent writes the code, and an architect reviews the system concerns. No developer ever being the bottleneck.
The thesis
In the AI Agent era, the bottleneck is not the work. It is the handoff.
I have been watching the same pattern repeat across three jobs. Sales leads have ideas. Operations leads know exactly which field is in the wrong place. They write it down. It lands in a Notion. The developer triages, asks three questions, gets a half-answer, builds it two weeks later, and the asker has already forgotten what they asked for.
The interesting thing is — the asker is usually right. The requirement is usually small. The reason it does not ship is not the work. It is the pipeline.
“In the AI Agent era, the pipeline is no longer the bottleneck. The bottleneck is the handoff.
So I rebuilt the handoff. End to end. With agents. The five steps below are the system as I am running it now.
The loop
Five steps. Three of them run by agents. Two of them are the people closest to the problem and the person closest to the system.
1 · File
A sales lead, an operations lead, or anyone with a real problem opens a module in our internal tool. They file a requirement — not in free text, but in a structured form. "When X happens, I want this field to behave like Y." The form is opinionated on purpose, so the user is nudged into thinking about edge cases, not just happy paths. They iterate on it inside the module until the requirement actually reads the way they mean it.
2 · Review
A higher-tier agent reads the requirement. It checks the existing system model, the data schema, the extension points we already left open. If the requirement is feasible as stated, it drafts a confirmation. If it is not, it does not say no. It says — "here are three ways to interpret what you mean, pick one, or describe a fourth." The conversation stays in the user's language, not the engineer's.
3 · Code
Once aligned, the requirement is handed to a coding agent. The coding agent writes the change in a sandboxed branch, runs the test suite, and opens a PR. The PR description is written for the original asker, not for the reviewer — so they can still recognize what they asked for, two weeks later.
4 · Architect
A human architect reviews the PR. Not for the requirement — the agent and the user already aligned on that. The architect reviews for system-level concerns: does this break an extension point? does it bleed into another module? does it leave the schema in a state the next agent will misread?
5 · Ship
Merge. Deploy. Loop. The whole thing lives in Git logic. The requirement, the conversation, the diff, the review — every step is a traceable artifact. The non-dev user does not need to know what a branch is. They just need to know that their idea is now a thing, with a number, that they can watch go from draft to live.
Why now
The cost of running an agent through a single requirement is finally lower than the cost of the human meeting that used to triage it.
A year ago this was science fiction. Today, a moderately capable agent can hold a schema in context, write a diff, and open a PR that is good enough to review. The remaining work — the part that needs a human — is the part the human is uniquely good at.
The architect. The original asker. The two ends of the loop, not the middle.
And — the people closest to the problem are not the developers. They are the sales lead watching a customer churn because a quote PDF is wrong. They are the operations lead noticing that 30% of returned items share a mis-categorized field. They know the problem. They do not need to know how to code to file it correctly. They only need the right door.
What I am not doing
Boundaries matter as much as the design.
- I am not letting non-developers push to main.
- I am not replacing the architect.
- I am not assuming the agent is right.
- I am not building this in a week.
- I am not assuming the loop scales beyond frontline management. The specialists on the team still file requirements the old way, and that is on purpose.
I am doing it step by step, with a small group of frontline management — the ones who already file requirements well, the ones who push back when something is unclear. If it does not work for them, it will not work for anyone. If the review agent is annoying to them, it is annoying. Full stop.
Where I am now
11 PRs in, watching a curve.
The first version is up. We have a structured form. We have a review agent. We have a coding agent. We have an architect on call. In the last month, we have shipped 11 PRs this way. Six of them were filed by people who have never written a line of code.
It is not faster than the old pipeline. It is slower, in fact, for the first three requirements. By the eleventh, the conversation between the user and the review agent was under four minutes. That is the curve I am watching.
“I do not know if this scales. I do not know if it survives contact with a real customer emergency at 11pm. But the alternative — waiting for a developer to have time — is not a system. It is a queue.
I would rather build a small, careful loop that works, than a grand one that does not.
What is next
Three questions I am sitting with, openly.
- How does the loop behave when a requirement is filed under a real customer emergency, at 11pm, with a 30-minute SLA?
- What happens when a frontline user files something the system model was never designed to express — and the review agent does not know how to ask the right clarifying question?
- At what point does the architect become the new bottleneck — and how do I dissolve that one, too?
I do not have answers to any of these yet. The honest answer is that I am still in the curve. If you are running something similar, or thinking about it, I would like to hear from you.