Aurora System + BMAD Integration Proposal

Date: 2025-12-17 Author: Coby Status: Draft for Discussion Audience: Graydon, Coby, Development Team

Executive Summary

This document proposes a hybrid architecture that combines the strengths of Aurora System (persistent infrastructure, visibility, coordination) with BMAD (structured workflows, high-quality outputs, artifact-based persistence). The goal is to enable consistent, high-quality development processes across the entire team while solving the multi-developer coordination challenge.

Current State Analysis

Aurora System Strengths

Capability	Value
Production-grade infrastructure	K8s deployment, circuit breakers, health checks, escalation tiers
Human oversight controls	Self-task creation disabled, audit trails, `created_by` requirements
GraphRAG knowledge base	Semantic search over project context and decisions
Dashboard visibility	Real-time view of agent status, tasks, escalations
Context libraries	Structured file-based context per agent
Founder OS	Comprehensive founder context tracking

BMAD Strengths

Capability	Value
Structured workflows	Step-by-step processes with validation and checklists
High-quality LLM	Claude (Opus 4.5) for complex reasoning, architecture, code review
Artifact-based persistence	PRDs, stories, architecture docs are the "memory"
Git as source of truth	Everything version-controlled, auditable, mergeable
On-demand execution	No idle resource consumption
Proven quality	Epic 1 & 2 delivered successfully using this process

Current Challenges

Challenge	Aurora Impact	BMAD Impact
Multi-developer conflicts	Shared agent state can conflict	Each dev has isolated session
LLM quality	Ollama good but not Claude-level	Claude API costs scale with usage
Resource cost	30 pods running continuously	Only runs when developer working
Workflow structure	Generic prompts, no structured execution	Full workflow engine with validation
Persistence model	DB state + file context	Git artifacts

Problem Statement

The core question: How do we enable all developers to follow the same high-quality development process (that produced Epic 1 & 2 success) while maintaining visibility and coordination across the team?

What We Need

Consistent process - Every developer follows BMAD workflows
Quality outputs - Architecture decisions, code review at Claude quality level
Shared visibility - Team can see project status, who's working on what
No conflicts - Multiple developers can work simultaneously
Artifact persistence - Decisions and context survive across sessions
Cost efficiency - Don't pay for idle infrastructure

Proposed Architecture Options

Option A: Per-Developer Local + Shared Visibility Layer

┌─────────────────────────────────────────────────────────────────────────┐
│                         Per-Developer Setup                              │
│                                                                          │
│   Coby's Machine              Graydon's Machine          Menley's Machine│
│  ┌─────────────────┐        ┌─────────────────┐        ┌───────────────┐│
│  │ Claude Code     │        │ Claude Code     │        │ Claude Code   ││
│  │ + BMAD          │        │ + BMAD          │        │ + BMAD        ││
│  │ + Local Ollama  │        │ + Local Ollama  │        │ + Local Ollama││
│  └────────┬────────┘        └────────┬────────┘        └───────┬───────┘│
│           │                          │                         │        │
│           └──────────────────────────┼─────────────────────────┘        │
│                                      │                                   │
│                                      ▼                                   │
│                        ┌─────────────────────────┐                      │
│                        │      Git Repository     │                      │
│                        │  - BMAD artifacts       │                      │
│                        │  - Agent definitions    │                      │
│                        │  - Source code          │                      │
│                        └────────────┬────────────┘                      │
│                                     │                                    │
│                                     ▼                                    │
│                        ┌─────────────────────────┐                      │
│                        │   Shared Visibility     │                      │
│                        │   (ICP or Lightweight)  │                      │
│                        │  - Sprint dashboard     │                      │
│                        │  - Story status         │                      │
│                        │  - Team activity        │                      │
│                        └─────────────────────────┘                      │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

How it works:

Each developer runs Claude Code + BMAD locally
BMAD workflows produce artifacts (PRDs, stories, architecture)
Artifacts commit to shared Git repository
Git webhooks update shared visibility layer
Dashboard shows team-wide status

Pros:

No multi-developer conflicts (isolated sessions)
Claude quality for all developers
Cost-efficient (only runs when working)
Simple setup (just install tools)
Works offline with local Ollama

Cons:

No persistent agent "memory" across sessions
Each session starts fresh (but loads context from artifacts)
Requires discipline to commit artifacts

Option B: Aurora as Coordination Layer + BMAD for Execution

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                          │
│   Developer Machines                    Aurora Infrastructure            │
│  ┌─────────────────────┐              ┌─────────────────────────────┐  │
│  │ Claude Code + BMAD  │              │  Coordination Services       │  │
│  │                     │◄────────────►│  - Task assignment           │  │
│  │ Executes workflows  │   REST API   │  - Status tracking           │  │
│  │ Produces artifacts  │              │  - GraphRAG (context search) │  │
│  │ High-quality LLM    │              │  - Escalation management     │  │
│  └─────────────────────┘              │  - Dashboard                 │  │
│           │                           └─────────────────────────────┘  │
│           │                                        │                    │
│           ▼                                        │                    │
│  ┌─────────────────────┐                          │                    │
│  │  Git Repository     │◄─────────────────────────┘                    │
│  │  (Source of Truth)  │         Syncs artifacts to GraphRAG           │
│  └─────────────────────┘                                                │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

How it works:

Aurora provides coordination (task queue, status, search)
Developers use Claude Code + BMAD for actual work
Artifacts sync to both Git and GraphRAG
Aurora agents remain available for simple queries (via Ollama)
Complex work routes to Claude via developer machines

Pros:

Leverages Aurora infrastructure investment
GraphRAG provides searchable project context
Dashboard visibility for whole team
Escalation system for blockers
Best of both worlds

Cons:

More complex integration
Need to define clear boundaries (what goes where)
Aurora still needs hosting (but lighter load)

Option C: ICP-Native Coordination + Local Execution

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                          │
│   Developer Machines                    ICP Canisters                    │
│  ┌─────────────────────┐              ┌─────────────────────────────┐  │
│  │ Claude Code + BMAD  │              │  Project Registry Canister   │  │
│  │                     │◄────────────►│  - Story status              │  │
│  │ Local execution     │   IC Agent   │  - Sprint tracking           │  │
│  │ Claude API          │              │  - Developer assignments     │  │
│  │ Local Ollama        │              │  - Artifact index            │  │
│  └─────────────────────┘              └─────────────────────────────┘  │
│           │                                        │                    │
│           │                           ┌────────────┴────────────┐      │
│           │                           │  Notification Canister  │      │
│           │                           │  - Story ready for review│      │
│           │                           │  - Blocker alerts        │      │
│           │                           │  - Sprint updates        │      │
│           ▼                           └─────────────────────────┘      │
│  ┌─────────────────────┐                                                │
│  │  Git Repository     │                                                │
│  │  (Source of Truth)  │                                                │
│  └─────────────────────┘                                                │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

How it works:

ICP canisters handle coordination (status, assignments, notifications)
All LLM work happens locally (Claude Code + BMAD)
Git remains source of truth for artifacts
ICP provides decentralized, always-available coordination
No central server to maintain

Pros:

Decentralized coordination (no single point of failure)
Low cost (ICP cycles are cheap for simple state)
Aligns with Hello World DAO's ICP focus
No server maintenance

Cons:

ICP can't run LLMs (still need local/API)
No background processing (no work loops)
Limited to coordination, not execution

ICP Feasibility Analysis

What ICP Can Handle

Feature	Feasibility	Notes
Story/task registry	Yes	Simple CRUD, fits canister model
Sprint status tracking	Yes	State storage is ICP's strength
Developer assignments	Yes	Access control via principals
Artifact index	Yes	Metadata + links to Git/IPFS
Notifications	Partial	Can store, but no push (needs polling)
Search	Limited	Basic queries yes, semantic search no

What ICP Cannot Handle

Feature	Reason
LLM inference	No GPU, instruction limits
Background work loops	Canisters don't run continuously
Vector search (pgvector)	No native support
Real-time updates	No WebSocket/SSE
Large file storage	Expensive, use IPFS instead

Recommended ICP Scope

If we go with ICP for coordination:

candid

// Project Registry Canister
service : {
  // Story management
  create_story : (StoryInput) -> (StoryId);
  update_story_status : (StoryId, Status) -> (Result);
  get_stories_by_sprint : (SprintId) -> (vec Story);
  assign_story : (StoryId, Principal) -> (Result);

  // Sprint tracking
  get_sprint_status : (SprintId) -> (SprintStatus);
  get_developer_workload : (Principal) -> (vec Story);

  // Artifact registry
  register_artifact : (ArtifactMetadata) -> (ArtifactId);
  search_artifacts : (Query) -> (vec ArtifactMetadata);

  // Activity feed
  log_activity : (ActivityEvent) -> ();
  get_recent_activity : (nat) -> (vec ActivityEvent);
}

Comparison Matrix

Criteria	Aurora Only	BMAD Only	Option A (Local + Visibility)	Option B (Aurora + BMAD)	Option C (ICP + BMAD)
LLM Quality	Ollama	Claude	Claude	Claude + Ollama	Claude
Multi-dev safety	Conflicts	Isolated	Isolated	Isolated	Isolated
Setup complexity	High	Low	Low	Medium	Medium
Ongoing cost	High (k8s)	Low (API)	Low	Medium	Low (cycles)
Visibility	Dashboard	Local only	Shared	Full	Basic
Offline work	No	Limited	Ollama	Ollama	Ollama
ICP alignment	Off-chain	Off-chain	Partial	Partial	Native
Work loops	Native	On-demand	On-demand	Optional	On-demand

Key Questions for Discussion

About Current Aurora System

What specific value does the 5-minute work loop provide?
- If agents are idle 95% of the time, is continuous polling worth the cost?
- Could the same value be achieved with on-demand invocation?
How do you envision multi-developer usage?
- If Coby and Graydon both invoke the architect agent, whose context wins?
- Should each developer have isolated agent instances?
What's the LLM quality bar for different tasks?
- Which tasks truly need Claude-level quality?
- Which tasks are fine with Ollama?

About Integration

What would you want to keep from Aurora in a hybrid model?
- Dashboard?
- GraphRAG?
- Escalation system?
- Agent personas/context libraries?
Would you accept BMAD workflows as the primary execution engine?
- With artifacts as the persistence model?
- Claude for quality-critical tasks?
What's the minimum viable shared layer?
- Just sprint status?
- Or full GraphRAG + dashboard?

About ICP

How important is ICP-native vs pragmatic off-chain?
- Is there value in dogfooding ICP for internal tools?
- Or is off-chain acceptable for dev infrastructure?
Would an ICP coordination layer be sufficient?
- Status tracking, assignments, notifications on ICP
- LLM execution remains local

Recommended Path Forward

Phase 1: Validate Hybrid Model (2-4 weeks)

Coby continues with BMAD for Hello World DAO development
Document the workflow - What artifacts are produced, how context is maintained
Graydon experiments with using BMAD for a small task
Compare outputs - Same task with Aurora-only vs BMAD

Phase 2: Define Integration Points (2-4 weeks)

Identify what Aurora should handle - Visibility, coordination, search
Identify what BMAD should handle - Workflow execution, artifact generation
Design the bridge - How artifacts flow between systems

Phase 3: Build Shared Layer (4-8 weeks)

Option A - Simple visibility dashboard (Git webhooks → dashboard)
Option B - Aurora lite (keep GraphRAG + dashboard, remove work loops)
Option C - ICP canister for coordination

Phase 4: Team Rollout

Onboard Menley with the hybrid process
Document the full workflow for future developers
Iterate based on feedback

Appendix: Technical Details

A. BMAD Artifact Flow

Developer starts story
         │
         ▼
┌─────────────────────┐
│ Load Story Context  │ ◄── story-context.xml (generated by story-context workflow)
│ - PRD requirements  │
│ - Architecture refs │
│ - Existing code     │
└─────────────────────┘
         │
         ▼
┌─────────────────────┐
│ Execute dev-story   │ ◄── BMAD workflow with Claude
│ - Implement tasks   │
│ - Write tests       │
│ - Update story.md   │
└─────────────────────┘
         │
         ▼
┌─────────────────────┐
│ Commit artifacts    │ ◄── Git commit
│ - Code changes      │
│ - Updated story.md  │
│ - Test results      │
└─────────────────────┘
         │
         ▼
┌─────────────────────┐
│ Next developer can  │ ◄── Picks up from story.md status
│ continue or review  │
└─────────────────────┘

B. Aurora Agent Runtime Summary

Language: Python (FastAPI)
LLM: Ollama (llama3.2, mistral)
Database: PostgreSQL + pgvector
Orchestration: Kubernetes (k3s)
Work pattern: 5-minute polling loop
State: DB tables (agent_tasks, graphrag_entities, circuit_breaker_state)

C. Proposed ICP Canister Interface

See project-registry.did (to be created) for full Candid interface.

Next Steps

Graydon reviews this document and provides feedback
Schedule discussion to align on preferred option
Agree on Phase 1 experiment parameters
Begin implementation of chosen approach

"Together, we can do anything."

Login Required

Aurora System + BMAD Integration Proposal ​

Executive Summary ​

Current State Analysis ​

Aurora System Strengths ​

BMAD Strengths ​

Current Challenges ​

Problem Statement ​

What We Need ​

Proposed Architecture Options ​

Option A: Per-Developer Local + Shared Visibility Layer ​

Option B: Aurora as Coordination Layer + BMAD for Execution ​

Option C: ICP-Native Coordination + Local Execution ​

ICP Feasibility Analysis ​

What ICP Can Handle ​

What ICP Cannot Handle ​

Recommended ICP Scope ​

Comparison Matrix ​

Key Questions for Discussion ​

About Current Aurora System ​

About Integration ​

About ICP ​

Recommended Path Forward ​

Phase 1: Validate Hybrid Model (2-4 weeks) ​

Phase 2: Define Integration Points (2-4 weeks) ​

Phase 3: Build Shared Layer (4-8 weeks) ​

Phase 4: Team Rollout ​

Appendix: Technical Details ​

A. BMAD Artifact Flow ​

B. Aurora Agent Runtime Summary ​

C. Proposed ICP Canister Interface ​

Next Steps ​

Aurora System + BMAD Integration Proposal

Executive Summary

Current State Analysis

Aurora System Strengths

BMAD Strengths

Current Challenges

Problem Statement

What We Need

Proposed Architecture Options

Option A: Per-Developer Local + Shared Visibility Layer

Option B: Aurora as Coordination Layer + BMAD for Execution

Option C: ICP-Native Coordination + Local Execution

ICP Feasibility Analysis

What ICP Can Handle

What ICP Cannot Handle

Recommended ICP Scope

Comparison Matrix

Key Questions for Discussion

About Current Aurora System

About Integration

About ICP

Recommended Path Forward

Phase 1: Validate Hybrid Model (2-4 weeks)

Phase 2: Define Integration Points (2-4 weeks)

Phase 3: Build Shared Layer (4-8 weeks)

Phase 4: Team Rollout

Appendix: Technical Details

A. BMAD Artifact Flow

B. Aurora Agent Runtime Summary

C. Proposed ICP Canister Interface

Next Steps