DEV Community

Cover image for Release the Horde: Multi-Agent Orchestration in Pure Bash
Spencer Marx
Spencer Marx

Posted on

Release the Horde: Multi-Agent Orchestration in Pure Bash

#ai #opensource #bash #devtools

Anyone running 3+ AI coding agents in parallel has hit the same wall: the agents are fine. The coordination is the problem.

Merge conflicts. Duplicated work. No review gate. Token burn on orchestration overhead. You end up spending more time managing agents than the agents save you.

So I built Orc.

Orc in Action

What it does

You describe the work. Orc decomposes it into goals and beads (focused work items), spawns engineers in isolated git worktrees, reviews everything before merge, and delivers clean goal branches.

Across multiple projects, from a single session.

"Fix auth, add rate limiting, update docs"
                  │
                  ▼
          ┌──── orc ────┐
          │      │      │
          ▼      ▼      ▼
    fix/auth  feat/rate  task/docs      ← goal branches
      │   │      │         │
     [E] [E]    [E]       [E]           ← engineers in isolated worktrees
      │   │      │         │
     ✓/✗ ✓/✗    ✓/✗       ✓/✗           ← built-in review loop
      │   │      │         │
    fix/auth  feat/rate  task/docs      ← approved beads merge back
          │      │         │
          You review & merge            ← you decide when to ship
Enter fullscreen mode Exit fullscreen mode

The whole stack

Bash. Tmux. Git worktrees.

No daemon. No server. No framework. No build step. State is three files. You're running in five minutes.

# Register a project
orc add myapp /path/to/myapp

# Launch
orc myapp

# Or go full send
orc myapp --yolo
Enter fullscreen mode Exit fullscreen mode

Opinionated but stays out of your way

This is where it gets interesting. Orc has strong opinions about structure (four-tier hierarchy, mandatory review before merge, hard role boundaries), but the things you actually care about customizing are wide open.

The review loop is mandatory. How you review is yours. Swap in your own review command, point it at a multi-agent review tool, or just describe your review standards in plain English:

[review]
command = "/ocr:review"  # your tool, or leave blank for built-in

instructions = """
Focus on security: check for SQL injection, XSS, and auth bypass.
All new endpoints must have rate limiting.
Verify error responses follow our RFC 7807 format.
"""
Enter fullscreen mode Exit fullscreen mode

Branch naming? Natural language:

[branching]
strategy = "use Jira ticket prefix like PROJ-123, then kebab-case summary"
Enter fullscreen mode Exit fullscreen mode

Delivery strategy? Same pattern:

[delivery]
mode = "pr"
target_strategy = "target develop for features, main for hotfixes"
Enter fullscreen mode Exit fullscreen mode

Most of the configuration is "tell it what you want in plain English." Orc interprets it.

Token efficiency by design

Coordination happens through the filesystem, not agent-to-agent conversation. An engineer writes review to a .worker-status file. The orchestrator reads the file. Zero tokens burned on supervisors polling workers or nudging stalled agents.

The tools you already have (tmux for sessions, git worktrees for isolation, the filesystem for signals) solve most of the orchestration problem. The interesting part is the decomposition, dispatch, and review protocol on top.

YOLO mode

Sometimes you don't want to babysit.

orc myapp --yolo
Enter fullscreen mode Exit fullscreen mode

All approval gates are skipped. Planning flows straight into dispatch. Agents launch with auto-accept flags.

But it still escalates on merge conflicts, blocked engineers, and out-of-scope discoveries. We're not animals.

Works with your agent

Claude Code, OpenCode, Codex, or bring your own. Personas are markdown files you can override per-project. Adding a new agent is a single adapter.

Credit where it's due

Huge respect to Gas Town for proving this category matters and pushing everyone's thinking forward. Orc asked "what's the minimum viable version of this?"

Try it 

git clone https://github.com/spencermarx/orc.git
cd orc && pnpm install
pnpm orc:install
orc add myapp /path/to/your/project
orc myapp
Enter fullscreen mode Exit fullscreen mode

Now go. Release the horde.

GitHub: spencermarx/orc

Star it if it's useful. PRs are welcome. Issues too.

Top comments (1)

Collapse
 
mavericksantander profile image
Mavericksantander •

Great project — the filesystem-as-coordination-bus approach is elegant and the token efficiency argument is real.

One thing worth thinking about as Orc scales: the engineers in those worktrees have shell access, and --yolo mode removes the review gate entirely. That's fine for trusted contexts, but in any setup where agents are writing and executing code autonomously, you want a pre-execution gate at the tool level — not just a post-execution review.

Canopy is built exactly for that layer: authorize_action() returns ALLOW/DENY/REQUIRE_APPROVAL before any shell command runs, with a tamper-evident audit log of every decision. It would sit between Orc's dispatch and the engineer's actual execution — so even in --yolo mode, catastrophic actions (rm -rf, env hijacking, credential access) get blocked deterministically before they happen.

pip install canopy-runtime — the HTTP gateway mode makes it easy to integrate without touching Orc's bash core.

github.com/Mavericksantander/Canopy