A library that gets installed into someone else's backend is judged partly on what its own install pulls down. Three changes tighten that, and two questions turned out to need no change at all. The line this draws is what ships. Every dependency that stays inside the repository is now pinned to the exact version the lockfile already resolved: all 27 devDependencies across the four workspaces, plus the private release bot's own zod. The lockfile change is 28 spec lines with no resolution moved, no entry added or removed, and all 61 platform-specific entries intact. A new root .npmrc sets save-exact=true so the next one arrives pinned rather than as a range nobody notices. What a consumer installs keeps its range: `dependencies` in packages/core, the only published runtime block here, every `peerDependencies`, and otel's core compatibility range. An exact version in those blocks overrides the consumer's own resolution and stops their `npm audit fix` from reaching a patched build until we cut a release, which is a worse trade than the install-time drift it prevents. save-exact will still pin a new dependency added to one of them, so the package job now asserts all three published manifests and fails when one is left exact, next to the assertion that already covers otel's range. min-release-age is deliberately not set. It first shipped in npm 11.10.0, and the CI matrix runs Node 20 and 22, which bundle npm 10.8.2 and 10.9.8. Those two accept the key, echo it back from `npm config get`, and never act on it, so a quarantine window would hold on one leg of the matrix while silently doing nothing on the other two. It also has no effect on `npm ci`, which installs the lockfile verbatim. Every `npm ci` that installs this repository's own tree now passes --ignore-scripts, so a compromised dependency cannot run an install hook on a runner that holds release credentials. Only three dependencies declare a postinstall at all, and the full lint, test, build, scaffold, and example suites pass on a tree installed that way. The `npm install` calls that stand in for a real consumer are deliberately left alone: their job is to reproduce what a user's install actually does, and hardening them would make the smoke tests prove less than they claim. A new scheduled Supply chain audit workflow asks two questions about the dependencies that reach a consumer, an hour before the weekly release bot so a finding lands before the release PR is drafted. --omit=dev is the point of running it separately: auditing the full tree reports eighteen advisories, every one of them in test and fixture tooling that never ships, and a permanently red job is one nobody reads. The two steps fail differently. `npm audit` reports into the run summary, because a new upstream advisory is not this repository misbehaving and may have no fixed version yet. `npm audit signatures` fails, because it compares served bytes against the registry's own signature, so a mismatch is tampering rather than churn; all 27 production packages verify today. Two things needed no change. npm provenance is already live: publish.yml publishes through npm trusted publishing with id-token: write, which attaches SLSA attestations on its own, and every version since core 1.16.0, otel 0.1.2, and create-oma-app 0.8.1 carries one. And .npmrc left .gitignore in #198 because it only restated the default registry; it comes back tracked, with the ignore rule narrowed so a contributor's own nested .npmrc stays out.
Open Multi-Agent
Describe the goal, not the graph.
Multi-agent orchestration that runs in your own environment.
Website · Docs · Examples · npm
English · 中文
open-multi-agent is an AI agent orchestration framework for TypeScript backends that drops into any Node.js app. It runs dynamic workflows: a coordinator turns one goal into a task DAG at runtime, a deterministic scheduler executes it across the team, and the whole run stays data you can inspect, approve, and replay. The dashboard above is the built-in offline Run Viewer replaying a real run.
Get started
Requires Node.js 20 or newer. For production, use a currently maintained Node.js LTS release.
Scaffold a PR review agent, security analysis agent, or teaching DAG:
npm create oma-app@latest my-oma
In an interactive terminal, that one command selects a starter and runtime, installs dependencies, and runs a deterministic local demo. The demo needs no API key and makes no model request: scripted model responses drive the real OMA scheduler, result aggregation, and offline dashboard.
Or add OMA to an existing backend:
npm install @open-multi-agent/core
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)
Full example: DAG readback, token usage, and model overrides
import { OpenMultiAgent } from '@open-multi-agent/core'
const model = process.env.OMA_MODEL ?? 'gpt-5.4'
const oma = new OpenMultiAgent({ defaultProvider: 'openai', defaultModel: model })
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.')
// Nothing above declares a task graph. The coordinator planned one at runtime,
// and the finished run is data you can read back.
for (const task of result.tasks ?? []) {
console.log(`[${task.status}] ${task.title} → ${task.assignee ?? 'unassigned'}`, task.dependsOn)
}
console.log(result.agentResults.get('coordinator')?.output)
console.log(result.totalTokenUsage)
Set OPENAI_API_KEY to run this example. Providers covers other hosted models, local servers, OpenAI-compatible endpoints, and AI SDK providers.
runTeam() plans from a goal, runAgent() runs a single agent, and runTasks() executes an explicit pipeline. The Core package guide walks through all three modes, provider and credential setup, and the production checklist. The example index lists 50+ runnable examples across basics, cookbook workflows, patterns, providers, and integrations.
Why OMA
Every seam, an interface. Every run, a record.
OMA combines dynamic orchestration with the control, evidence, and recovery paths needed to move multi-agent systems from prototype to production.
- Dynamic orchestration. Describe the goal and let the coordinator build the task DAG, assign work, and synthesize the result at runtime. There is no hand-wired graph to maintain.
- Controlled execution. Preview, approve, or durably suspend plans, task dispatches, and tool calls; freeze approved plans for replay. Declare required roles and order when topology cannot drift, and verify outputs with multi-agent consensus.
- Reliability. Resume interrupted runs from checkpoints, or opt into append-only plan repair at task outcome barriers. Retries, timeouts, loop detection, and token and cost budgets keep execution bounded.
- Observability and evaluation. Follow each run through stable identity, execution receipts, and traces. Replay the task DAG and span waterfall in the offline Run Viewer, or export through the optional OpenTelemetry adapter. The same records feed versioned EvalSets, offline reports, CI gates, and production sampling.
- Safety and privacy. Tools are default-deny, individual calls are gated, and explicit privacy controls apply to telemetry and persisted state.
- Open runtime. Process and ACP backends put Claude Code, Gemini CLI, and Codex on the same task DAG, shared memory, and budgets as LLM agents. Mix cloud and local models, natively integrated Chinese providers, OpenAI-compatible endpoints, and AI SDK providers, with a fallback parser for local models that emit tool calls as text. Run on your own infrastructure and credentials, locally, offline, or air-gapped.
Built with OMA
open-multi-agent launched 2026-04-01 under MIT. Known users and integrations to date:
- temodar-agent by Ali Sünbül. WordPress security analysis platform running OMA's built-in tools (
bash,file_*,grep) inside a Docker runtime. Confirmed production use. - Mark Galyan runs OMA fully offline on local quantized models, using the coordinator and context compaction to keep autonomous agent loops alive under tight VRAM limits. Contributor since the framework's first month.
- PR-Copilot by kidoom. AI pull-request review assistant running an OMA review team, with
defineToolrepo-context tools and a customContextStrategyfor token-aware diff compression. - StuFlow by znc15. Terminal AI coding assistant on OMA's orchestration core, driving
runAgent/runTasks/runTeamwith a custom coordinator, paired with DeepSeek. - Reports to Charts Studio. Turns documents and research tables into slide-ready charts, using a five-role extraction council with structured outputs and deterministic validation.
Integrations
- Engram: "Git for AI memory." Syncs knowledge across agents instantly and flags conflicts. (repo, ~80 stars)
- @agentsonar/oma: Sidecar detecting cross-run delegation cycles, repetition, and rate bursts.
- CodingScaffold: Agentic-coding scaffold that lists OMA as an optional orchestration backend, with a
runTeamworkflow template. - Bilig WorkPaper: Formula-workbook MCP server with a reciprocal OMA integration for editing inputs, recalculating formulas, verifying readback, and persisting WorkPaper JSON.
- baize-oma: HTTP adapter exposing OMA
runAgent()andrunTeam()as Baize slot capabilities.
Using open-multi-agent in production or a side project? Open a discussion and we will list it here. Built an integration? The integration guide covers how to get listed. For a deep integration, see the Featured partner program.
Sponsors
Paid sponsors supporting open-multi-agent. Sponsorship does not affect technical decisions or model recommendations.
Providers
- Atlas Cloud: Full-modal AI inference platform giving one API for video, image, and LLM across 300+ curated models. $5 credit vouchers for OMA users, first come first served. See the Atlas Cloud setup guide.
When OMA fits
OMA is designed for TypeScript teams that want the task graph to emerge from the goal at runtime.
Choose a graph-first framework when the workflow must be authored node by node. Use an LLM toolkit alone when one agent call is enough. OMA sits at the orchestration layer when several agents, dependencies, approvals, or recovery steps must work together.
For a named head-to-head against LangGraph, Mastra, CrewAI, the Vercel AI SDK, and others, see the comparison page.
Packages
@open-multi-agent/core: Orchestration runtime, tools, memory, checkpoints, traces, CLI, and offline Run Viewer.@open-multi-agent/otel: Optional enterprise integration for production teams with a centralized OpenTelemetry stack.create-oma-app: Scaffolder behindnpm create oma-app; starter templates with a no-key local demo.
Core users can store traces locally and inspect them with the offline Run Viewer. Install the OTel package only when OMA traces should appear in the same monitoring system as the rest of your application.
Commercial support
Need to embed agent capabilities in an existing product or business system? We help teams scope AI use cases, embed agent capabilities, and support delivery. Email jack@yuanasi.com.
Documentation
| Goal | Start here |
|---|---|
| Install and run | Core package guide · Examples · CLI |
| Configure models and tools | Providers · LLM egress policy · Tools and sandbox · External agents |
| Operate reliably | Observability · Evaluation · Checkpoint and resume · Durable approvals · Adaptive recovery · Context management |
| Control orchestration | Consensus · Execution routing · Model routing · Task scheduling · Plan replay · Shared memory |
Contributing
Issues and pull requests are welcome. See CONTRIBUTING.md for workspace boundaries, validation, and submission guidance.
Contributor credits by area are in CONTRIBUTORS.md.
License
MIT
