Stoneforge — Summary

Stoneforge is an open-source multi-agent orchestration platform for AI coding agents, centered on a three-role architecture: a Director (strategic planner/task assigner), Workers (ephemeral or persistent agents that execute tasks in isolated git worktrees), and Stewards (merge reviewers that check CI status and handle integration). It ships as @stoneforge/smithy npm CLI with a sf binary and a web dashboard at localhost:3457. The platform features dependency-aware task dispatch via a daemon, a Kanban board with merge requests, plans/workflows, a workspace/terminal multiplexer, document management, channels/messaging, and performance metrics. It supports Claude Code, Codex, and OpenCode agents, with automatic merge and a dependency-aware dispatch daemon that prevents duplicated work and blocked starts. Apache 2.0, community project (source: stoneforge.ai, stoneforge-ai GitHub org).

Differs from seeds: Stoneforge introduces a named three-role hierarchy (Director/Worker/Steward) not found in any seed framework. The Steward role — dedicated merge reviewer — is architecturally novel: while superpowers has a verification-before-completion skill and Bernstein has a "janitor," the Stoneforge Steward is a long-running agent persona dedicated exclusively to merge management. The sf CLI + localhost:3457 web dashboard gives it a closer resemblance to Kagan (Python TUI + SQLite) but with a TypeScript/Node.js implementation. Unlike taskmaster-ai (task planning only), Stoneforge executes, reviews, and merges automatically.

Stoneforge — Overview

Origin

GitHub org: stoneforge-ai. npm package: @stoneforge/smithy. Website: stoneforge.ai. Apache 2.0. Version 0.1.0 at time of analysis. Active (last commit ~2026-02). No public GitHub star count found (repo may be private or at stoneforge-ai/smithy).

Philosophy

From the website:

"Orchestrate AI coding agents in parallel with multi-agent workflows. Run teams of AI coding agents with automatic merge, dependency-aware dispatch, and a real-time web dashboard."

The three-role model is Stoneforge's core innovation:

• Director: Strategic agent that creates and assigns tasks to workers
• Workers: Task-executing agents (ephemeral or persistent) in isolated worktrees
• Stewards: Dedicated merge-review agents that check CI and handle integration

From the website's "Problem" section:

"Merge conflicts — Agents edit the same files on the same branch, creating constant conflicts." "Duplicated work — Two agents grab the same task, or one starts work that's blocked by another." "Zero visibility — You can't see what's happening until you check each terminal individually."

Stoneforge solves all three: worktree isolation eliminates merge conflicts, dependency-aware dispatch eliminates duplicate/blocked starts, and the web dashboard eliminates visibility gaps.

Latest Version

v1.16 mentioned on website ("Now with GitHub, Linear, and Notion sync").

Features (from website)

• Terminal only → Web dashboard
• Manual worktrees → Automatic worktrees
• Lead assigns → Auto-dispatch daemon
• Manual merge → Auto merge + test
• Lead-mediated communication → Persistent channels
• CLAUDE.md only → Versioned docs + search
• Ad-hoc task lists → Resumable playbooks
• Single plan → Multi-plan support
• Claude only → Claude, OpenCode, Codex

Stoneforge — Architecture

Distribution

npm install -g @stoneforge/smithy    # Install CLI globally
cd your-project && sf init            # Initialize .stoneforge workspace
sf serve                              # Start server + web dashboard at http://localhost:3457

Server Architecture

Stoneforge runs two server processes:

• quarry-server — the main API server
• smithy-server — derived server (appears to share routes via shared-routes package)

Runtime state stored in .stoneforge/ directory:

• daemon-state.json — dispatch daemon persistence

Monorepo Structure

stoneforge/ (inferred from source references)
├── apps/
│   ├── smithy-server/     # API server
│   │   └── src/
│   │       ├── routes/    # Task, agent, merge, plan routes
│   │       ├── services/  # Business logic
│   │       └── daemon-state.ts  # Daemon state persistence
│   ├── quarry-server/     # (original server)
│   └── quarry-web/        # Web dashboard frontend
├── packages/
│   ├── shared-routes/     # Shared route factories
│   └── ...
└── .stoneforge/           # Runtime state dir
    ├── daemon-state.json  # Daemon running state
    └── ...

Required Runtime

• Node.js 18+ (inferred from TypeScript + npm)
• Git (worktree management)
• AI agent CLIs (claude-code, codex, opencode)

Web Dashboard

http://localhost:3457/activity

Multi-section UI:

• Overview, Activity, Inbox, Editor, Work/Tasks, Merge Requests, Plans, Workflows, Orchestration, Agents, Workspaces, Collaborate/Messages, Documents, Analytics/Metrics, Settings

Key Config

• .stoneforge/ — runtime state
• sf init creates initial workspace config
• Agents section: configure Director, Workers (persistent/ephemeral), Stewards, Pools

Stoneforge — Components

CLI Binary: sf (@stoneforge/smithy)

Agent Roles (3 types)

Dashboard Sections

MCP Integration

Not explicitly documented in the public site, but the sf task create command is used by agent tools — suggesting MCP or some API interface agents call to interact with Stoneforge from within their sessions.

Stoneforge — Uniqueness and Positioning

Differs from Seeds

Stoneforge introduces the most explicit three-role named hierarchy of any framework in this batch or the seeds: Director → Worker → Steward. No seed framework has a dedicated "Steward" role — a persistent agent whose sole job is merge management and CI gating.

Versus taskmaster-ai (closest seed in spirit — both manage task queues): Taskmaster creates and manages tasks but doesn't execute them or merge their output. Stoneforge executes, reviews, and merges automatically via the Steward agents.

Versus claude-flow (both run parallel workers): claude-flow uses LLM consensus protocols (hive-mind) for coordination; Stoneforge uses a deterministic dispatch daemon (like Bernstein) but with named role agents rather than a generic worker pool.

Versus agent-os and claude-conductor (Archetype 4 markdown scaffolds): Stoneforge is a full platform — not a CLAUDE.md template.

The document library (sf document search/create/update) as a persistent, versioned knowledge base accessible to all agents is not present in any seed framework. It's positioned as solving "CLAUDE.md only" → "Versioned docs + search."

Distinctive Features

1. Director/Worker/Steward naming — clearest role taxonomy of any framework analyzed
2. Steward as dedicated merge agent — novel role not seen elsewhere
3. Persistent inter-agent channels — operators and agents communicate via DMs and channel history
4. Document library with versioned docs and search — knowledge management for agent teams
5. GitHub, Linear, Notion sync (v1.16) — external project management integration

Positioning

Stoneforge targets teams that want the parallelism benefits of multi-agent orchestration but need structured roles rather than ad-hoc agent coordination. The Director ensures there's always a strategic planner; Stewards ensure merge hygiene without requiring the operator to constantly monitor CI.

Observable Failure Modes

1. Director as single point of failure: if the Director misdecomposes the goal, all downstream tasks are wrong.
2. Steward race condition: the demo itself mentions fixing "non-atomic worker unassignment" — Steward concurrency may still have edge cases.
3. Source not public: No public GitHub repo found for stoneforge-ai at time of analysis — limits community adoption and auditability.
4. Node.js-only: server restart causes daemon state loss unless .stoneforge/daemon-state.json correctly tracks state (one file governs whether daemon auto-restarts).