There's a dirty secret about AI coding agents that nobody talks about in the demos.
The demos always show a well-written ticket going in and clean code coming out. Feature request, clear acceptance criteria, agent picks it up, implements it, opens a PR. Looks great on a slide.
In reality, most tickets are terrible.
"Add dark mode." That's the ticket. That's all of it. No acceptance criteria, no design spec, no mention of which components are affected, no call on how user preferences are handled, no call on what "dark mode" even means for the settings page versus the dashboard versus the marketing site.
A human developer who gets this ticket walks over to the PM (or Slacks them) and asks 14 clarifying questions. They fill in the gaps with institutional knowledge. They make judgment calls about scope. Maybe they ping the designer for a quick opinion.
An AI agent who gets this ticket guesses. It implements something. Maybe what the PM wanted. Maybe a complete CSS overhaul that touches 40 files and breaks the build. The agent doesn't know the difference. It works with what it was given.
This is why a lot of teams try AI agents, get bad output, and conclude that the agents aren't ready. But the agents were mostly fine. The tickets were the actual problem, and the agents were just unlucky enough to be the ones holding the bag when the bad input arrived.
Putting a product owner at the front of the pipeline
In Fleet, you can configure a product owner agent that sits between your backlog and your development agents. Its job is to take a ticket, make it good enough for a development agent to execute on, and then hand it to the right agent.
Here's what that looks like in practice.
A PM writes "Add dark mode" and labels it ready. The PO agent picks it up first. It reads the ticket, reads the relevant parts of the codebase, and produces a revised ticket with the specific components affected, acceptance criteria, edge cases to handle, a suggested approach, and a rough estimate of complexity.
Then it decides which development agent should handle it. A CSS-heavy UI task goes to the frontend agent. A feature that requires API changes goes to the full-stack agent. A database migration goes to the backend agent. The PO agent makes that routing decision based on the ticket content and the agent configurations you've defined.
The development agent receives a ticket that's actually actionable, and the output quality comes up with it, because you fixed the input before the work started.
The cheaper lever nobody pulls
Most conversations about AI agent quality focus on the model. "Use a better model and the output improves." That's technically true, and also the most expensive lever available.
The cheaper lever is input quality. A well-scoped ticket given to Sonnet produces better code than a vague ticket given to Opus. I've tested this. The difference is not subtle.
The PO agent is your input-quality layer. It turns your messy backlog into agent-ready work items. And because it's an agent itself, it runs on whatever model you choose. You don't need Opus for ticket refinement. Sonnet handles it well. [YOUR DETAIL: any specific example of testing this from your own experience.]
The routing piece is underrated
The other thing the PO agent does is route tickets to the right development agent. That sounds minor until you have eight agents with different specializations.
Without routing, you either assign tickets manually (which defeats the purpose of autonomous pipelines) or you let every agent see every ticket (which is wasteful and leads to agents grabbing work they're not suited for). With a PO agent handling routing, a security-related ticket goes to the agent with security-focused prompts and access to your security docs. A frontend ticket goes to the agent that knows your component library.
This is how human engineering teams work. You don't assign a database migration to your CSS specialist. The PO agent makes the same decision, automatically, for every ticket that comes in.
Configuration
agents:
- name: product-owner
role: product-owner
model: claude-sonnet
subscriptions:
- ticket_created
routes_to:
- frontend-dev
- backend-dev
- fullstack-dev
- security-eng
The PO agent subscribes to new ticket events, refines them, and publishes a ticket_ready event with the target agent specified. The development agent picks it up from there.
Fleet ships with templates for PO agents. You customize the refinement prompts to match your team's standards for what a "good ticket" looks like. The template is a starting point, and you tune it based on what your downstream agents actually need to produce good work.