BMad v6 Alpha

Plan → Build → Verify. Repeat. BMad v6 Alpha makes agents reproducible.

A developer-centric leap for Agent-as-Code

BMad v6 Alpha is a ground-up refresh of the BMad Method focused on Agent-as-Code, deterministic planning→build pipelines, and first-class ops (observability, replay, policy). It keeps the BMad spirit—Analyst → PM → Architect → Dev → QA—but ships a cleaner core, a stricter config model, and a more modular runtime that’s friendlier to teams, CI, and multi-repo workspaces.

---

🎥 Watch BMAD V6 Alpha Released: BMad Builder + 4 Features That Change Everything

Who this release is for

• Indie builders who want reproducible one-shot agents without babysitting context.

• Team leads who need planning discipline and traceability across repos/services.

• Toolsmiths integrating new models, vector stores, RAG tools, or eval harnesses.

• Ops/Compliance who care about guardrails, secrets, and policy.

---

What’s new in v6 (Alpha)

1) Agent-as-Code, standardized

• Agents live as versioned code artifacts (markdown or .bmad.yaml) with roles, tools, IO contracts, and success criteria declared up-front.

• Portable across projects; can be reused, extended, and diffed in PRs.

2) Two-phase pipeline done right

• Plan phase (Analyst/PM/Architect) produces a deterministic Blueprint (tasks, files, acceptance tests, tooling budget).

• Build/Verify phase (Dev/QA) consumes that Blueprint—no prompt drift, no context thrash.

3) Workspaces & service partitions

• Treat a monorepo or polyrepo as a Workspace.

• Run per-service agents with isolated context and shared org-level policies.

4) Pluggable model + tool adapters

• Swap LLM backends (local or cloud) and tools (search, code actions, browsers, vector DBs) via adapters.

• Ship different “profiles” (fast draft, high-quality, offline) without editing agent logic.

5) Determinism, replay, and diffs

• Run manifests capture inputs, model versions, seeds, tools, and outputs.

• Replay a run (or a single stage) to compare outputs; diff changes for reviews.

6) Observability by default

• Structured logs, token/time budgets, tool call traces, and artifact timeline per run.

• Export JSON traces for dashboards or attach to PRs.

7) Policy & safety

• Guardrails for file writes, network calls, data boundaries, and license checks.

• Fine-grained allow/deny on tools, directories, and domains.

8) Cleaner CLI + thin Web UI

• One mental model: bmad plan, bmad build, bmad verify, bmad run --pipeline.

• Web view for browsing traces, artifacts, blueprints, and diffs.

---

Install & Quickstart (Alpha)

# install (global or venv)
pip install bmad-method==6.0.0a0

# initialize a workspace
bmad init

# scaffold a service and a basic agent set
bmad scaffold service web-api
bmad scaffold agents --preset "product-dev"

# plan → build → verify
bmad plan --service web-api --out .bmad/blueprints/web-api.json
bmad build --blueprint .bmad/blueprints/web-api.json
bmad verify --blueprint .bmad/blueprints/web-api.json

Tip: run with --profile fast during exploration, switch to --profile hq for release candidates.

---

Minimal Agent-as-Code example

agents/dev.md

# Dev Agent
role: Developer
objectives:
  - Implement endpoints from the Blueprint with tests
  - Respect coding standards and architecture constraints
inputs:
  - blueprint: .bmad/blueprints/web-api.json
tools:
  - code.write
  - test.run
  - ref.search
success:
  - All acceptance tests pass
  - No policy violations

agents/dev.bmad.yaml

name: dev
role: developer
model_profile: hq
tools:
  - id: code.write
  - id: test.run
  - id: ref.search
io:
  consumes:
    - type: blueprint
      path: .bmad/blueprints/web-api.json
  produces:
    - type: pr
      path: .
policies:
  filesystem:
    allow:
      - "src/**"
      - "tests/**"
    deny:
      - "**/secrets/**"
  network:
    allow_domains: ["pypi.org"]
    deny_domains: ["*social*"]
success:
  - "pytest: 0 failures"
  - "linter: 0 errors"

---

Workspace anatomy (v6)

.bmad/
  profiles/            # fast, hq, offline, etc.
  blueprints/          # outputs from 'plan'
  runs/                # manifests, traces, artifacts
agents/
  analyst.md
  pm.md
  architect.md
  dev.md
  qa.md
policies/
  org.yaml             # global guardrails
services/
  web-api/
  worker/
  frontend/

---

Typical developer loop

1. Scaffold service + agents

2. Plan → generate a Blueprint with scope, files, tests

3. Review the Blueprint like a spec (PR comment thread)

4. Build → code edits + assets produced deterministically

5. Verify → run acceptance tests & policy checks

6. Replay with upgraded model/tooling before merging

---

CI/CD pattern

# .github/workflows/bmad.yml
name: bmad-pipeline
on: [pull_request]
jobs:
  plan_build_verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install bmad-method==6.0.0a0
      - run: bmad plan --out .bmad/blueprints/ci.json --profile fast
      - run: bmad build --blueprint .bmad/blueprints/ci.json --profile fast
      - run: bmad verify --blueprint .bmad/blueprints/ci.json --profile fast
      - name: Upload traces
        uses: actions/upload-artifact@v4
        with:
          name: bmad-traces
          path: .bmad/runs/**

---

Migration notes (v4 → v6 Alpha)

What carries over well

• Role chain (Analyst → PM → Architect → Dev → QA)

• Expansion-pack concept and domain-specific agent bundles

• JSON/MD specs and prompt libraries (convertible)

Breaking/changed

• Config format: consolidate per-agent YAML/MD + workspace policies.

• Two-phase pipeline is enforced: ad-hoc “do-everything” runs are discouraged.

• Policies now gate file/network actions by default (opt-in allowlists).

• Tracing is structured; custom scripts may need adapters.

Recommended migration path

1. Map v4 roles to v6 agent files with explicit success criteria.

2. Extract any long prompts into objectives + constraints sections.

3. Wrap existing scripts (lint, test, build) as tools.

4. Start with --profile fast, then tune hq for production.

5. Add org.yaml policies and tighten over time.

---

FAQ (Alpha)

Q: Can I use my existing LLM provider?
Yes—use a model profile (e.g., fast, hq, offline) and point it to your backend. You can keep secrets out of the repo via env vars or secret stores.

Q: Is v6 stable for production?
Alpha is feature-complete enough for pilot projects. Expect some breaking surface as adapters and policy schemas firm up before beta.

Q: How does replay work?
Each run creates a manifest with inputs, versions, seeds, and artifacts. Replays restore those and optionally swap model/tool versions to compare deltas.

Q: How do I plug in my evals?
Expose them as a tool (e.g., eval.run) and add success gates like “score ≥ X” in the QA agent’s success list.

Q: Does v6 support multi-repo organizations?
Yes—use a top-level Workspace with per-service partitions and shared org policies.

---

Roadmap signals (subject to change)

• Beta: stabilized policy schema, adapter SDK, richer Web UI for trace inspection.

• v6 GA: long-run agents (sagas), job queue + concurrency, first-party RAG adapter, and signed artifact attestations.

---