BMAD Method vs Ruflo (Claude Flow) vs Gas Town

While Claude Code and similar tools are changing the way we write software, they still hit fundamental limitations: one context window, one task at a time, and context loss between sessions. What if we could have multiple specialized AI agents working together, each with their own expertise, coordinating like a real development team?

That's exactly what multi-agent orchestration frameworks do. After spending some time with BMAD, Ruflo (formerly Claude Flow) and Gas Town, I want to share what each does best, and how you can chain them together for maximum fun and effect.

The Problem with Single-Agent Development#

Think about your last significant coding session with an AI assistant. You probably experienced:

• Context loss mid-conversation - The AI "forgets" earlier decisions
• Inconsistent architectural choices - Different approaches emerge in different sessions
• Hard to pick up where you left off - "Where was I?" syndrome
• Sequential bottleneck - One task at a time, no parallelization

Anthropic's own research found that multi-agent systems with Claude Opus 4 as lead and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on their internal research evaluations. The evidence is clear: multiple specialized agents beat one generalist.

Steve Yegge (creator of Gas Town) describes the different uses of agents as a journey (see below). Based on my experience, most developers are working with a generalist somewhere below stage 5.

The AI Coding Adoption Ladder#

Steve Yegge describes the journey developers take with AI coding tools:

Most developers reading this are probably at stages 3-5. The frameworks in this post, BMAD, Ruflo and Gas Town, are tools for stages 6-8. They exist because hand-managing 10+ agents doesn't scale, and because the productivity gains from multi-agent workflows are too significant to ignore.

1. BMAD: Structure Beats Chaos#

BMAD (Breakthrough Method for Agile AI-Driven Development) takes the philosophy that chaos should be fought with documentation. In BMAD, source code is no longer the sole source of truth, documentation (PRDs, architecture designs, user stories) is.

How It Works#

BMAD is now on its v6 line, with v7 in preview, and is organised around skills rather than slash-command workflows. A small set of persona agents (Analyst, Product Manager, Architect, UX Designer and Developer) carry the roles; earlier releases had separate Scrum Master and QA personas, which have since been folded into the Developer. Work flows through structured phases:

Each phase runs in a fresh chat to avoid context limitations. The key insight: handoffs between personas create versioned artifacts that persist in git.

The Build Cycle#

BMAD installs with npx bmad-method install and needs Node 20.12 or newer, plus Python 3.10 and uv. Community modules install with --custom-source <git-url-or-path>.

Each step is a skill. Planning runs through bmad-product-brief, bmad-prd, bmad-architecture and bmad-create-epics-and-stories, and bmad-help tells you what to run next. For implementation, v6 recommends:

# 1. Plan the sprint from your epics
bmad-sprint-planning

# 2. Implement the next story (new chat)
bmad-build

# 3. Code review (new chat)
bmad-code-review

Test generation now lives in the separate Test Architect module (bmad-tea, with workflows such as bmad-tea-automate). If you are on the old flow, create-story and dev-story survive as forwarding shims until v7; since v6.12 a fresh install only includes them if you pass --shims.

Best For#

• Greenfield projects that need proper planning
• Teams requiring audit trails - everything is versioned docs
• Complex requirements that need explicit documentation before coding
• Handoffs between developers - anyone can pick up a story file

The trade-off? Planning takes lots time and tokens. A typical planning phase runs about 3 hours before any code is written. But that upfront investment pays off with predictable execution.

2. Ruflo (formerly Claude Flow): Memory Enables Learning#

Ruflo, the project by ruvnet formerly called Claude Flow, takes a different approach: rather than fighting context limits with documentation, it builds AI-native memory systems. The result is parallel agent swarms that coordinate through shared knowledge.

Architecture#

Ruflo offers a catalogue of more than 100 specialized agents and deploys them in coordinated swarms using the orchestrator-worker pattern:

                    ┌─────────────────┐
                    │  Orchestrator   │
                    │  (Queen Agent)  │
                    └────────┬────────┘
                             │
           ┌─────────────────┼─────────────────┐
           │                 │                 │
           ▼                 ▼                 ▼
    ┌──────────┐      ┌──────────┐      ┌──────────┐
    │ Worker 1 │      │ Worker 2 │      │ Worker 3 │
    │ Backend  │      │ Frontend │      │ Testing  │
    └──────────┘      └──────────┘      └──────────┘

The Queen analyzes requests, breaks them into subtasks, assigns workers, and synthesizes results. Workers have domain expertise, execute tasks, and report back—all in parallel.

Memory Systems#

What makes Ruflo special is its memory layer, now built on AgentDB v3, with a bridge that imports Claude Code's own memory:

Combined, agents get smarter over time, across sessions. Successful patterns are stored and reused, routing similar tasks to the best-performing agents.

Setup#

# Install and initialize (or `init wizard` for the interactive setup)
npx ruflo@latest init

# Add the MCP server to Claude Code (it is still registered as claude-flow)
claude mcp add claude-flow -- npx ruflo@latest mcp start

# Verify installation
claude mcp list

Then just tell Claude Code to use Ruflo:

Build a web-based retrospective board with Ruflo and parallel agents:
- Three columns: happy, unsure, sad
- Real-time updates using Socket.io
- Tech stack: Express.js, Socket.io, better-sqlite3

Ruflo automatically breaks down the objective, spawns specialized coder agents, and coordinates through shared memory.

Best For#

• Rapid prototyping - parallel execution is fast
• Complex parallel tasks - multiple agents working simultaneously
• Projects needing persistent memory - decisions carry across sessions
• Performance-critical work - V3 delivers ~250% improvement in effective subscription capacity

3. Gas Town: Git Survives Everything#

Gas Town, Steve Yegge's January 2026 release, takes a radically different philosophy: instead of fighting chaos with structure (BMAD) or memory (Ruflo), it embraces chaos with git as the persistence layer.

Gas Town reached v1.0.0 on 3 April 2026, released alongside Beads v1.0.0, the issue tracker it runs on. Beads now stores its data in embedded Dolt, a versioned SQL database, and both projects have moved to the gastownhall organisation on GitHub. The 7 roles and the Mayor commands below are unchanged in v1.

Philosophy#

"Physics over Politeness" - Agents must prioritize execution over courtesy.

GUPP: Gastown Universal Propulsion Principle

"If there is work on your hook, YOU MUST RUN IT."

The key insight: Git is already a persistence layer. Why invent another one?

The 7 Worker Roles#

The magic is in Polecats, ephemeral worker agents that spawn, complete a task, create an MR, and disappear. Their context dies, but their work survives in git.

Setup#

# Install (requires Go)
go install github.com/steveyegge/gastown/cmd/gt@latest

# Initialize town (creates workspace)
gt install ~/gt --git
cd ~/gt

# Add a project as a "rig"
gt rig add retro_board file:///path/to/retro_board

Working with the Mayor#

The Mayor is your main interface:

gt mayor attach

Then give high-level instructions. The Mayor breaks down your request into tasks, creates a convoy with issues, spawns Polecats to do the work, and reports progress back.

Crash Recovery#

This is where Gas Town shines. Close your terminal mid-work, then:

cd ~/gt
gt prime

Everything is still there because it's in git. Compare that to vibe coding where "Where was I?" is the eternal question.

Best For#

• Long-running projects with many features
• Teams that need crash recovery - sessions are cattle, agents are persistent
• High throughput requirements - 15+ Polecats working in parallel
• Projects requiring full git history - every decision is a commit

Gas City#

Yegge's next project, Gas City, is the MIT-licensed successor. It reached v1.0 in April 2026, generalises Gas Town's roles into configurable packs, and ships a Gas Town pack and a migration guide for existing users. Gas Town itself is now in maintenance mode, so new setups are worth starting on Gas City.

The Cost Warning#

Gas Town burns money, not gas. Steve Yegge reports a 60-minute session can cost about $100 in Claude tokens—roughly 10x the cost of a normal Claude Code session. The throughput is real, but so is the bill.

Chaining Them Together: The Ultimate Workflow#

Here's where things get interesting. Each framework has strengths for different phases:

┌─────────────────────────────────────────────────────────────┐
│                      Your Project                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   BMAD                     (Planning)                       │
│   ├── bmad-product-brief                                    │
│   ├── bmad-prd                                              │
│   └── bmad-architecture                                     │
│              │                                              │
│              ▼                                              │
│   Gas Town                 (Orchestration)                  │
│   ├── gt rig add <project>                                  │
│   ├── gt convoy create <epic>                               │
│   └── gt sling <issue> <rig>                                │
│              │                                              │
│              ▼                                              │
│   Ruflo                    (Execution - per story)          │
│   └── swarm via the MCP server: "implement story"           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

The Flow#

1. BMAD for Planning: Start with BMAD's structured personas to create your PRD, architecture, and epics. This gives you versioned documentation that any agent (or human) can reference.

2. Gas Town for Orchestration: Add your project as a rig in Gas Town. Create convoys from BMAD's epics. The Mayor coordinates work assignment, and Polecats handle branches and MRs automatically.

3. Ruflo for Execution: For complex stories that benefit from parallel work, spawn a Ruflo swarm within a Gas Town task. The memory systems help agents learn from the codebase as they work.

A Simpler Alternative: SpecKit + Gas Town#

If BMAD feels heavyweight or just not your tool of choice, consider:

┌─────────────────────────────────────────────────────────────┐
│                      Your Project                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   SpecKit                  (Planning)                       │
│   ├── /speckit.specify → spec and requirements              │
│   ├── /speckit.clarify → refine                             │
│   └── /speckit.plan → research and plan                     │
│              │                                              │
│              ▼                                              │
│   Gas Town                 (Orchestration/Execution)        │
│   ├── gt rig add <project>                                  │
│   ├── gt convoy create <epic>                               │
│   └── gt sling <issue> <rig>                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Comparison Table#

When to Use What#

Final Thoughts#

Multi-agent orchestration isn't just about having more agents—it's about having the right agents for the right phases, with the right persistence model.

• Structure beats chaos (BMAD)
• Memory enables learning (Ruflo)
• Git survives everything (Gas Town)

The frameworks are complementary, not competing. Use BMAD when you need upfront planning discipline. Use Ruflo when you need parallel execution with memory. Use Gas Town when you need git-backed durability and crash recovery.

Or chain them together and let AI agents handle AI agent coordination. Welcome to the future of software development.

Resources#

BMAD:

• docs.bmad-method.org
• GitHub - bmad-code-org/BMAD-METHOD

Ruflo (formerly Claude Flow):

• GitHub - ruvnet/ruflo

Gas Town:

• Welcome to Gas Town - Steve Yegge
• Gas Town: from Clown Show to v1.0 - Steve Yegge
• GitHub - gastownhall/gastown
• GitHub - gastownhall/gascity