The Agents

Your hybrid team is not a set of forms you fill in. It's a team you talk to. Each phase has an agent (a persona with a point of view, a specialty, and a voice) and your job as the agile lead is to steer that team, not to do every job yourself.

In Dybs.it, you meet these agents by launching their slash commands in the embedded terminal. The agent runs on the coding agent you choose (Claude Code, Codex, Gemini, and others), holds a real conversation with you, and leaves behind an artifact the next agent can build on.

Think of it as a small studio. You're the director. Here's the crew.

Names and roster aren't fixed. The agents below (their names, and which ship by default versus as an optional module) come from the installed BMad Method method and any customizations in your project, so they can differ from what you see here and can change between versions. This page describes the default team you'll typically meet in Dybs.it; for the authoritative, current roster, the source of truth is the canonical agents reference.

The default team

The Test Architect (Murat) is often in the room too, but doesn't ship with the default team. He, the creative studio, the design team and the agent builder are all further down this page.

Who does what

📊 Mary: the Business Analyst

Mary channels strategic rigor and the Pyramid Principle, and grounds every finding in evidence. She's a treasure hunter: thrilled by every clue, precise once the pattern emerges. Bring her a fuzzy idea and she'll help you find the real problem hiding underneath it: through brainstorming, market and domain research, and a crisp product brief. → Phase 1 · Analysis

📋 John: the Product Manager

John drives Jobs-to-be-Done over template-filling. User value comes first; technical feasibility is a constraint, not the driver. He interrogates a product idea like a cold case (short questions, sharper follow-ups, every "why?" tightening the net) until you have a PRD you can actually build against. → Phase 2 · Planning

🎨 Sally: the UX Designer

Sally balances empathy with edge-case rigor. She starts simple and evolves through feedback, and every decision serves a genuine user need. She pitches the scene before the code exists, painting user stories that make you feel the problem, then turns them into UX specifications. → Phase 2 · Planning

🏗️ Winston: the System Architect

Winston favors boring technology for stability and treats developer productivity as architecture. He works at the whiteboard: measured, laying out trade-offs rather than verdicts. He gives you an architecture spine: the lean set of invariants that keep every epic and story consistent. Then he breaks the work into epics and stories. → Phase 3 · Solutioning

💻 Amelia: the Senior Software Engineer

Amelia is test-first discipline made flesh: red, green, refactor; 100% pass before review; no fluff, all precision. She speaks like a terminal prompt: exact file paths, acceptance-criteria IDs, commit-message brevity. She takes a story spec and turns it into working, reviewed code. → Phase 4 · Implementation

📚 Paige: the Technical Writer

Paige is a master of structured docs who favors diagrams over walls of text and makes complex things feel simple. She's the patient teacher you wish you'd had, and she wrote the site you're reading now. Call on her anytime you need something explained, documented, or a diagram drawn.

Beyond the default team

The default team isn't the whole roster. The most common addition is the test specialist:

🧪 Murat: the Master Test Architect (TEA)

Murat thinks in risk calculations and impact assessments: strong opinions, weakly held. He spends test effort where the risk actually is, not uniformly, and owns the quality gate that tells you whether an epic is safe to close. He doesn't ship with the default team. The full Test Architect (TEA) comes as its own module you add when a project's risk makes it worth it. → Quality & testing · TEA in the canonical docs

The creative studio

When the problem is fuzzy rather than under-specified, there's a whole studio waiting. You don't need any of them to ship, and none of them replace a phase agent. Call one when the work in front of you is thinking work.

The design team

A second, parallel design track with its own analyst, designer and builder. They work as a trio rather than individually, and they're worth reaching for when design is the hard part of the project rather than a step in it.

The agent builder

Anything Builder makes is yours. It lives in your project rather than in the method, which also means it behaves a little differently in a party. See Getting them in a room together below.

For the canonical roster and every agent's full brief, see the official named agents docs.

Getting them in a room together

So far every agent has been a one-to-one conversation. Party mode is the other way to work: several agents in the same room, reacting to each other and to you.

You start one by running /bmad-party-mode in the terminal. With no arguments you pick the room by hand. With a named group, the room is already cast:

/bmad-party-mode --party code-review-crew

Two named groups ship by default.

Whether the voices really think for themselves

This is the part worth understanding before you trust a room's output, because it changes what the answer is worth.

A party can run four ways, and they differ in one thing: whether each persona gets its own mind or whether one mind voices all of them.

Both shipped groups are written for subagent mode and say so out loud. The Anti-Consensus Club will even ask you to switch at the start of a session, because separate minds make it far less likely that one shared context quietly talks the whole room into agreeing. If you're running a room to catch something you'd otherwise miss, that difference is the entire point.

You can set the mode for one run:

/bmad-party-mode --party code-review-crew --mode subagent

Not everyone can be summoned

Every agent on this page can join a party. Agents you or your team wrote yourself cannot, unless they've been added to the party pool. They're still fully usable one-to-one, which is how most custom agents are meant to be used.

Next release: the Team view marks each agent with whether a party can summon it, shows the run mode currently in force and what it means, and lists the named groups with their summon commands. Until then, party mode itself works exactly as described above.

Names in your retrospectives

A retrospective write-up features a small recurring cast: Alice the Product Owner, Charlie the Senior Dev, Dana the QA Engineer and Elena the Junior Dev. They're written into the retrospective itself, which is why you'll never find a command that launches them and why a party can't summon them. They are voices the retrospective uses to argue with itself, not members of your team. Amelia appears in the same write-ups and is the exception: she's a real agent you can launch any time.

Next release: the Team view lists this cast in its own section, so you can see where the names come from without going looking.

How you actually work with them

You never manage the whole team at once. In practice:

1. You're in a phase, so you talk to that phase's agent.
2. You launch the agent's command in the terminal, or, during implementation, by clicking a story phase on Dybs.it.
3. The agent converses with you and writes an artifact (a brief, a PRD, an architecture doc, a story file) into _bmad-output/.
4. You review it in the Documents view and hand off to the next agent.

The agile lead's real skill is knowing which agent to call, when, and when the artifact is good enough to move on.

Next steps

• See how the agents hand off to each other across the whole method → The method: overview
• Meet the first agent you'll work with → Phase 1 · Analysis
• Look up every agent's commands → Slash-command reference