This is Part 3 of the Agentic Engineering series. In Part 2, I introduced Knowledge-First Development and the 10-step Knowledge Store Generator. This post goes deeper into the mechanism that makes it work: assigning specialized personas to the same AI agent at each step.
I have spent the better part of this year experimenting with how to get the best output from AI coding agents. And one of the most counterintuitive discoveries has been this: the same AI model produces dramatically different quality output depending on the role you assign it.
Not different prompts. Not different temperature settings. Just a different persona: “You are a Systems Architect” versus “You are a UX Designer” versus “You are a Quality Engineer.”
Simply said — when you tell an AI agent to be everything at once, it becomes mediocre at everything. When you tell it to be one thing at a time, it becomes genuinely good at that thing.
The Problem with “Do Everything” Prompts
Here is a scenario most of us have encountered. You ask an AI agent: “Design the architecture for my application, write the product specs, create the test strategy, and document the API.”
What you get back is a single document that tries to do all four things and does none of them well. The architecture section mentions testing concerns. The product specs drift into implementation details. The test strategy assumes architecture decisions that were never explicitly made.
It is the equivalent of asking one person to be the architect, the product manager, the QA lead, and the technical writer — all in the same meeting. Similar to managers hiring specialists for each role, you want your AI agent to specialize too.
Ten Personas, One Agent
In the Knowledge Store Generator I described in Part 2, I break the generation process into 10 steps, each with a dedicated persona. Here is what each one thinks about:
Step 1 — Product Architect: “What does the agent need to know first?” Creates the foundational structure — CLAUDE.md (the agent entry point, which I cover in Part 4), design index, execution plans, and the directory skeleton.
Step 2 — Product Strategist: “What would make users love or hate this product?” Builds product sense — user personas, core beliefs, and product guardrails with measurable thresholds (more on guardrails in Part 9).
Step 3 — Systems Architect: “What are the system boundaries and how does data move between them?” Reads Steps 1-2 and designs the technical architecture — domains, layers, data flow, dependency rules.
Step 4 — Quality & Reliability Engineer: “How do we know this system is working correctly?” Reads Steps 1-3 and defines quality attributes — SLOs, performance targets, security model, tech debt tracking.
Step 5 — Domain Designer: The most prolific step. Reads everything above and produces 15+ design documents, each covering a specific technical decision — database schema, authentication, browser automation, LLM resilience, error handling. Every significant decision gets its own document with context, alternatives considered, and rationale. Each decision is classified as a one-way or two-way door (more on this in Part 8).
Step 6 — Spec Writer: Converts design decisions into implementable specifications. Each spec has acceptance criteria written in Given/When/Then format, making them directly testable.
Step 7 — UX Designer: Focuses purely on the user-facing experience. Design system components, interaction patterns, state transitions. This persona does not care about database schemas — it cares about what the user sees and does.
Step 8 — Test Architect: Designs the testing strategy. Test-fix loops, performance assertions, Playwright configurations. This persona reads the specs from Step 6 and asks “how do I prove each acceptance criterion is met?”
Step 9 — Reference Librarian: Creates library-specific guides for every external dependency. Playwright, Pydantic, python-docx, structlog — each gets its own reference document with API patterns, anti-patterns, and integration examples.
Step 10 — Product Architect (Final Pass): Returns to the first persona for a forensic verification pass across all 44 documents — cross-references, terminology consistency, numerical accuracy, traceability chains. I dedicate Part 6 entirely to this step because it surfaces a fascinating tension between verification quality and self-grading bias.
Why Specialization Works
The key insight is that each persona constrains the agent’s attention. When the agent is a “Quality Engineer,” it is not trying to redesign the architecture. It takes the architecture as given and asks quality-specific questions about it.
This mirrors how the research describes multi-agent patterns. Instead of one general agent trying to hold everything in context, you get specialized agents that go deep in their domain. The result is documents that are genuinely expert-quality in their specific area.
Here is what I found when comparing outputs:
| Aspect | Single “Do Everything” Prompt | Role-Based Sequential |
|---|---|---|
| Terminology consistency | Frequent drift across sections | 0 inconsistencies |
| Cross-domain awareness | Architecture ignores testing needs | Each step reads all prior steps |
| Depth per topic | Surface-level coverage | Expert-depth per domain |
| Contradictions | Common between sections | Caught by dependency chain |
The Dependency Chain Is the Secret Sauce
The personas alone are not enough. The real magic is in the dependency ordering. Each step explicitly reads the output of all prior steps. This means:
- The Systems Architect does not invent domain names — it reads them from the Product Strategist’s personas
- The Spec Writer does not guess at quality requirements — it reads them from the Quality Engineer’s SLOs
- The Test Architect does not assume acceptance criteria — it reads them from the Spec Writer’s Given/When/Then blocks
This creates what I think of as a “coherence cascade.” Good decisions in early steps cascade through every subsequent document. And because each persona is constrained to its specialization, it does not accidentally overwrite decisions made by earlier personas.
I formalize this cascading relationship through what I call traceability chains — explicit, verifiable connections between documents at different levels. That is the subject of Part 5.
The Agentic Engineering Principle
The broader principle here is one I keep returning to throughout this series: structure the agent’s work the way you would structure a high-performing team.
You would not ask your DBA to design the user interface. Do not ask your AI agent to do the equivalent. Break the work into role-specific, sequential steps where each step inherits the context of all prior steps.
The total output might be longer, but each piece will be substantially better. And the consistency across pieces — that is the part that really pays off during implementation.
What do you think — have you experimented with persona-based prompting in your own workflows? I am curious whether the “one agent, many hats” approach works as well for others as it has for me.