tools-only SAM vs BMAD-METHOD: Methodology Comparison
0) Comparison Header
- Item A: Stateless Agent Methodology (SAM)
- Item B: BMad Method (Breakthrough Method of Agile AI Driven Development)
- Comparison category: technical_framework
- Decision posture: describe_tradeoffs_only
- Audience: Software teams evaluating LLM agent workflows for software development
- Primary decision to enable: "Which methodology fits our LLM agent project needs?"
- Stakes / cost of wrong choice: high (methodology affects project architecture, workflow patterns, team collaboration, and development velocity)
- Time budget: 120 minutes
- Evidence constraint: high_rigor_required
- Non-negotiables: Evidence-based only, must support LLM agents, must address hallucination risks, must produce verifiable outcomes
1) Pre-Comparison Reflection (MANDATORY; produces the "tailored rubric")
1.1 Fit-for-purpose framing
What problem exists in the world that this comparison must resolve?
- Software teams using LLM agents for development face reliability issues: hallucinations, context degradation, methodology non-compliance, and inconsistent outputs. Teams need structured approaches to compensate for LLM limitations.
Who experiences the problem and in what context(s)?
- Development teams building software with AI assistants (Claude Code, Cursor, Windsurf, etc.)
- Teams working on projects ranging from bug fixes to enterprise systems
- Teams needing verifiable, consistent results from AI-assisted development
What does "success" mean in observable terms?
- Reduced hallucination rates (<5% for SAM target)
- Consistent methodology compliance (100% for SAM target)
- Working code that passes verification
- Clear artifact trails for auditing
- Reduced rework from agent conflicts
What does "failure" look like (costly mistakes)?
- Agent conflicts creating incompatible implementations
- Hallucinated code that appears correct but fails in production
- Skipped methodology steps leading to incomplete implementations
- Context window pressure causing quality degradation
- Unverifiable claims about implementation correctness
What is out of scope?
- Methodologies not designed for LLM agents
- Human-only agile methodologies (Scrum, Kanban without AI adaptation)
- General software engineering best practices not specific to AI workflows
- Performance benchmarks of specific LLM models
- Cost comparisons of LLM usage
1.2 Assumptions and boundary conditions
Assumptions you are making:
- Assumption 1: Both methodologies address LLM-specific limitations (hallucination, context rot, training data staleness) → Evidence needed: Direct statements in methodology documentation about LLM constraints
- Assumption 2: Both methodologies produce artifacts that serve as context for subsequent stages → Evidence needed: Artifact flow diagrams and stage descriptions
- Assumption 3: Both methodologies can be implemented with common AI IDE tools (Claude Code, Cursor, etc.) → Evidence needed: Tool compatibility documentation
- Assumption 4: Teams have basic software development skills and understanding of agile concepts → Evidence needed: Prerequisites sections in documentation
Boundary conditions / constraints:
- Teams must have access to AI coding assistants (Claude Code, Cursor, Windsurf, or similar)
- Projects must be software development (not other domains)
- Teams need version control and basic DevOps capabilities
- Comparison limited to documented features as of 2026-01-27
- SAM documentation does not include implementation details for tooling (focuses on principles)
- BMAD documentation includes complete implementation (installable npm package with agents/workflows)
1.3 Evidence plan
Primary evidence sources:
- Official methodology documentation (markdown files from source repositories)
- Workflow diagrams and architecture specifications
- Direct quotes from methodology descriptions
- Stated design principles and constraints
- Success metrics where explicitly documented
Comparability rules:
- Only compare features explicitly documented in source material
- If feature exists in one but not documented in the other, mark as NOT_COMPARABLE
- For workflow stages, compare documented purpose and outputs
- For principles, compare stated design goals and rationale
- No inferences about unstated capabilities
Version / time window:
- SAM: Document accessed 2026-01-27 from ./stateless-agent-methodology.md
- BMAD: Version 6 (beta), accessed 2026-01-27 from ~/repos/BMAD-METHOD/
1.4 Scoring stance
Selected stance: narrative-only
Rationale: Both methodologies involve qualitative workflow design, agent coordination patterns, and architectural principles that resist numeric scoring. Evidence is primarily descriptive (workflow stages, design principles, artifact types) rather than quantitatively measurable. Narrative comparison allows proper treatment of tradeoffs and context-dependent strengths.
1.5 Tailored domain set
Essential domains (must cover)
Chosen essentials:
- Core approach / mechanism / workflow - How each methodology structures the development process
- Agent architecture and coordination - How agents are organized and communicate
- Context management and artifact flow - How information passes between stages
- Verification and quality gates - How correctness is ensured
- LLM limitation mitigation - How each addresses hallucination, context rot, training data staleness
- Adoption / learning curve - Prerequisites, implementation complexity, tooling requirements
- Scalability across project types - Adaptability from simple fixes to enterprise systems
Optional universal domains
Chosen optional domains:
- Maintainability / operability - Ongoing effort to use and update the methodology
- Ecosystem / support / community - Tooling, documentation, community resources
Domain-specific extensions
New domains (methodology-specific):
Prerequisite enforcement - How methodologies prevent agents from proceeding with incomplete information
- Why decision-critical: Directly impacts hallucination rates and implementation correctness
- Evidence resolves: RT-ICA gate documentation (SAM), implementation readiness checks (BMAD)
- Relates to: LLM limitation mitigation, verification gates
Multi-agent conflict prevention - Mechanisms to ensure consistent technical decisions across agents
- Why decision-critical: Critical for multi-epic or multi-developer projects
- Evidence resolves: Architecture documentation requirements, ADR patterns
- Relates to: Agent architecture, verification gates
Fresh context enforcement - Mechanisms to prevent context window degradation
- Why decision-critical: Directly addresses documented LLM limitation
- Evidence resolves: Session management patterns, context reset protocols
- Relates to: LLM limitation mitigation, core workflow
1.6 Stopping criteria
Verify readiness:
- ✅ Chosen essentials answered with decision-grade evidence
- ✅ Adding domains would not change recommendation (both methodologies have distinct strengths)
- ✅ Remaining unknowns are evidence-blocked (implementation details not in documentation)
Decision: READY_TO_COMPARE
2) Comparison Map (one-screen orientation)
2.1 One-sentence summaries
SAM in one sentence: A constraint-driven development framework that treats LLM agents as stateless computation engines, compensating for their limitations through pipeline architecture with fresh context per stage and independent forensic verification.
BMAD in one sentence: An AI-driven agile development framework with 21+ specialized agent personas, 50+ guided workflows across 4 phases, and scale-adaptive intelligence that structures development from brainstorming to implementation.
2.2 "Best for" and "avoid if" personas
SAM best for:
- Teams prioritizing verifiable correctness over development velocity
- Complex implementations requiring independent verification
- Projects where hallucination consequences are severe
- Teams comfortable implementing custom tooling
- Environments requiring audit trails and forensic review
SAM avoid if:
- Need immediate implementation without framework setup
- Small, low-risk changes where verification overhead exceeds value
- Teams unfamiliar with formal methods or verification patterns
- Seeking pre-built tooling and agent personas
BMAD best for:
- Teams wanting immediate productivity with pre-built agents and workflows
- Projects following agile development patterns
- Teams needing guidance through planning phases (PRD, architecture, stories)
- Brownfield projects requiring integration with existing codebases
- Teams scaling from bug fixes to enterprise systems with adaptive planning depth
BMAD avoid if:
- Need minimal tooling dependencies (BMAD requires Node.js installation)
- Working in non-JavaScript ecosystems without adaptation
- Require forensic-level verification for every implementation
- Prefer building custom agent frameworks rather than using opinionated structure
2.3 Non-negotiables check
SAM: PASS
- Supports LLM agents: Yes (designed specifically for LLM limitations)
- Addresses hallucination risks: Yes (forensic review, fresh context, no recall required)
- Produces verifiable outcomes: Yes (verification at every boundary, audit trail)
BMAD: PASS
- Supports LLM agents: Yes (designed for AI-driven development with AI IDEs)
- Addresses hallucination risks: Yes (context management, implementation readiness checks, code review workflows)
- Produces verifiable outcomes: Yes (structured artifacts, quality gates, testing integration)
3) Domain Worksheets
3.1 Core approach / mechanism / workflow
Definition: The fundamental structure and stages of the development process in each methodology.
Starter questions:
- What are the core primitives/steps?
- Where are decisions made (centralized vs distributed; human vs system)?
- What must be true for the approach to work (preconditions)?
- What is the typical failure mode when assumptions are violated?
Specialize:
- How does each methodology structure the progression from requirements to implementation?
- What is the role of human input vs AI automation at each stage?
- How does each methodology handle iteration and rework?
Evidence:
SAM (Source: stateless-agent-methodology.md lines 133-210):
- 7-stage pipeline: Discovery → Planning (RT-ICA) → Context Integration → Task Decomposition → Execution → Forensic Review → Final Verification
- Each stage produces artifacts consumed by next stage
- Fresh agent session per execution stage (line 503: "FRESH SESSION")
- Human input in Discovery stage; automated verification throughout
- Recursive loop between Execution and Forensic Review for rework (lines 565-577)
BMAD (Source: docs/reference/workflow-map.md, docs/tutorials/getting-started.md):
- 4-phase structure: Analysis (optional) → Planning → Solutioning → Implementation
- Each phase contains multiple workflows (50+ total workflows)
- Specialized agent personas (PM, Architect, Dev, SM, UX Designer, etc.) guide workflows
- Human facilitation throughout with structured elicitation
- Fresh chat recommended per workflow (getting-started.md line 71: "Always use fresh chats")
Comparability: COMPARABLE - both have documented multi-stage pipelines with artifact progression
Findings:
SAM:
- Linear 7-stage pipeline with clear inputs/outputs per stage
- Emphasis on stateless execution agents (fresh context)
- Built-in verification stages (Forensic Review, Final Verification)
- Designed for single-feature/task completion
- Minimal human guidance after Discovery stage
BMAD:
- 4-phase agile structure with 50+ workflow options
- Emphasis on guided facilitation (agent personas coach humans)
- Adaptive planning depth based on project scale (Quick Flow vs Method vs Enterprise)
- Designed for full project lifecycle (brainstorming to deployment)
- Continuous human collaboration with AI throughout
Tradeoffs:
What SAM optimizes for:
- Minimal context window usage (fresh sessions)
- Maximum verification (multiple independent review stages)
- Elimination of training data reliance (all context in task files)
What SAM trades away:
- Development velocity (more stages, more verification)
- Flexibility (linear pipeline less adaptable to agile iterations)
- Pre-built tooling (principles-focused, implementation required)
What BMAD optimizes for:
- Development velocity (immediate productivity with pre-built workflows)
- Agile iteration (flexible phase re-entry, course correction workflows)
- User experience (guided menus, explanations, facilitated elicitation)
What BMAD trades away:
- Forensic-level verification (relies on built-in code review workflow, not independent verification)
- Stateless purity (continuous context across workflows within phases)
- Installation simplicity (requires Node.js ecosystem)
Verdict: depends on project needs
- Confidence: high
- Rationale: SAM is verification-centric with stateless architecture; BMAD is velocity-centric with guided agile structure. Choice depends on whether verification overhead or development speed matters more for the project context.
3.2 Agent architecture and coordination
Definition: How agents are structured, specialized, and coordinated within each methodology.
Starter questions:
- How are agent roles defined?
- How do agents communicate and coordinate?
- What prevents agents from making conflicting decisions?
- How are agent contexts managed?
Specialize:
- What is the specialization model (single-purpose vs multi-purpose agents)?
- How does each methodology handle handoffs between agents?
- What mechanisms ensure agent consistency across the workflow?
Evidence:
SAM (Source: stateless-agent-methodology.md):
- Specialized agents per stage: Discovery Agent, Planning Agent, Context Integration Agent, Task Decomposition Agent, Execution Agent (lines 370-520)
- Single responsibility principle (line 110: "Each agent does exactly one thing")
- Message passing via artifacts (line 111: "Agents communicate via artifacts, not shared context")
- Fresh context per execution agent (line 503: "FRESH SESSION")
- Orchestrator coordinates execution-review cycle (lines 565-577)
- Forensic Review Agent is DIFFERENT from Execution Agent (line 536, emphasis in original)
BMAD (Source: README.md lines 19, docs/tutorials/getting-started.md, docs/explanation/preventing-agent-conflicts.md):
- 21+ specialized agent personas: PM, Architect, Developer, UX Designer, Scrum Master, Analyst, etc.
- Each agent has menu-driven workflows (getting-started.md line 89: "Load the PM agent")
- Architecture document prevents conflicts (preventing-agent-conflicts.md lines 44-53: ADRs establish shared standards)
- Artifacts provide shared context (workflow-map.md lines 69-83: "Context Management")
- Project-context.md for brownfield integration (workflow-map.md line 73)
Comparability: COMPARABLE - both define specialized agents with coordination mechanisms
Findings:
SAM:
- Functional specialization (each stage = one agent type)
- Strict isolation (stateless, fresh context per execution)
- Coordination via artifact handoffs only
- Independent verification agent (forensic reviewer separate from implementer)
- No persona/personality layer (pure functional roles)
BMAD:
- Role-based specialization (PM, Architect, Dev match job titles)
- Persona layer with facilitation patterns (agents guide humans through workflows)
- Coordination via shared artifacts AND continuous context within phases
- Self-review patterns (Dev agent does code-review workflow)
- Conflict prevention via architecture documentation (ADRs, standards)
Tradeoffs:
SAM's architectural advantages:
- Guaranteed independence of verification (separate forensic agent)
- Minimal context pollution (fresh sessions eliminate accumulated errors)
- Clear separation of concerns (one agent = one responsibility)
SAM's architectural challenges:
- Requires implementation of coordination layer (orchestrator)
- No built-in persona/facilitation patterns
- Human needs to understand stage boundaries explicitly
BMAD's architectural advantages:
- Immediate usability (pre-built agents with menus)
- Human-friendly personas (agents facilitate, not just execute)
- Built-in conflict prevention via architecture phase
BMAD's architectural challenges:
- Self-review patterns (same agent type reviews own work)
- Context continuity may accumulate errors within phases
- Requires fresh chats between workflows (documented but not enforced)
Verdict: depends on verification requirements
- Confidence: high
- Rationale: SAM's independent verification architecture is structurally superior for correctness; BMAD's persona-driven facilitation is structurally superior for usability and velocity. Evidence from SAM lines 536-559 shows explicit independent review design; BMAD preventing-agent-conflicts.md shows conflict prevention via documentation rather than architectural isolation.
3.3 Context management and artifact flow
Definition: How information and state pass between workflow stages and agents.
Starter questions:
- Where does state live (conversation, files, external systems)?
- How is context provided to agents at each stage?
- What prevents context from degrading over time?
- How is context validated and verified?
Specialize:
- What are the artifact types and their purposes?
- How does each methodology handle context window limitations?
- What mechanisms enforce artifact completeness?
Evidence:
SAM (Source: stateless-agent-methodology.md):
- All state externalized to artifact files (line 109: "All state lives in artifact files, not conversation")
- Artifact flow diagram (lines 214-256) shows complete pipeline
- Task files contain ALL context (line 115: "No recall required", line 495: "A fresh agent receiving only this task file can execute it without any other context")
- Fresh context per agent prevents degradation (line 108: "Fresh context per agent with exactly what it needs")
- Context window usage target <50% per agent (line 731: success metric)
BMAD (Source: docs/reference/workflow-map.md, docs/tutorials/getting-started.md):
- Artifacts: product-brief.md, PRD.md, architecture.md, ux-spec.md, epic files, story files, sprint-status.yaml (workflow-map.md lines 20-84)
- Context Management section (workflow-map.md lines 69-83): "Each document becomes context for the next phase"
- Fresh chat per workflow recommended (getting-started.md line 71: "Always start a fresh chat for each workflow")
- project-context.md for brownfield projects (workflow-map.md line 73)
- Implementation workflows load multiple context documents (workflow-map.md lines 76-84)
Comparability: COMPARABLE - both use artifact-based state management
Findings:
SAM:
- Strict externalization (zero conversation state)
- Complete self-contained task files (no external references needed)
- Single artifact consumption per stage (except forensic review which reads multiple)
- Enforced fresh sessions (architectural requirement)
- Minimal context principle (only what's needed for current task)
BMAD:
- Artifact-based with recommendations for fresh chats (not enforced)
- Progressive context building (each phase adds context for next)
- Multiple artifact loading (story context loads epics, PRD, architecture, UX)
- Context documentation for brownfield projects (project-context.md template)
- Scale-adaptive context depth (Quick Flow vs Method vs Enterprise)
Tradeoffs:
SAM's context advantages:
- Guaranteed context isolation (architectural enforcement)
- Complete task specification (no missing dependencies)
- Predictable context window usage (<50% per agent)
- Zero conversation-state bugs
SAM's context challenges:
- Task files must be comprehensive (higher upfront cost)
- No adaptive context depth (same rigor for all tasks)
- Requires tooling to generate complete task files
BMAD's context advantages:
- Adaptive context loading (only needed artifacts per workflow)
- Quick start (fewer artifacts for Quick Flow track)
- Human-readable documentation artifacts (PRD, architecture serve dual purpose)
- Built-in brownfield support (project-context.md pattern)
BMAD's context challenges:
- Fresh chat enforcement relies on discipline (not architectural)
- Multi-artifact loading increases context window pressure
- Context accumulation possible if fresh chats skipped
Verdict: A_better (SAM) for context reliability
- Confidence: high
- Rationale: SAM architecturally enforces fresh context and complete task files (lines 108-115), eliminating entire categories of context-related failures. BMAD's approach is more flexible and user-friendly but relies on developer discipline. Evidence: SAM line 731 targets <50% context usage; BMAD getting-started.md line 71 "should" rather than "must" for fresh chats.
3.4 Verification and quality gates
Definition: Mechanisms to ensure correctness, completeness, and quality throughout the development process.
Starter questions:
- What verification happens at each stage?
- Who/what performs verification (self-review vs independent review)?
- What are the gate criteria (when can work proceed)?
- How are verification failures handled?
Specialize:
- What is the independence level of verification (same agent vs different agent vs human)?
- How are verification steps enforced vs recommended?
- What metrics or criteria define "verification passed"?
Evidence:
SAM (Source: stateless-agent-methodology.md):
- Verification at boundaries (line 112: "Every stage validates previous stage's output")
- RT-ICA gate (lines 406-432): BLOCKS if prerequisites MISSING (line 419: "If MISSING: BLOCK and request information")
- Forensic Review stage (lines 534-559): INDEPENDENT agent reviews execution (line 536: "DIFFERENT from Execution Agent", emphasis in original)
- Final Verification stage (lines 583-606): validates against original goals
- Recursive quality loops (lines 565-577): iterate until forensic review passes
- Deterministic backpressure (line 113: "Always run deterministic checks (tests, linters, static analysis, checklists)")
- Success metrics (lines 724-733): <5% hallucination rate, 100% methodology compliance, >70% first-pass success
BMAD (Source: docs/reference/workflow-map.md, docs/tutorials/getting-started.md, docs/explanation/preventing-agent-conflicts.md):
- Implementation readiness check (workflow-map.md line 46: "Gate check before implementation", produces "PASS/CONCERNS/FAIL decision")
- Code review workflow (workflow-map.md line 56: "Validate implementation quality", produces "Approved or changes requested")
- Architecture prevents conflicts (preventing-agent-conflicts.md lines 44-69: ADRs establish shared standards before implementation)
- Retrospective workflow (workflow-map.md line 59: "Review after epic completion")
- Fresh chat recommendations (getting-started.md line 71: "prevents context limitations from causing issues")
Comparability: COMPARABLE - both have verification mechanisms with different enforcement levels
Findings:
SAM:
- Multi-layered verification (RT-ICA gate, forensic review, final verification)
- Architectural independence (forensic reviewer != implementer)
- Hard gates (RT-ICA BLOCKS execution if prerequisites missing)
- Deterministic verification (tests, linters, static analysis as ground truth)
- Quantified success criteria (<5% hallucination, >70% first-pass)
- Self-verification (execution agent) AND independent verification (forensic agent)
BMAD:
- Phase-based verification (readiness check before implementation, code review after)
- Workflow-based independence (separate workflow, but same agent type for self-review)
- Soft gates (readiness check can be CONCERNS vs FAIL, decision point for humans)
- Review patterns (retrospective, code review as recommended workflows)
- Preventive verification (architecture phase prevents conflicts before they occur)
- Self-review primary pattern (Dev agent reviews Dev agent work)
Tradeoffs:
SAM's verification advantages:
- Structural independence (impossible for implementer to skip their own review)
- Hard blocking gates (cannot proceed with missing prerequisites)
- Multiple verification layers (self + forensic + final)
- Quantified targets (measurable success criteria)
SAM's verification challenges:
- Higher overhead (multiple review stages per task)
- Slower iteration (hard gates block progress)
- Requires separate verification agent implementation
BMAD's verification advantages:
- Lightweight for simple work (Quick Flow track has minimal verification)
- Preventive approach (architecture prevents conflicts vs detecting them)
- Integrated into workflow (readiness check, code review as standard workflows)
- Human decision points (CONCERNS allows proceeding with awareness)
BMAD's verification challenges:
- Self-review patterns (same agent type reviews work)
- Verification skippable (workflows are recommended, not enforced)
- No independent forensic review architecture
- No quantified verification targets
Verdict: A_better (SAM) for verification rigor
- Confidence: high
- Rationale: SAM's independent forensic review (lines 534-559) is architecturally superior to self-review. Evidence shows SAM's RT-ICA gate is a hard BLOCK (line 419), while BMAD's readiness check allows CONCERNS with human judgment. SAM has quantified success metrics (lines 724-733); BMAD verification criteria not quantified in documentation. For projects where verification overhead is acceptable, SAM's approach eliminates structural verification gaps.
3.5 LLM limitation mitigation
Definition: How each methodology addresses specific documented limitations of LLMs (hallucination, context rot, training data staleness, goal displacement).
Starter questions:
- How does each methodology address hallucination risks?
- What mechanisms prevent context window degradation?
- How is training data staleness handled?
- How are goal displacement and shortcut-taking prevented?
Specialize:
- Which LLM limitations are explicitly acknowledged in documentation?
- What are the specific mitigation strategies for each limitation?
- How are mitigations enforced vs recommended?
Evidence:
SAM (Source: stateless-agent-methodology.md lines 29-99):
- Explicitly documented limitations (lines 30-39): context rot, training data staleness, training data overconfidence, completion optimization, no self-reflective knowledge gaps, goal displacement
- Context rot mitigation (lines 40-54): concise prompts, modularize content, manage conversation state, fresh sessions
- Training data mitigation (line 115: "No recall required - Task files contain all answers needed")
- Hallucination mitigation (line 112: "Verification at boundaries", line 536: independent forensic review)
- Goal displacement mitigation (line 113: "Deterministic backpressure - Always run deterministic checks")
- Structural enforcement (lines 117-127): "Methodology IS the task file structure", cannot skip what structures the task
BMAD (Source: docs/tutorials/getting-started.md, docs/reference/workflow-map.md):
- Context management (getting-started.md line 71: "Fresh chats prevent context limitations from causing issues")
- Guided elicitation (README.md line 14: "agents and facilitated workflow act as expert collaborators")
- Structured artifacts (workflow-map.md lines 69-71: "Each document becomes context for the next phase")
- Implementation readiness gate (workflow-map.md line 46: validates cohesion before implementation)
- Architecture phase prevents agent conflicts (preventing-agent-conflicts.md)
Comparability: PARTIALLY COMPARABLE
- SAM explicitly documents LLM limitations with targeted mitigations
- BMAD implicitly addresses limitations through workflow structure without explicit limitation catalog
- Can compare mitigation strategies where both are documented
Findings:
SAM:
- Explicit limitation taxonomy (6 documented LLM limitations with citations)
- Targeted mitigation per limitation (context rot → fresh sessions, training data → no recall, goal displacement → deterministic backpressure)
- Architectural enforcement (structural, not behavioral instructions)
- Quantified targets (lines 724-733: <5% hallucination rate, 100% methodology compliance)
- Research citations (lines 44-47: academic papers on context length effects)
BMAD:
- Implicit limitation handling (fresh chats recommended, structured context)
- Process-based mitigation (guided workflows, architecture documentation)
- Discipline-based enforcement (recommendations, best practices)
- No explicit limitation taxonomy in core documentation
- Focus on productivity enhancement rather than limitation compensation
Tradeoffs:
SAM's mitigation advantages:
- Explicit awareness (documented limitation catalog)
- Research-grounded (academic citations for context effects)
- Architectural enforcement (cannot skip mitigations)
- Measurable targets (quantified success metrics)
SAM's mitigation challenges:
- Higher overhead (mitigations add complexity)
- Requires deep understanding of LLM limitations
- May over-engineer for simple tasks
BMAD's mitigation advantages:
- Transparent to users (mitigations embedded in workflows)
- Adaptive overhead (Quick Flow vs Method vs Enterprise)
- Focus on positive patterns (what to do vs what to avoid)
BMAD's mitigation challenges:
- No explicit limitation documentation (may miss emerging issues)
- Reliance on discipline (fresh chats recommended but not enforced)
- No quantified mitigation targets
Verdict: A_better (SAM) for explicit LLM limitation mitigation
- Confidence: high
- Rationale: SAM's explicit limitation taxonomy (lines 30-39) with targeted architectural mitigations is superior to implicit handling. Evidence: SAM provides research citations (lines 44-47), quantified targets (lines 724-733), and structural enforcement (line 127). BMAD's approach is effective but lacks explicit limitation awareness that would help teams understand why certain practices matter.
3.6 Prerequisite enforcement
Definition: Mechanisms to prevent agents from proceeding with incomplete or missing information.
Starter questions:
- How does each methodology detect missing prerequisites?
- What happens when prerequisites are missing?
- Is enforcement automatic or manual?
- Can enforcement be bypassed?
Specialize:
- What constitutes a "prerequisite" in each methodology?
- How are prerequisites documented and checked?
- What is the recovery path when prerequisites are discovered missing mid-workflow?
Evidence:
SAM (Source: stateless-agent-methodology.md lines 406-432):
- RT-ICA stage (Reverse Thinking - Information Completeness Assessment)
- Lines 417-420: "List all prerequisites for success. Mark each: AVAILABLE | DERIVABLE | MISSING. If MISSING: BLOCK and request information. If all AVAILABLE/DERIVABLE: PROCEED"
- Line 432: "Gate: Cannot proceed if any prerequisite is MISSING"
- Structural enforcement (blocking gate prevents execution)
BMAD (Source: docs/reference/workflow-map.md, docs/tutorials/getting-started.md):
- Implementation readiness check (workflow-map.md line 46): "Gate check before implementation", produces "PASS/CONCERNS/FAIL decision"
- getting-started.md line 119: "Validates cohesion across all planning documents"
- Recommended workflow (line 117: "Highly Recommended")
- Human decision point (CONCERNS allows proceeding with awareness vs FAIL)
Comparability: COMPARABLE - both have prerequisite checking mechanisms with different enforcement levels
Findings:
SAM:
- RT-ICA is a mandatory stage in pipeline (line 406: Stage 2)
- Hard blocking gate (line 419: "If MISSING: BLOCK and request information")
- No bypass mechanism documented
- Prerequisite status is binary: AVAILABLE/DERIVABLE = proceed, MISSING = block
- Prevents execution stage from starting without complete context
BMAD:
- Implementation readiness check is recommended (getting-started.md line 117: "Highly Recommended")
- Soft gate with human judgment (PASS/CONCERNS/FAIL)
- CONCERNS allows proceeding with awareness
- Check happens between solutioning and implementation phases
- Validates document cohesion rather than information completeness
Tradeoffs:
SAM's prerequisite advantages:
- Impossible to skip (mandatory stage in pipeline)
- Binary decision (no ambiguity about proceeding)
- Catches missing information before implementation starts
- Structural enforcement (architectural gate)
SAM's prerequisite challenges:
- May block progress on recoverable information gaps
- No documented override for low-risk scenarios
- Requires careful prerequisite identification
BMAD's prerequisite advantages:
- Flexible (CONCERNS allows proceeding with awareness)
- Human judgment (team decides risk tolerance)
- Can be skipped for simple work (Quick Flow track)
- Checks cohesion (documents consistent with each other)
BMAD's prerequisite challenges:
- Skippable (recommended but not enforced)
- Subjective criteria (PASS/CONCERNS/FAIL judgment-based)
- May miss information gaps if check skipped
Verdict: A_better (SAM) for prerequisite enforcement
- Confidence: high
- Rationale: SAM's RT-ICA gate is a hard architectural BLOCK (line 419) that prevents execution with missing prerequisites. BMAD's readiness check is recommended and allows flexible judgment. For high-risk projects where proceeding with missing information is unacceptable, SAM's approach is structurally superior. For adaptive project needs, BMAD's flexibility may be preferred despite lower rigor.
3.7 Multi-agent conflict prevention
Definition: Mechanisms to ensure consistent technical decisions when multiple agents implement different parts of a system.
Starter questions:
- How does each methodology prevent agents from making conflicting technical decisions?
- What shared context ensures consistency?
- How are conflicts detected and resolved?
- What happens when agents have implemented conflicting patterns?
Specialize:
- What documentation or artifacts provide shared technical standards?
- How is consistency enforced across agent implementations?
- What conflict types are addressed (API style, database design, naming, etc.)?
Evidence:
SAM (Source: stateless-agent-methodology.md):
- Context Integration stage (lines 435-460): "Ground the design in actual codebase reality", "Find conflicts, contradictions, technical constraints"
- Task files embed methodology (line 489: "Methodology to use")
- Single agent per execution (lines 499-528): fresh session per task
- NOT_COMPARABLE: SAM documentation does not explicitly address multi-agent simultaneous implementation or conflict prevention between parallel execution agents
BMAD (Source: docs/explanation/preventing-agent-conflicts.md, docs/explanation/why-solutioning-matters.md):
- Solutioning phase (architecture) prevents conflicts (preventing-agent-conflicts.md lines 44-53): "Architecture documentation prevents this by establishing shared standards"
- ADRs (Architecture Decision Records) document technical choices (preventing-agent-conflicts.md lines 46-52)
- Architecture document maps FRs to technical approach (preventing-agent-conflicts.md lines 54-59)
- Standards documented: directory structure, naming conventions, code organization, testing patterns (lines 61-67)
- why-solutioning-matters.md lines 20-29: Example of REST vs GraphQL conflict and how architecture prevents it
- Explicit conflict types addressed (preventing-agent-conflicts.md lines 87-95): API style, database design, state management, styling, testing
Comparability: LIMITED - SAM's serial execution model vs BMAD's multi-epic parallel implementation create different conflict scenarios
Findings:
SAM:
- Serial execution model (one task at a time)
- Context Integration stage catches codebase conflicts
- Task files specify exact methodology and constraints
- Conflict detection happens during Context Integration (before task decomposition)
- NOT_COMPARABLE: SAM documentation does not describe simultaneous multi-agent implementation scenarios
BMAD:
- Multi-epic parallel implementation supported
- Architecture phase (Solutioning) establishes shared standards BEFORE implementation
- ADRs document explicit technical decisions
- Conflicts prevented rather than detected (proactive approach)
- Explicit conflict taxonomy (6 documented conflict types)
Tradeoffs:
SAM's conflict approach:
- Serial execution eliminates simultaneous conflicts
- Context Integration catches existing codebase conflicts
- Task-level methodology specification ensures consistency
SAM's conflict limitations:
- Serial execution may be slower for multi-epic projects
- No documented approach for parallel agent implementations
- Conflict prevention relies on serial ordering
BMAD's conflict approach:
- Proactive conflict prevention (architecture before implementation)
- Explicit technical decision documentation (ADRs)
- Supports parallel implementation of multiple epics
- Comprehensive conflict taxonomy
BMAD's conflict limitations:
- Relies on architecture documentation quality
- Agents must read and follow architecture (discipline-based)
- No architectural enforcement of consistency
Verdict: depends on project structure
- Confidence: medium (limited comparability due to different execution models)
- Rationale: SAM's serial execution model eliminates certain conflict classes that BMAD explicitly addresses. For single-epic or serial work, SAM's approach is sufficient. For multi-epic projects with parallel implementation, BMAD's explicit conflict prevention via architecture phase is more directly applicable. Evidence: SAM lines 435-460 show conflict detection in Context Integration; BMAD preventing-agent-conflicts.md lines 44-95 show comprehensive conflict prevention taxonomy and ADR approach.
3.8 Fresh context enforcement
Definition: Mechanisms to prevent context window degradation by ensuring agents start with clean, focused context.
Starter questions:
- How does each methodology ensure agents work with fresh context?
- Is fresh context enforcement architectural or discipline-based?
- What prevents context accumulation over time?
- How is context reset handled in each workflow?
Specialize:
- Is fresh context a recommendation or architectural requirement?
- What tooling or structure enforces fresh context?
- How does fresh context interact with multi-stage workflows?
Evidence:
SAM (Source: stateless-agent-methodology.md):
- Architectural requirement (line 503: "FRESH SESSION" in all caps)
- Execution agent properties (lines 514-519): "Fresh session: No accumulated context. No recall needed: All answers in task file. Embedded verification: Cannot skip methodology"
- Context usage target (line 731: "<50%" per agent)
- Fresh context per agent (line 108: "Fresh context per agent with exactly what it needs")
BMAD (Source: docs/tutorials/getting-started.md, docs/reference/workflow-map.md):
- Discipline-based recommendation (getting-started.md line 71: "Always start a fresh chat for each workflow")
- Repeated emphasis (line 27:
…(truncated)