A process document about how James built Quorum (the product development platform where AI agents are the team) using the BMad methodology itself. Written as the work happens, not reconstructed at the end.
This document is not Quorum's Step 13 Portfolio feature (which Quorum produces for its users about their products). This document is about James building Quorum with BMad. Meta, personal, for portfolio or process documentation use.
Quorum's origin predates the product. A while back, while working at a major North American bank, I designed an internal agent system. An automation that tied into our products, customer needs, and cross-selling opportunities. This was before "agentic AI" was even a phrase. It never shipped as code, but thinking through what that system could do showed me where things were heading. Tools you operate were going to be replaced by agents that act on your behalf. When agentic AI finally hit the public conversation months later, I was already excited. The future I'd been sketching was becoming real.
Then I found BMad, and the scope of what I could take on changed overnight. Things that used to be out of reach, either because I wasn't advanced enough or the scaffolding didn't exist, stopped being out of reach. I could plan and build at a scope that would've needed a whole team a year ago.
Quorum surfaced quickly. I'd been carrying a longer-term idea for a portfolio that shows the process of building, not just the finished output. Meta, but honest. Quorum turned out to be the perfect first project for that portfolio, because it's the methodology itself made tangible.
The real push came from my day job. The number one roadblock in the design work I do has always been funding. We never get proper discovery, so design ends up reactive by default. You design whatever the current ask is and rarely get upstream to the strategy that would've made the design matter in the first place. It's pretty much a dead end.
Quorum exists to change that. It puts the designer at the front of the process, leading the way with the rest of the pack. Discovery becomes a first-class step instead of a luxury we couldn't afford. A 13-step pipeline where the user and an AI team work through the full arc of a product, from raw idea to shippable spec, with the designer in the driver's seat.
If this one ships right, it's the case study, and everything after it gets easier.
To be filled in: installing BMad, initial module configuration, first project setup, decisions about directory structure (_bmad-output/planning-artifacts, etc.).
Five agents designed and added to the BMad roster for this project (and kept as reusable identities going forward):
Each agent has its own sanctum at _bmad/memory/agent-<name>/ with CAPABILITIES.md, BOND.md, CREED.md, MEMORY.md, and INDEX.md. A setup dev team command registers them into BMad workflow routing so bmad-help recommends them at the right phases.
To be filled in: for each agent, why they exist, how their scope was defined, what they unlocked that a generic agent could not.
Sequence of artifacts produced, in order:
product-brief-quorum.md (2026-04-07 area)planning-artifacts/research/)prd.md, 91KB, complete through all 13 workflow steps. Six elicitation methods applied (Focus Group, War Room, First Principles, Shark Tank, Pre-mortem, SCAMPER).architecture.mdux-design-specification.mdepics.md, 9 epics, ~45 stories with acceptance criteriafigma-handoff-brief.mdTo be filled in: what each artifact taught you, what surprised you, where BMad's structure helped and where it pushed back.
Key decisions captured chronologically, each with the reasoning that drove them.
Tried the concept prompt in Figma Make; output didn't match the specs. Realized the existing specs (PRD, UX spec, handoff brief) captured structure but not experience quality. Decided to produce a pipeline walkthrough as a richer design reference, one that describes what each step feels like, not just what it contains.
Formalized the walkthrough as a standalone artifact (quorum-pipeline-walkthrough.md). Positioned as complementary to the PRD's quorumPipeline YAML: PRD owns structural definition, walkthrough owns experience definition.
Enriched the walkthrough significantly. Step 1 grew into a full 8-category Kitchen Sink Discovery Framework with structured deliverables. Step 13 (Portfolio Document) added as a new pipeline step, a product feature that Quorum produces for its users. Ran Correct Course to propagate 52 edits across PRD / epics / UX spec, keeping the canonical artifacts aligned with the walkthrough. Sprint Change Proposal: sprint-change-proposal-2026-04-14.md.
Distinguished two portfolio artifacts: (1) Quorum's Step 13 for its users about their products, and (2) this document, James's process building Quorum. Kept them separate because they answer different questions.
First working session with Damien (backend agent). Walked through three decisions (database, auth, job runner) conversationally, not as a chatbot prompt. Outcome: Supabase + Supabase Auth + Inngest + Vercel. Damien's MEMORY.md recorded the locked stack so a subsequent Claude Code session could pick it up without re-litigation. This was the first moment the "AI agents as team members, not tools" thesis felt real instead of aspirational.
Ran the full readiness audit: 48 FRs validated, 100% epic coverage, 0 critical issues (implementation-readiness-report-2026-04-15.md). Sprint planning produced 9 epics / 48 stories / 9 retrospectives in sprint-status.yaml. Story 1.1 marked ready for dev. quorum-app repo initialized at github.com/jcfrank8910/quorum-app. Greenlight for build phase.
First build session. Opened a fresh Claude Code session in quorum-app/; Damien's memory carried forward cleanly; Story 1.1 started from a cold handoff. All 7 tasks passed: lint clean, typecheck clean, production build clean, Prisma client generates. Next.js 16 + React 19 + TypeScript strict + Tailwind 4 + Prisma 7 + Supabase JS client installed. The story file was followed almost verbatim. The only deviation was Prisma 7's new config format (moved from schema.prisma to prisma.config.ts), caught at prisma generate time, adapted in one step, saved to project memory so future stories don't re-hit it. Proof the planning-first methodology produces build-ready specs.
Moved story files and sprint-status.yaml from quorum/ into quorum-app/. Reasoning: implementation specs want to live next to the code they describe, not in a sibling planning repo. quorum/ stays as the planning-artifacts source of truth (PRD, architecture, epics, UX specs, exports, portfolio capture); quorum-app/ owns the codebase and the implementation artifacts that govern it. Codified in both repos' CLAUDE.md files so future sessions don't re-merge them.
Initial plan was screenshot-heavy capture alongside text. First real session proved the opposite: Cursor froze mid-wrap; had screenshots been the primary record, the session would have been lost. Pivoted to text-first: rich timestamped entries in capture-log.md are the durable record, screenshots are optional garnish. Most moments are deferred and recreatable (re-run the build, restage the window) rather than blocking on a live capture. Resilient to tool flakiness and faster in the moment.
To be filled in as future decisions happen.
Why the walkthrough became a separate artifact instead of being folded into the UX spec:
Both needed to exist. Merging them would have diluted both.
To be filled in: lessons from the review process itself, what worked, what would change next time.
Execution began 2026-04-16 with Epic 1 Story 1.1 (project scaffold).
Tooling model: Cursor as the IDE (file tree, terminal, diffs, window for James's own reading and edits); Claude Code as the execution partner inside that environment (tool-using agent with memory, running tasks). Custom agents (Damien for backend planning, Jaymes for frontend, Kinsley for design, Luca for motion, Cipher for security) live as skills that any Claude Code session can invoke by name.
First agent handoff, Damien → Claude Code (2026-04-16). Walked out of the stack-planning session with Damien, opened a fresh Claude Code session in quorum-app/, and the handoff just worked. Damien's MEMORY.md was read on entry; stack decisions carried forward without re-litigation; Story 1.1 started from a cold context. This is the whole thesis in miniature: specialized agents with persistent memory, handing off work the way a real team does.
Story 1.1 scaffold (2026-04-16). All 7 tasks passed. Next.js 16 + React 19 + TypeScript strict + Tailwind 4 + Prisma 7 + Supabase JS client installed. npm run lint, npm run typecheck, npm run build, npm run prisma:generate all clean. curl localhost:3000 returned 200. The symbolic "it's alive" moment, captured as the first real screenshot in the portfolio capture log.
Prisma 7 drift moment (2026-04-16). Story 1.1 was written expecting Prisma 6's url = env("DATABASE_URL") inside schema.prisma. Prisma 7 moved that to prisma.config.ts. Error fired at prisma generate time (P1012), adapted in one step, saved to project memory so future stories don't re-hit it. Not a crisis. Noticed, adapted, documented. The kind of small-moment competence that separates finished products from unfinished ones, and an honest portrayal of how tooling drift gets handled in a real build.
To be filled in as subsequent stories ship.
To be filled in progressively. Don't wait until the end.
MEMORY.md at each agent's sanctum is what makes cross-session continuity feel like a team, not a chat log.sprint-status.yaml in the planning repo created a constant context-switch tax. Moving them into quorum-app/ made the build loop tighter: one repo open, one source of truth for what's next.Jay Frank is Senior Manager of Human-Centered Design at a major North American bank, leading design for Commercial and Small Business Lending. He filed four AI-related design patents in 2025 covering adaptive GUI systems, intelligent interaction patterns, and predictive financial UX. One of those patents earned a 2025 internal Visionary of the Year nomination, the only solo-inventor nomination among three finalist inventions that year. Quorum is his first published AI project and the first in a longer pipeline of products he plans to build using this methodology.
HTML + PDF generation will reuse the pattern from _gen_prd_exports.py when the project reaches a natural completion point. No point building the export script until the content is close to final. It changes weekly right now.