The Agents
The BMad Method 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 LLM you choose (Claude Code, Codex, Cursor, 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
| Agent | Role | You lean on them for | Runs | |
|---|---|---|---|---|
| 📊 | Mary | Business Analyst | Framing the problem, research, the product brief | Analysis |
| 📋 | John | Product Manager | The PRD — what to build and why | Planning |
| 🎨 | Sally | UX Designer | User journeys and UX specifications | Planning |
| 🏗️ | Winston | System Architect | The architecture spine, epics & stories | Solutioning |
| 💻 | Amelia | Senior Software Engineer | Implementing stories, test-first | Implementation |
| 📚 | Paige | Technical Writer | Documentation and explanations | anytime |
The Test Architect (Murat / TEA) is often in the room too, but doesn't ship with the default team — see below.
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 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 method ships more specialists still — a whole creative studio (brainstorming coaches, storytellers, design-thinking and innovation experts) and dedicated design (WDS) and builder (BMB) agents. You don't need them to ship, and they're out of scope for these getting-started docs, but they're there when a project calls for deeper ideation or design work.
For the canonical roster and every agent's full brief, see the official named agents docs.
How you actually work with them
You never manage the whole team at once. In practice:
- You're in a phase, so you talk to that phase's agent.
- You launch the agent's command in the terminal — or, during implementation, by clicking a story phase on Dybs.it.
- The agent converses with you and writes an artifact (a brief, a PRD, an
architecture doc, a story file) into
_bmad-output/. - 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