Most teams start agentic development the same way: one chat window, one long session, and one agent asked to plan the feature, write the code, and confirm the code is good. It feels efficient. It also repeats one of the oldest mistakes in software engineering, at machine speed.
On the Scaling Tech Podcast Episode 64: Responsible Agentic Development: Building Fast Without Losing Control, host Arin Sime calls the human version of this the “cowboy developer.” A lone engineer on a business-critical project who plays architect, developer, tester, and product owner all at once. Some of these developers are brilliant, but it does not matter. One voice in the room means one set of blind spots, unchallenged, compounding with every decision. Teams learned decades ago to separate the person who builds from the person who reviews, to make priorities explicit, and to keep work visible on a board.
A single AI agent in a single context window has the same problem as the cowboy developer, and the same fix applies. In that Scaling Tech Podcast episode, AgilityFeat and WebRTC.ventures Senior Web Developer Andrea Phillips demonstrated her answer: a simulated team of specialized agents with distinct roles for product management, development, and code review, orchestrated by a human. This post walks through how that structure works and why the role separation carries most of the value.
What is AI agent orchestration with specialized roles?
AI agent orchestration means running multiple AI agents, each with its own instructions, persona, and context, and coordinating them the way a manager coordinates a team. Instead of one agent doing everything in one conversation, a PM agent breaks down requirements, developer agents implement scoped tasks, and a code reviewer agent evaluates the output against acceptance criteria. A human orchestrator supervises the flow and makes the final decisions.
The core argument: builders should not check their own work
Andrea’s reasoning starts from a principle every engineering organization already accepts for humans.
“You shouldn’t give a developer the responsibility to check its own work. It’s biased. It wrote it. It already knows. If you give it to another agent with a different session, fresh context, it’s going to catch much more bugs or issues that might arise.”
The bias here is mechanical rather than psychological. An agent reviewing its own output evaluates the code against the assumptions it used to write it, so those assumptions never get tested. A reviewer agent with fresh context evaluates the same code against the specification, the definition of done, and the full project scope. It can catch the class of bug that hides between files: a function signature changed to take two parameters while call sites elsewhere still pass one. As Andrea points out, an AI reviewer holds the entire codebase in context at once, something no human reviewer can do line by line, which makes it especially strong at exactly the cross-cutting checks humans miss on a busy week.
The same principle extends up one level. Andrea reviews her agents’ output, and on client work a second human reviews hers before anything reaches production. Fresh eyes at every layer.
The roles and what each one contributes
Andrea’s team, which she runs through an orchestration tool called Hive so she can watch every agent from one place, consists of three role types.
- The PM and product owner agent turns a goal into structured work. It drafts the PRD, asks the human clarifying questions about stack and requirements, writes the tech spec, breaks the work into epics and small scoped tasks, sets priorities, assigns tasks to developer agents, and can spawn new agents when the team needs another role. In her Episode 64 demo, this agent paused mid-planning to ask her which stack to use and what the content requirements were, exactly as a human PM would.
- Developer agents implement one scoped task at a time, with the full context of the PRD, spec, and acceptance criteria attached. Because the thinking already happened upstream, these agents execute rather than improvise.
- The code reviewer agent checks each pull request against the definition of done, verifies tests pass, and approves or requests changes, cycling with the developer agents until the work meets the bar.
Andrea gives her agents names and personalities, mostly footballers during a World Cup year. It sounds whimsical, and it serves a practical purpose: named personas keep roles and contexts cleanly separated when several agents run at once, and they make the board legible at a glance.
Running agents in parallel without collisions
Multiple developer agents working the same codebase would normally step on each other. Andrea borrows the coordination tools human teams already use.
- Git work trees give each parallel agent an isolated copy of the code, so two agents can work simultaneously without merge chaos.
- Small task sizing keeps each unit of work reviewable in minutes, avoiding the giant pull requests that defeat review whether the reviewer is human or AI.
- A visible task board shows what every agent is working on at all times. Andrea built her own lightweight board, though as she notes, Linear or Jira with an MCP connection works the same way. Her reasoning is a management instinct, self-aware and correct: “I have to see. I have to know what they’re doing.” An orchestrator who cannot see the work cannot supervise it.
The pattern across all three practices is the same. Manage agents exactly the way you manage human developers, because the failure modes are identical.
Match the model to the role
Role separation also unlocks a cost lever that a single-chat setup cannot use. Andrea assigns her most capable, most expensive models to the thinking-heavy roles: brainstorming, PRDs, tech specs, and task definition. Once the work is fully specified, implementation goes to smaller, cheaper models.
“After everything’s defined and they know exactly what they need to do, I can use even the smallest model. They don’t even need to think.”
Her framing echoes an old lesson. Lines of code never measured software quality, and token spend does not either. Spend the expensive tokens where judgment happens and the cheap ones where execution happens.
Add agents only after you have done the job by hand
The tempting endpoint of all this is full automation: agents feeding tasks to agents, reviewing each other, merging to main, no human anywhere. Andrea’s rule guards against expanding the team faster than you can supervise it. Never hand a role to an agent until you have performed that role manually enough times to recognize good output. Run the process, inspect the result, refine the prompt, and repeat across different projects. A process is ready for automation “when you run it X amount of times and you know that the output is what you want.”
Until then, delegating it means wishing rather than managing. This applies to every role on the agent team: task writing, code review criteria, test plans, all of it. The orchestrator’s expertise is what makes the oversight real. For more on the specification discipline underneath all of this, see our post on spec-driven development for production-ready AI code.
The same pattern works inside AI products
Role separation is not only a development workflow. It is an architecture pattern for AI products themselves, and our WebRTC.ventures team recently proved it in production. For CETA Global’s multi-agent clinical training simulator, the instinct might have been one large prompt asking a single model to roleplay a patient, coach the trainee, track protocol steps, and grade the session. That breaks down quickly, because each of those jobs has different requirements and different failure modes. Instead, the platform runs six purpose-built agents, each owning one responsibility, from client simulation to real-time coaching to post-session evaluation. Each agent can be tuned and tested independently without changes to one breaking another.
Whether the agents are building software or running inside it, the lesson holds: specialized roles with clear responsibilities outperform one agent asked to do everything.
Where this fits alongside your individual AI setup
This team-level view complements the individual developer’s toolkit rather than replacing it. Justin Williams covered that layer in his post on terminal agents, context files, and why your AI harness matters more than your model. His post answers how one developer should equip a single agent to work well. This one answers what to do when the work outgrows a single agent: give the additional agents distinct roles, coordinate them like a team, and keep a human orchestrator who owns the decisions.
Andrea demonstrates the full workflow, including a head-to-head build against a vibe-coded version of the same app:
At AgilityFeat, this is how our senior engineers work by default, and it is the workflow our Builder Pods bring to client projects: agents handling the volume, specialized roles keeping each other honest, and experienced humans making the calls that determine whether software is genuinely production-ready. If your team is ready to move beyond the single chat window, we should talk.
