Open Multi-Agent

open-multi-agent · open-multi-agent/open-multi-agent · ★ 6.3k · last commit 2026-05-26

Give a natural-language goal to a coordinator agent and get a dynamically decomposed, parallelized task DAG executed by specialized worker agents — zero graph wiring required.

Best whenGoal-first (coordinator decomposes at runtime) vs. graph-first (hand-wired nodes); 3 runtime dependencies; production-ready JSON-first CLI.

Skip ifHard-wiring task graphs manually when the goal is dynamic, Single-provider lock-in for multi-agent systems

vs seeds

claude-flowin being an npm library with runtime multi-agent orchestration and a dedicated CLI binary, but with opposite design prio…

Primitive shape 6 total

MCP tools 6

Summary

Open Multi-Agent — Summary

Open Multi-Agent (6,251 stars) is a TypeScript-native npm library (@open-multi-agent/core) that provides goal-driven multi-agent orchestration: give it a goal, a coordinator agent decomposes it into a task DAG, parallelizes independent tasks, and synthesizes the result. The library ships a dedicated oma CLI binary for shell/CI use, supports 10 built-in LLM providers plus any OpenAI-compatible endpoint, and ships a post-run HTML dashboard that renders the executed task DAG with timing and token counts. Unlike prompt/markdown-based frameworks, Open Multi-Agent is a TypeScript code library — agents are configured via AgentConfig objects and orchestration is expressed as function calls (runTeam(), runTasks(), runAgent()). There are no skills, commands, or hooks — the entire framework value is in the library API and the goal-to-DAG coordinator. It integrates with MCP servers via connectMCPTools() and supports pluggable memory backends. Compared to seeds, it is closest to claude-flow (both are npm packages with runtime orchestration) but is far simpler (3 runtime deps vs. claude-flow's 305-tool MCP server) and is not tied to any single AI coding assistant — it targets TypeScript backend code, not IDE plugins.

Overview

Open Multi-Agent — Overview

Origin

Launched 2026-04-01 under MIT license. Migrated from the deprecated @jackchen_me/open-multi-agent package to the current @open-multi-agent/core org. TypeScript-first library targeting Node.js backends.

Philosophy

"Your engineers describe the goal, not the graph."

"From a goal to a task DAG, automatically. TypeScript-native multi-agent orchestration. Three runtime dependencies." "Give it a goal; a coordinator agent decomposes it into a task DAG, parallelizes independents, and synthesizes the result."

The framework is explicitly goal-first vs. graph-first: the user provides a natural-language goal, and the coordinator dynamically decomposes it at runtime rather than requiring hand-wired nodes and edges (as LangGraph does).

Positioning vs. Competitors (from README)

Framework	Positioning
LangGraph JS	Graph-first (declarative); OMA is goal-first (dynamic)
Mastra	Supervisor + hand-wired workflows; OMA coordinator auto-wires
CrewAI	Python-only; OMA targets TypeScript backends
Vercel AI SDK	Single-agent/app layer; OMA is multi-agent orchestration

Version

1.4.2 (at analysis date 2026-05-26)

Architecture

Open Multi-Agent — Architecture

Distribution

Type: npm package (@open-multi-agent/core)
CLI binary: oma (dist/cli/oma.js)
Version: 1.4.2
Runtime deps: 3

Installation

npm install @open-multi-agent/core

Directory Tree (source)

open-multi-agent/open-multi-agent/
├── src/
│   ├── agent/          # Agent execution, tool dispatch
│   ├── cli/            # oma CLI binary
│   ├── dashboard/      # HTML dashboard renderer
│   ├── llm/            # Provider adapters (10 built-in)
│   ├── memory/         # Memory store interface + in-process KV
│   ├── orchestrator/   # Coordinator + task DAG
│   ├── task/           # Task scheduling, retry, dependency
│   ├── team/           # Team config, agent pool
│   ├── tool/           # 6 built-in tools
│   └── types.ts        # Public type definitions
├── examples/
│   ├── basics/
│   ├── cookbook/       # Real-world workflows
│   ├── patterns/
│   ├── providers/
│   └── integrations/
├── docs/               # CLI, observability, providers, shared-memory docs
└── package.json        # @open-multi-agent/core v1.4.2

Required Runtime

Node.js >= 18
At least one provider API key (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, etc.)

Supported Providers (10 built-in)

Anthropic, OpenAI, Azure OpenAI, AWS Bedrock, Google Gemini, Grok, DeepSeek, MiniMax, Qiniu, GitHub Copilot

Plus any OpenAI-compatible endpoint: Ollama, vLLM, LM Studio, OpenRouter, Groq

Built-in Tools (6)

bash, file_read, file_write, file_edit, grep, glob

Plus: delegate_to_agent (opt-in subagent delegation), custom tools via defineTool() + Zod, stdio MCP servers via connectMCPTools()

Components

Open Multi-Agent — Components

Core API (TypeScript)

Function/Class	Purpose
`new OpenMultiAgent({...})`	Create orchestrator with defaultModel, onProgress, onTrace
`orchestrator.createTeam(name, config)`	Define a team with agents and sharedMemory flag
`orchestrator.runTeam(team, goal, opts?)`	Goal → coordinator decomposition → parallel DAG execution → synthesis
`orchestrator.runTasks(team, tasks)`	Execute user-defined task graph (no coordinator)
`orchestrator.runAgent(agent, prompt)`	Single agent, single prompt
`AgentPool.runParallel(agents, prompts)`	MapReduce fan-out without dependencies
`renderTeamRunDashboard(result)`	Generate static HTML dashboard of executed DAG
`connectMCPTools(config)`	Load tools from stdio MCP servers
`defineTool(name, schema, handler)`	Define custom tool with Zod validation

CLI Binary: `oma`

Subcommand	Purpose
`oma run --goal <text> --team <file.json>`	Run team against goal
`oma run --dashboard`	Write HTML dashboard to `oma-dashboards/`
`oma task --file <tasks.json>`	Run fixed task list (no coordinator)
`oma provider` / `oma provider list`	List providers, API key env vars
`oma provider template <provider>`	Print example config JSON
`oma help`	Usage text

Coordinator Agent

The coordinator is an LLM agent that:

Receives the team roster (agent names + system prompts) and the goal
Decomposes the goal into a typed task DAG with assigned_to, depends_on, description
Returns structured JSON (Zod-validated, auto-retry on parse failure)
The orchestrator schedules unblocked tasks in parallel

Events (onProgress)

task_start, task_complete, task_retry, task_skipped, agent_start, agent_complete, budget_exceeded, error

Trace Spans (onTrace)

Structured spans with parent IDs, durations, token counts, and tool I/O. Compatible with OpenTelemetry, Datadog, Honeycomb, Langfuse.

Prompts

Open Multi-Agent — Prompts

Verbatim Excerpt 1: Team Collaboration Example (README)

const agents: AgentConfig[] = [
  { 
    name: 'architect', 
    model: 'claude-sonnet-4-6', 
    systemPrompt: 'Design clean API contracts.', 
    tools: ['file_write'] 
  },
  { 
    name: 'developer', 
    model: 'claude-sonnet-4-6', 
    systemPrompt: 'Implement runnable TypeScript.', 
    tools: ['bash', 'file_read', 'file_write', 'file_edit'] 
  },
  { 
    name: 'reviewer', 
    model: 'claude-sonnet-4-6', 
    systemPrompt: 'Review correctness and security.', 
    tools: ['file_read', 'grep'] 
  },
]

const result = await orchestrator.runTeam(team, 'Create a REST API for a todo list in /tmp/todo-api/')

Prompting technique: Tool-scoped agent design — each agent's tools array is a capability fence. The reviewer has file_read + grep only (read-only), preventing it from modifying files. The developer has mutation tools. This is an architectural separation enforced at the tool configuration layer, not at the prompt layer.

Verbatim Excerpt 2: Progress Events (docs)

const orchestrator = new OpenMultiAgent({
  onProgress: (event) => {
    console.log(event.type, event.task ?? event.agent ?? '')
  },
})
// Streams: agent_start coordinator → task_start design-api → task_complete design-api → 
//          task_start implement-handlers → task_start scaffold-tests → 
//          task_complete scaffold-tests → task_complete implement-handlers → 
//          task_start review-code → task_complete review-code → agent_complete coordinator

Design pattern: Event-driven observability layer is separate from execution logic. The coordinator's task DAG is visible as a stream of lifecycle events — downstream consumers (dashboards, logs, traces) attach to onProgress without coupling to execution.

Verbatim Excerpt 3: Structured Output Pattern

// From examples/patterns/structured-output.ts
// Any agent can return Zod-validated JSON
// The library auto-retries coordinator decomposition on parse failure
const plan = await orchestrator.runTeam(team, goal, { planOnly: true })
// plan.tasks is typed as the coordinator's structured output

Prompting technique: Zod schema validation on coordinator output with auto-retry. The coordinator prompt instructs it to return a specific JSON shape; if the shape is invalid, the library retries transparently. This is a library-enforced structural guarantee rather than a prompt engineering technique.

Uniqueness

Open Multi-Agent — Uniqueness

Differs from Seeds

Closest seed: claude-flow — both are npm packages with runtime multi-agent orchestration, a dedicated CLI, and TypeScript code-based agent definitions. Key deltas: (1) Open Multi-Agent has only 3 runtime dependencies vs. claude-flow's heavy dependency footprint and 305-tool MCP server; (2) OMA targets backend TypeScript code as the integration surface, not an AI coding assistant plugin — there are no skills, commands, or hooks; (3) OMA's coordinator decomposes goals dynamically at runtime from a natural-language goal string, while claude-flow requires workflow graph definition; (4) OMA supports 10 built-in providers and any OpenAI-compatible endpoint, enabling genuine cross-provider agent teams (e.g., Claude architect + GPT-4 coder + Gemini reviewer); (5) OMA has no memory persistence across runs by default — state is ephemeral unless the caller implements a MemoryStore backend.

Positioning

Open Multi-Agent is the only pure TypeScript library in this batch — not an AI coding assistant plugin, not a methodology document. It targets engineers who want to embed multi-agent orchestration into backend applications, CI pipelines, or APIs. The "3 runtime dependencies" claim and the CLI's JSON-first design are explicit signals for production/CI use.

Observable Failure Modes

Coordinator reliability — Dynamic DAG decomposition can produce inconsistent task graphs for ambiguous goals. The Zod-validated auto-retry helps but doesn't eliminate hallucinated task assignments.
In-process isolation — Agents share a process and can interfere with each other via shared tools (e.g., two agents writing the same file). No git worktree or container isolation.
Dashboard CDN dependency — Dashboard HTML requires CDN-served assets (Tailwind, Google Fonts). Offline or air-gapped environments can't view it.
No human-in-the-loop — The library has no built-in approval gates. Fully autonomous execution is the default; callers must implement gates via onProgress callbacks.
Short ecosystem tenure — Launched 2026-04-01; the "known users" list has 1 confirmed production user. Risk of API churn before stabilization.

Workflow

Open Multi-Agent — Workflow

Three Execution Modes

Mode 1: Auto-Orchestrated Team (`runTeam`)

User provides goal → Coordinator decomposes → DAG created → 
  Independent tasks run in parallel → Dependent tasks unblock sequentially → 
  Coordinator synthesizes final result

Mode 2: Explicit Pipeline (`runTasks`)

User defines task graph (assignments + deps) → Tasks execute per graph → 
  Results collected

Mode 3: Single Agent (`runAgent`)

One agent, one prompt → Result

Mode 4: Fan-out (`AgentPool.runParallel`)

Same operation applied to N items in parallel → Results collected

Preview / Plan-Only

const plan = await orchestrator.runTeam(team, goal, { planOnly: true })
// Returns coordinator's task DAG without executing agents

Coordinator Reveal

const result = await orchestrator.runTeam(team, goal, { revealCoordinator: true })
// Injects team context (goal, roster, this worker's role) into every worker prompt

Approval Gates

None — Open Multi-Agent is a fully autonomous library. There are no human-in-the-loop gates by default. Callers can implement approval gates in their application code by inspecting onProgress events.

Error Recovery

Task retry with backoff — configurable retry count per task
Loop detection — prevents infinite agent loops
Structured output auto-retry — if Zod validation fails on coordinator output, it retries the coordinator call
Budget exceeded — budget_exceeded progress event when token budget is hit

Phase/Artifact Map

Phase	Artifact
Coordinator decomposition	In-memory task DAG (accessible as `TeamRunResult.tasks`)
Agent execution	Per-task results in `TeamRunResult.tasks[].result`
Post-run	Static HTML dashboard (optional, written by CLI with `--dashboard`)

Memory Context

Open Multi-Agent — Memory & Context

Memory Type

Pluggable shared memory — default in-process KV store; swap in Redis/Postgres/custom backend by implementing MemoryStore interface.

Shared Memory

When sharedMemory: true on a team, all agents in the team share a common KV store instance. Agents can read/write shared state during the same run. The default in-process KV is ephemeral (lost at process exit).

Persistence Options

Backend	Notes
In-process KV (default)	Session only; zero setup
Redis	Persistent across runs; implement MemoryStore
Postgres	Persistent; implement MemoryStore
Custom	Any backend implementing MemoryStore interface

Cross-Session Handoff

Not built-in — the library doesn't persist agent state between separate runTeam() calls. Callers who need cross-session persistence implement their own MemoryStore backend.

Context Management

The library provides context strategies (production controls) for managing long-running agents. No automatic compaction — callers configure context window limits.

Observability State

TeamRunResult.tasks — full executed DAG with per-task states, accessible post-run
TeamRunResult.totalTokenUsage — cost attribution
onTrace spans — per-LLM-call structured spans (durations, token counts, tool I/O)
HTML dashboard — renderTeamRunDashboard(result) → static HTML with task DAG visualization

Orchestration

Open Multi-Agent — Orchestration

Orchestration Pattern

Hierarchical (coordinator + workers)
The coordinator is a special LLM agent that receives the team roster + goal and returns a typed task DAG. Workers execute tasks. The coordinator synthesizes the final result after all tasks complete.

Parallel fan-out within each level — independent tasks run concurrently via Promise.all() semantics.

Task DAG

Coordinator produces a JSON task DAG with assigned_to, depends_on, description per node
Zod-validated with auto-retry on parse failure
planOnly: true option returns the DAG without executing workers

Multi-Model Support

First-class — each agent in a team can use a different model:

{ name: 'planner', model: 'claude-opus-4-5', systemPrompt: '...' }
{ name: 'coder', model: 'claude-sonnet-4-6', systemPrompt: '...' }
{ name: 'reviewer', model: 'gpt-4o', systemPrompt: '...' }

10 built-in providers, any OpenAI-compatible endpoint. This is pure TypeScript config — no YAML or markdown required.

Isolation

Process-level — agents run as async functions within the same Node.js process. No git worktrees, no containers, no subprocesses. Shared memory is opt-in.

Subagent Delegation

delegate_to_agent is an opt-in tool that lets worker agents spawn sub-agents synchronously. Disabled by default to prevent unbounded recursion. See agent-handoff example.

MCP Integration

connectMCPTools(config) loads tools from stdio MCP servers and makes them available to any agent. Each MCP tool call goes through the same tool-dispatch layer as built-in tools.

Execution Mode

One-shot — runTeam() is a single async call that returns when all tasks complete. No continuous loop, no daemon mode, no background process.

Error Recovery

Task-level retry with exponential backoff
Loop detection (configurable max depth)
Tool output truncation/compression for long outputs
budget_exceeded event for token budget enforcement

Ui Cli Surface

Open Multi-Agent — UI, CLI & Surface

CLI Binary: `oma`

Binary name: oma
Package: @open-multi-agent/core (includes binary)
Access: npx oma or node dist/cli/oma.js from a clone

Design principles: JSON-first output, stable exit codes, non-interactive flags — designed for CI/shell scripting use.

Subcommands

Subcommand	Flags	Output
`oma run`	`--goal`, `--team`, `--orchestrator`, `--coordinator`, `--dashboard`, `--pretty`, `--include-messages`	JSON result to stdout; dashboard HTML to `oma-dashboards/runTeam-<timestamp>.html`
`oma task`	`--file`, `--team`, `--pretty`, `--include-messages`	JSON result
`oma provider` / `oma provider list`	`--pretty`	JSON: provider IDs, env var names, baseURL support
`oma provider template <provider>`	`--pretty`	JSON: example orchestrator + agent config with env entries
`oma help`	—	Usage text to stdout, exit 0

Post-Run HTML Dashboard

renderTeamRunDashboard(result) returns a static HTML page (not a running server) showing:

Executed task DAG with per-node status
Timing per task
Token usage breakdown
Agent output log

CLI writes to oma-dashboards/runTeam-<timestamp>.html with --dashboard flag.
Dashboard loads Tailwind CSS + Google Fonts from CDN at view time (requires online access).

No Local Web Dashboard

There is no running web server or port. The dashboard is a static file generated post-run.

IDE Integration

None — this is a backend library, not an IDE plugin. No Claude Code skills, no Cursor integration. Targets TypeScript backend code and CI pipelines.

Vercel AI SDK Integration

A Next.js integration example ships at examples/integrations/with-vercel-ai-sdk/ — combines runTeam() with Vercel AI SDK's useChat for streaming agent output to a frontend.

Observability Integration

onTrace spans are compatible with OpenTelemetry, Datadog, Honeycomb, Langfuse. Callers pipe spans to their own tracing infrastructure.

Related frameworks

same archetype · same primary tool · same memory type

MemPalace ★ 53k

A10 Memory engine

Verbatim local-first AI memory with 96.6% R@5 retrieval on LongMemEval using zero API calls — structured into a palace hierarchy…

Beads (Yegge) ★ 24k

A10 Memory engine

Dolt-powered distributed graph issue tracker where AI agents track tasks with hierarchical IDs and dependency edges, claim work…

deepagents (LangChain) ★ 23k

A10 Memory engine

Opinionated Python agent harness on top of LangGraph with sub-agents, filesystem, memory, and context compaction bundled in

agentmemory ★ 18k

A10 Memory engine

Persistent, searchable memory for AI coding agents that captures every tool interaction, compresses it via LLM, and injects…

Basic Memory ★ 3.1k

A10 Memory engine

Gives AI agents a persistent, human-readable knowledge graph of project decisions, observations, and relations stored as plain…

Claude-Supermemory ★ 2.6k

A10 Memory engine

Gives Claude Code team-level persistent memory via a cloud API, sharing project knowledge across developers and sessions without…

Distribution

Type: npm-package
License: MIT
Install: npm-install
Version: 1.4.2

Surfaces

CLI binary: oma
CLI subcmds: 4
Local UI: other
Tech stack: Static HTML + Tailwind CSS CDN (no running server)

Components

Commands: 0
Skills: 0
Subagents: 0
Hooks: 0
MCP servers: 0
MCP tools: 6
Scripts: 0
Templates: 0

Workflow

Phases: 3
Approval gates: 0
Spec format: none
Spec storage: none
Delta or full: none

Orchestration

Multi-agent: Yes
Pattern: hierarchical
Isolation: process
Consensus: none
Prompt chaining: Yes

Multi-model

Multi-model: Yes
BYOK: Yes
Modal: text

Execution

Mode: one-shot
Crash recovery: Yes
Compaction: No
Session handoff: No
Streaming: Yes

Memory

Type: hybrid
Persistence: session
Search: none

Quality

TDD: No
TDD mechanism: none
Self-review: none

Git / Observability

Auto commit: No
Auto PR: No
Auto merge: No
Worktree/feat: No
Audit log: Yes
Audit format: jsonl
Replay: No

Tools

Primary: node-js-backends
Targets: 3
Portability: high

Signals

Stars: 6.3k
Last commit: 2026-05-26
Maintainer: active
Quality score: 4/10

Summary

Open Multi-Agent — Summary

Overview

Open Multi-Agent — Overview

Origin

Philosophy

Positioning vs. Competitors (from README)

Version

Architecture

Open Multi-Agent — Architecture

Distribution

Installation

Directory Tree (source)

Required Runtime

Supported Providers (10 built-in)

Built-in Tools (6)

Components

Open Multi-Agent — Components

Core API (TypeScript)

CLI Binary: oma

Coordinator Agent

Events (onProgress)

Trace Spans (onTrace)

Prompts

Open Multi-Agent — Prompts

Verbatim Excerpt 1: Team Collaboration Example (README)

Verbatim Excerpt 2: Progress Events (docs)

Verbatim Excerpt 3: Structured Output Pattern

Uniqueness

Open Multi-Agent — Uniqueness

Differs from Seeds

Positioning

Observable Failure Modes

Workflow

Open Multi-Agent — Workflow

Three Execution Modes

Mode 1: Auto-Orchestrated Team (runTeam)

Mode 2: Explicit Pipeline (runTasks)

Mode 3: Single Agent (runAgent)

Mode 4: Fan-out (AgentPool.runParallel)

Preview / Plan-Only

Coordinator Reveal

Approval Gates

Error Recovery

Phase/Artifact Map

Memory Context

Open Multi-Agent — Memory & Context

Memory Type

Shared Memory

Persistence Options

Cross-Session Handoff

Context Management

Observability State

Orchestration

Open Multi-Agent — Orchestration

Orchestration Pattern

Task DAG

Multi-Model Support

Isolation

Subagent Delegation

MCP Integration

Execution Mode

Error Recovery

Ui Cli Surface

Open Multi-Agent — UI, CLI & Surface

CLI Binary: oma

Subcommands

Post-Run HTML Dashboard

No Local Web Dashboard

IDE Integration

Vercel AI SDK Integration

Observability Integration

Related frameworks

CLI Binary: `oma`

Mode 1: Auto-Orchestrated Team (`runTeam`)

Mode 2: Explicit Pipeline (`runTasks`)

Mode 3: Single Agent (`runAgent`)

Mode 4: Fan-out (`AgentPool.runParallel`)

CLI Binary: `oma`