Files
BMAD-METHOD/docs/explanation/architecture/preventing-agent-conflicts.md
forcetrainer 12d3492e0c Add link auditor, reorganize documentation, and README update (#1277)
* feat: add link auditor tools and fix broken docs links

- Add audit-doc-links.js to scan docs for broken links with auto-resolution
- Add fix-doc-links.js to apply suggested fixes (dry-run by default)
- Remove stale "Back to Core Concepts" breadcrumb links
- Update BMad acronym to "Breakthrough Method of Agile AI Driven Development"
- Update README links to docs.bmad-method.org
- Simplify upgrade callout in getting-started tutorial

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: reorganize docs structure and archive v4 tutorial

- Remove unused section index files (tutorials, how-to, explanation, reference)
- Move getting-started-bmadv4.md to _archive
- Update quick-start-bmgd.md to remove archived file reference
- Update upgrade-to-v6.md
- Update astro.config.mjs for new structure

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix: ignore underscore directories in link checker

Update check-doc-links.js to skip _archive, _planning, and other
underscore-prefixed directories when validating links.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: add v4 users section to README

Add links to v4 documentation archive and upgrade guide for users
migrating from previous versions.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* feat: convert docs to site-relative links and add validation tools

- Convert all relative links (./  ../) to site-relative paths (/path/)
- Strip .md extensions and use trailing slashes for Astro/Starlight
- Add fix-doc-links.js to convert relative links to site-relative
- Add validate-doc-links.js to check links point to existing files
- Remove old audit-doc-links.js and check-doc-links.js
- Update build-docs.js to use new validation script
- Add npm scripts: docs:fix-links, docs:validate-links
- Update style guide with validation steps

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: standardize acronym to BMad across documentation

Replace incorrect "BMAD" with correct "BMad" in text and frontmatter
while preserving "BMAD-METHOD" in GitHub URLs.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: fix BMad acronym and remove draft README

- Correct acronym to "Breakthrough Method of Agile AI Driven Development"
- Remove unused README-draft.md

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: standardize BMad acronym in README

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: standardize FAQ format across all FAQ pages

- Add TOC with jump links under "## Questions"
- Use ### headers for questions (no Q: prefix)
- Direct answers without **A:** prefix
- Remove horizontal rules and "Related Documentation" sections
- End each FAQ with issue/Discord CTA
- Update style guide with new FAQ guidelines
- Delete redundant faq/index.md (sidebar handles navigation)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix: use repo-relative links with .md for GitHub compatibility

Convert all documentation links to repo-relative format (/docs/path/file.md)
so they work when browsing on GitHub. The rehype plugin strips /docs/ prefix
and converts .md to trailing slash at build time for Astro/Starlight.

- Update rehype-markdown-links.js to strip /docs/ prefix from absolute paths
- Update fix-doc-links.js to generate /docs/ prefixed paths with .md extension
- Convert 217 links across 64 files to new format

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix: handle /docs/ prefix in link validator

Update resolveLink to strip /docs/ prefix from repo-relative links
before checking if files exist.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: restore FAQ index page

Re-add the FAQ index page that was accidentally deleted, with
updated repo-relative link format.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Alex Verkhovsky <alexey.verkhovsky@gmail.com>
2026-01-10 02:55:33 +08:00

3.3 KiB

title, description
title description
Preventing Agent Conflicts How architecture prevents conflicts when multiple agents implement a system

When multiple AI agents implement different parts of a system, they can make conflicting technical decisions. Architecture documentation prevents this by establishing shared standards.


Common Conflict Types

API Style Conflicts

Without architecture:

  • Agent A uses REST with /users/{id}
  • Agent B uses GraphQL mutations
  • Result: Inconsistent API patterns, confused consumers

With architecture:

  • ADR specifies: "Use GraphQL for all client-server communication"
  • All agents follow the same pattern

Database Design Conflicts

Without architecture:

  • Agent A uses snake_case column names
  • Agent B uses camelCase column names
  • Result: Inconsistent schema, confusing queries

With architecture:

  • Standards document specifies naming conventions
  • All agents follow the same patterns

State Management Conflicts

Without architecture:

  • Agent A uses Redux for global state
  • Agent B uses React Context
  • Result: Multiple state management approaches, complexity

With architecture:

  • ADR specifies state management approach
  • All agents implement consistently

How Architecture Prevents Conflicts

1. Explicit Decisions via ADRs

Every significant technology choice is documented with:

  • Context (why this decision matters)
  • Options considered (what alternatives exist)
  • Decision (what we chose)
  • Rationale (why we chose it)
  • Consequences (trade-offs accepted)

2. FR/NFR-Specific Guidance

Architecture maps each functional requirement to technical approach:

  • FR-001: User Management → GraphQL mutations
  • FR-002: Mobile App → Optimized queries

3. Standards and Conventions

Explicit documentation of:

  • Directory structure
  • Naming conventions
  • Code organization
  • Testing patterns

Architecture as Shared Context

Think of architecture as the shared context that all agents read before implementing:

PRD: "What to build"
     ↓
Architecture: "How to build it"
     ↓
Agent A reads architecture → implements Epic 1
Agent B reads architecture → implements Epic 2
Agent C reads architecture → implements Epic 3
     ↓
Result: Consistent implementation

Key ADR Topics

Common decisions that prevent conflicts:

Topic Example Decision
API Style GraphQL vs REST vs gRPC
Database PostgreSQL vs MongoDB
Auth JWT vs Sessions
State Management Redux vs Context vs Zustand
Styling CSS Modules vs Tailwind vs Styled Components
Testing Jest + Playwright vs Vitest + Cypress

Anti-Patterns

Implicit Decisions

"We'll figure out the API style as we go" → Leads to inconsistency

Over-Documentation

Every minor choice documented → Analysis paralysis, wasted time

Stale Architecture

Document written once, never updated → Agents follow outdated patterns

Correct Approach

  • Document decisions that cross epic boundaries
  • Focus on conflict-prone areas
  • Update architecture as you learn
  • Use correct-course for significant changes