Open Multi-Agent
Turn a goal into a controlled, recoverable multi-agent task DAG at runtime.
Per-dimension scores and reasoning
Evidence shows default-deny tools, per-call gating, approval and suspension mechanisms, and privacy controls, but sensitive data handling details are insufficient, dependency security not fully demonstrated, and publisher identity unverified.
Code and tests show retries, timeouts, loop detection, budget limits, and clear failure messages, but dependency availability not fully verified.
Documentation clearly defines target audience and scenarios, capability boundaries are clear, triggers are precise, and environment fit is good.
Information architecture is clear, installation notes are detailed, examples are abundant, but known limitations and changelog are insufficient, and maintenance responsibility is unclear.
Output usability is high, marginal value is evident, but cost-benefit analysis is insufficient.
Claims have some supporting evidence, but lack independent source verification, and fact-inference separation is unclear.
- Publisher identity is unverified; assess supply chain risks carefully.
- Sensitive data handling details are insufficient; further review needed.
- Dependency security not fully demonstrated; check dependency list.
What does this agent do, and when should you use it?
Open Multi-Agent (OMA) is a multi-agent orchestration framework for TypeScript backends and Node.js applications. A coordinator plans a task DAG from a goal at runtime, while a deterministic scheduler executes work across a team and synthesizes the result. The core package includes the orchestration runtime, tools, shared memory, checkpoints, traces, a CLI, and an offline Run Viewer; @open-multi-agent/otel is an optional integration for centralized OpenTelemetry monitoring. Run records support review, approval, replay, evaluation sets, CI regression gates, and recovery from checkpoints or plan repair at task outcome barriers. It fits TypeScript teams that want workflow topology to emerge from a goal while retaining self-hosted control, budgets, approvals, and observability.
Developers create a runtime with new OpenMultiAgent(), define a team with createTeam(), and specify roles, system prompts, and sharedMemory. runTeam(team, goal) has the coordinator plan and dispatch a task DAG from the goal; runAgent() runs one agent, and runTasks() executes an explicit pipeline. The scheduler executes tasks with retries, timeouts, loop detection, and token and cost budgets; it produces execution receipts and traces that can be queried in TraceStore, replayed as a task DAG and span waterfall in the offline Run Viewer, or exported through @open-multi-agent/otel. Process and ACP backends allow Claude Code, Gemini CLI, and Codex to participate alongside LLM agents with the same task DAG, shared memory, and budgets.
- A TypeScript backend team needs to split a research request such as comparing approaches and recommending one between researcher and analyst roles.
- A business system needs a human to inspect and approve a plan or individual dispatch before freezing it for later replay.
- An engineering team runs long jobs that may be interrupted and needs checkpoint resume or append-only plan repair at task outcome barriers.
- An internal platform team needs to inspect task DAGs, statuses, tokens, tool calls, and span waterfalls in an offline Run Viewer.
- Developers want Claude Code, Gemini CLI, or Codex to collaborate with model-driven agents on one task DAG.
What are this agent's strengths and limitations?
- The coordinator creates the task DAG at runtime from a goal, avoiding a hand-maintained fixed graph.
- Plan and per-dispatch approval, plus frozen-plan replay, provide explicit control boundaries for dynamic orchestration.
- Checkpoint resume, append-only plan repair, retries, timeouts, loop detection, and token/cost budgets address bounded long-running execution.
- TraceStore, the offline Run Viewer, and optional OpenTelemetry export support both local inspection and centralized observability.
- The runtime requires Node.js 20 or newer, so non-Node services need an integration layer.
- The example uses the OpenAI provider; cloud-model runs also require provider credentials, but the supplied material does not give exact setup commands.
- Dynamic task topology is a poor fit for workflows that must be authored and fixed node by node in advance.
- External-agent participation from Claude Code, Gemini CLI, and Codex depends on process or ACP backends, which can add deployment complexity compared with a model API call alone.
How do you install or deploy this agent?
Node.js 20 or newer is required; a maintained Node.js LTS release is recommended for production. Install into an existing backend:
npm install @open-multi-agent/coreOr scaffold a project and run its deterministic local demo:
npm create oma-app@latest my-omaThe scaffolded demo needs no API key and makes no model request. Cloud-model use requires credentials for the chosen provider, but the supplied material does not specify the credential variables or configuration commands.
How do you use this agent?
After installation:
import { OpenMultiAgent } from '@open-multi-agent/core'const oma = new OpenMultiAgent({ defaultProvider: 'openai', defaultModel: 'gpt-5.4' })
const team = oma.createTeam('research-team', {name: 'research-team',
agents: [{ name: 'researcher', systemPrompt: 'Find the relevant facts.' },
{ name: 'analyst', systemPrompt: 'Compare evidence and identify tradeoffs.' },
],
sharedMemory: true,
})
const result = await oma.runTeam(team, 'Compare three approaches and recommend one.')
console.log(result.agentResults.get('coordinator')?.output)This plans and runs a team from the goal. Use runAgent() for one agent or runTasks() for an explicit pipeline.
How does this agent compare with similar options?
OMA positions itself at the dynamic orchestration layer: a graph-first framework is a better fit when every node must be authored in advance, while an LLM toolkit alone is sufficient when one agent call is enough. The repository names LangGraph, Mastra, CrewAI, and the Vercel AI SDK, but the supplied material does not provide a verifiable feature-by-feature comparison.