BMAD can bring specialised perspectives into a delivery workflow. Its stable release ships five named agents, an analyst, a product manager, an architect, a developer and a UX designer, alongside a larger set of skills. For a small team that cannot staff every discipline full time, that is genuinely useful. A developer working alone on a Friday afternoon can still be asked the questions an architect would ask.
The names also create a risk. It is easy to look at a tool that lists an analyst, an architect and a product manager and conclude that the organisation now has those people. It does not. An AI perspective can generate questions, drafts and challenges. It cannot hold organisational authority, carry professional accountability, or know things nobody wrote down for it.
This part is about designing the team so that the perspectives make people better at their jobs rather than quietly standing in for jobs nobody is doing.
Mopane Logistics is fictional, and its systems and figures are illustrative. Mopane, a Durban freight and courier company, has a seven-person internal software team: a product owner, a tech lead who also carries architecture, four engineers and one tester. Security and risk come part-time from group IT. By this point in the series the team has run its first pilot, the invoice-resend change from Part 3, and recovered enough context about the Dispatch system to stop the kind of breakage that started all this: the renamed consignment_ref field that broke a nightly finance export in Part 1.
Agent roles are perspectives
A perspective is a structured way of looking at a problem. BMAD's architect agent asks about boundaries, data, failure and deployment because it has been set up to ask those questions. That is valuable. It is also all it is.
Three things separate a perspective from a person in the role:
- Authority. Mopane's product owner can say no to a feature, trade scope for a date, or accept a known limitation. The product manager agent can recommend any of these, and none of its recommendations binds anyone.
- Accountability. When a release goes wrong, someone explains it to the operations director and to customers. That person needs to have understood what they approved.
- Tacit knowledge. Mopane's tech lead knows that the City Deep depot runs a different label printer, that the finance team reconciles on the third working day, and that one large retail customer will not accept a changed delivery-note format without notice. None of that is in the repository until someone puts it there.
The method works best when it is honest about this. The perspectives make the questions better and more consistent. The people still answer them.
Mapping perspectives to people
The tech lead's first job after the pilot was to write down, for each BMAD perspective the team uses, which person receives its output and which decision that person keeps.
| Human responsibility | What the BMAD perspective contributes | What the person retains |
|---|---|---|
| Product owner | Clarifies outcomes, journeys and acceptance criteria | Priority, scope and value decisions |
| Business analysis (shared at Mopane) | Structures rules, actors, exceptions and evidence | Validation with real stakeholders |
| Architect (the tech lead) | Surfaces views, trade-offs and decision records | Fitness, exceptions and architecture approval |
| Developer | Proposes implementation and tests | Code quality, maintainability and safe integration |
| Tester or quality engineer | Generates scenarios and challenges assumptions | Test strategy, risk acceptance and release evidence |
| Security and risk | Prompts threat and control analysis | Policy interpretation and approval |
| Delivery lead | Helps structure work and surface dependencies | Commitments, coordination and escalation |
Two rows needed thought at Mopane.
Nobody at Mopane has "business analyst" in their title. The product owner and the tester share the work. The analyst perspective turned out to be most useful for exactly that reason: it asks the questions a business analyst would ask, and it makes the gap visible. The product owner now books short sessions with depot supervisors whenever the analyst perspective raises a question the team cannot answer from the repository. The method did not fill the role. It showed where the role was missing.
The tester's row also changed. BMAD's stable release no longer ships a separate QA agent; test scenarios come from the developer agent and, for teams that want it, a separate test architecture module. Mopane's tester treats generated scenarios as a starting list, not a test strategy. In the resend pilot, the generated scenarios covered success, denial and a missing invoice. The tester added the case that actually mattered to operations: a resend requested while the finance system was mid-export, which is when support calls peak on the third working day.
The small-team pattern
Mopane fits the small-team pattern almost exactly:
- one product or outcome owner;
- one senior engineer with architecture responsibility;
- one or more engineers;
- shared quality responsibility, with a named tester;
- part-time security and domain review at defined gates;
- BMAD used to supply structure and specialist prompts.
The phrase that matters is at defined gates. Group IT's security reviewer does not read every artefact. The team agreed three points where that reviewer must look: when a change touches personal information, when it adds or changes an external integration, and before any change to authentication or roles. The resend pilot hit the first gate, because invoices carry customer contact details. The reviewer spent forty minutes on the specification, asked for resend events to be logged without the email body, and approved it.
Without defined gates, one of two things happens. Either the part-time reviewer is asked to look at everything and stops looking properly, or nobody asks and the review quietly disappears. The method should reduce role gaps, not conceal them.
The enterprise pattern
Mopane's parent group runs larger teams with formal governance. For a regulated or audited organisation, the pattern changes:
- Product and business authority remain named, not delegated to whoever runs the workflow.
- Architecture decisions follow the existing review thresholds. A BMAD architecture artefact is an input to the architecture forum, not a replacement for it.
- Security, privacy and risk controls are encoded where possible, in pipelines and repository rules, rather than left to the agent's judgement.
- AI-produced artefacts are versioned and reviewable, like any other change.
- CI/CD provides deterministic evidence.
- Separation of duties is preserved for sensitive changes. The person who prompts the developer agent to write a payments change should not be the only person who approves it.
- Vendor and internal teams share one definition of done.
None of this is BMAD-specific. It is how a well-run organisation already treats any delivery method. The point is that adopting BMAD does not suspend it. Our article on team structures for spec-driven development goes deeper into how responsibilities shift when agents draft more of the work.
The consultancy pattern
BMAD can improve continuity between a proposal and delivery, because discovery artefacts can flow straight into the engineering context. It can also amplify a bad commercial habit: generated detail can make unknowns look resolved.
Mopane met this directly. Baobab Systems, a fictional systems integrator, proposed rebuilding the customer portal. The proposal was impressive. It came with a product brief, a requirements document, an architecture and a set of epics, all clearly produced with BMAD's planning skills, all neatly formatted, and with forty numbered requirements.
The tech lead noticed that several requirements described behaviour Mopane had never discussed with Baobab. One specified a customer self-service rebooking flow. Another assumed the finance system exposed an invoice API, which it does not. They read as decisions. They were guesses.
Mopane asked Baobab to label every item in the proposal as one of six kinds of claim:
- client-confirmed fact;
- consultant observation;
- assumption used for estimating;
- decision pending client authority;
- technical hypothesis requiring discovery;
- item excluded from scope.
The result was uncomfortable for both sides. Twenty of the forty items were assumptions made to produce an estimate. Only nine had been confirmed by anyone at Mopane. The proposal had not changed, but its weight had: the fixed price rested on twenty assumptions, any of which could become a change request.
To Baobab's credit, it revised the offer into a paid discovery phase followed by a priced build, with the assumptions listed as explicit risks. That is a better commercial shape for everyone, and it is the same argument our Forward Deployed AI series makes about selling the discovery rather than the fantasy.
The lesson is not that consultancies should avoid BMAD. A consultancy that uses it well can arrive at a first workshop with sharper questions and leave with better-structured findings. The lesson is that this discipline matters more than the polish of the output. Any organisation receiving AI-assisted proposals should ask for the marking. Any supplier producing them should offer it unasked.
What changes for the people
The team members whose work changed most at Mopane were not the engineers.
The product owner spends more time before code and less after it. Acceptance criteria are drafted faster, so the time goes into checking them with depot staff and the operations director. The product owner's view: the drafting got cheaper, and the deciding got more visible.
The tech lead moved from answering the same context questions repeatedly to maintaining the context once. The project-context block in AGENTS.md, introduced in Part 4, now carries the rules that were previously in the tech lead's head, including "never rename a Dispatch column without checking the finance export and the depot report view".
The engineers review more and type less. Two of the four found this a welcome change. One found it frustrating at first, because reviewing a generated story against a specification felt like paperwork. That changed after a review caught a missing authorisation check that would otherwise have gone to production.
The tester became the person most likely to say "the specification is wrong", which is exactly the job.
A human team still owns the outcome. The method has made it easier to see who owns which part of it.
The short version
A perspective is not a person. BMAD's named agents supply questions and drafts; they hold no authority, accountability or unwritten knowledge.
Map every perspective to a decision-maker. For each one, name who receives the output and which decision they keep.
Use the gaps. Where a perspective has no human counterpart, the method has found a missing role, not filled it.
Define the gates. Part-time specialists review at agreed points, or they stop reviewing at all.
Mark facts and assumptions. In consulting work, labelling what is confirmed matters more than how polished the artefacts look.
Previous: Part 4, greenfield and brownfield are different games. Next: Part 6, supporting tools, alternatives and hybrids. All parts are on the series page.
How CloudNala can help
We help delivery teams design how people and AI perspectives work together: mapping each perspective to a named decision-maker, defining the gates where security, risk and domain specialists review, and setting up the fact-and-assumption marking that makes AI-assisted proposals and specifications safe to rely on. For organisations buying from suppliers who use these methods, we help you ask for the evidence that separates confirmed requirements from estimates.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan an AI Delivery Pilot or write to us at consult@cloudnala.co.za