Persona-Driven Development: Why We Gave Our Agents Job Titles
At some point last year we stopped asking our AI agents to "build the feature" and started assigning them roles instead. Arch writes the plan. Code implements it. The PM reviews against the ticket. DevOps owns the pipeline. QA runs the tests.
None of these agents are separate models. They are the same underlying capability with different prompts, different scopes, and different sets of tools available. The separation is organizational, not technical. But the effect on output quality has been larger than any model upgrade we have shipped against.
Why roles work
A model asked to do everything will do everything — including the parts you did not want, the parts that were not in scope, and the parts that violated a constraint the prompt did not explicitly mention. A model asked to do one role within a defined workflow will mostly stay in that role, because the prompt that defines the role also defines the edges.
This is the same reason human engineering organizations developed roles in the first place. Specialization reduces the surface area each actor has to reason about. A clear handoff between stages forces the ambiguity to be resolved at the boundary, where a human can see it, instead of buried three levels deep in a single monolithic task.
We adopted this pattern for our internal agents not because the model needed it — most capable models can handle a reasonable end-to-end task — but because we needed it. A persona boundary is a place we can insert a review. A persona handoff is a place we can require a structured artifact. A persona constraint is a place we can say "this actor is not authorized to do that."
The contract between personas
The interesting work in this model is not what happens inside a persona's session. It is what has to travel between them.
Between Arch and Code, a prompt file. Between Code and the PM, a pull request tied to a Jira issue. Between the PM and QA, a merge candidate with a documented test plan. Between QA and DevOps, a deployable artifact with its provenance intact.
Each handoff is a contract. If the contract is not satisfied, the work does not advance. That constraint is enforced not by goodwill but by structure — the prompt file is required to exist, the Jira link is required to be present, the test plan is required to be attached. A downstream persona that receives an incomplete handoff is expected to reject it, not to paper over it.
This sounds like bureaucracy. In practice it is the opposite. It removes the ambiguity that slows a monolithic agentic session to a crawl — the "is this in scope?" questions, the drift into adjacent work, the partial completions that look done but are not. Every actor knows what they are responsible for and what they are not.
Where this pays off
The payoff shows up most clearly in two places.
The first is review. When a PM reviews a pull request from an agent persona, they are reviewing against the specific scope that persona was authorized to modify. They are not sifting through incidental changes, scope creep, or tangential refactors. If those appeared, it is a process failure worth surfacing, not a judgment call.
The second is audit. When an auditor asks "who authorized this change," we can answer with the Jira issue, the prompt file, the session log, the persona that executed, the reviewer who approved, and the CI gate that passed. The chain is unbroken because the structure required it to be unbroken at every step.
That is the real argument for persona-driven development. Not that it makes the agents smarter. It makes the system around the agents legible — to us, to our reviewers, and to anyone who later needs to explain what happened.