open-multi-agent: a TypeScript runtime where the coordinator builds the task DAG

What open-multi-agent solves, and who it is actually for

Most multi-agent code starts as a hand-wired graph. You declare nodes, edges, and the order they fire, then you maintain that shape as the task changes. open-multi-agent inverts the direction: the README's tagline is "Describe the goal, not the graph." A coordinator reads one goal, builds a task DAG at runtime, assigns work to agents, and synthesizes the result. Nothing in the basic example declares a task graph.

The audience is narrow and specific. This is a TypeScript framework that "drops into any Node.js app," so the natural user is a backend engineer already writing Node services who wants agent orchestration as a library rather than as a separate service to operate. The package.json sets `engines.node` to `>=20.0.0`, and the README adds that production should use a currently maintained Node.js LTS release. If your stack is Python, this is the wrong repository.

The second group is teams with a compliance or privacy constraint. The framework runs in your own environment and credentials, and the README claims local, offline, and air-gapped operation is possible. Tools are default-deny and individual calls are gated. That combination is the reason someone picks this over a hosted orchestration product, not the orchestration itself.

How the coordinator turns a goal into a task DAG

The mechanism has three moving parts. A coordinator plans, a deterministic scheduler executes, and the run is written down as inspectable data. The README describes it as: "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 scheduler being deterministic matters more than it sounds. If the plan is produced by a model but executed by a component that follows the plan mechanically, then a replay of the same approved plan should reproduce the same dispatch order. The README states you can "freeze approved plans for replay," which is the feature that makes the plan auditable rather than merely logged.

Three entry points exist, and picking the right one is the first design decision. `runTeam()` plans from a goal. `runAgent()` runs a single agent. `runTasks()` executes an explicit pipeline. So the dynamic behavior is opt-in per call site: a team that needs a stable topology can still be driven through the explicit path.

Around the scheduler sit the recovery paths. Runs resume from checkpoints. There is an optional mode the README calls "append-only plan repair at task outcome barriers," plus retries, timeouts, loop detection, and token and cost budgets. The runtime is also open in the provider sense: process and ACP backends put Claude Code, Gemini CLI, and Codex on the same task DAG, shared memory, and budgets as LLM agents, and there is a fallback parser for local models that emit tool calls as text.

Installing open-multi-agent and running a first team

There are two entry paths. The scaffold is the faster one and, importantly, does not require an API key. The README states that in an interactive terminal the command selects a starter and runtime, installs dependencies, and runs a deterministic local demo where scripted model responses drive the real scheduler, result aggregation, and offline dashboard.

npm create oma-app@latest my-oma

Run that from a directory where you want the project created. In a non-interactive shell you will not get the starter picker, so run it in a real terminal if you want the demo to complete.

If you already have a backend, add the core package instead.

npm install @open-multi-agent/core

Then a minimal team looks like this. The README gives this example, with `sharedMemory: true` so both agents see the same context, and a single goal string passed to `runTeam()`.

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)

The README notes that this example needs `OPENAI_API_KEY` set. Note what the final line reads: the coordinator's output, not the researcher's. The coordinator is the agent that synthesizes, so that is where the answer lands. `docs/providers.md` covers other hosted models, local servers, OpenAI-compatible endpoints, and AI SDK providers. The example index under `packages/core/examples/README.md` lists more than 50 runnable examples across basics, cookbook workflows, patterns, providers, and integrations.

Where the dynamic DAG gets in your way

A runtime-planned graph is a liability when the task is already known. If your workflow is extract, transform, load, in that order, every time, then paying for a planning step and accepting plan variance buys you nothing. Use `runTasks()` for that, or use a workflow engine that never calls a model to decide the shape of the work.

The second cost is nondeterminism at the plan level. The README offers a mitigation rather than a removal: you can "declare required roles and order when topology cannot drift." That is a real escape hatch, but it means the framework has two modes, and the moment you constrain topology you are back to maintaining a graph, just expressed as role and order declarations instead of edges. The dynamic mode and the controlled mode are not the same product.

Third, the provider story is broad enough to be a support surface. Hosted models, local servers, OpenAI-compatible endpoints, AI SDK providers, process and ACP backends, and a text fallback parser for local models are all listed. Breadth here is not a quality claim; it means the failure modes depend on which combination you pick, and the README does not enumerate them per provider.

Finally, the run viewer is described as offline and built in, and the README says the dashboard replays a real run. That is a replay tool, not live monitoring. The README points to an optional OpenTelemetry adapter for export, so if you need streaming production telemetry, that adapter is the path, and it is optional rather than default.

How this differs from LangGraph and CrewAI

The closest comparison is LangGraph, where you define a graph of nodes and edges in code and the framework executes that graph. The graph is the artifact you author. In open-multi-agent the graph is an output: the coordinator produces it at runtime, and the artifact you keep is the plan record. That difference drives everything downstream. With an authored graph, reviewing behavior means reading the graph definition. With a generated plan, reviewing behavior means reading a plan that a model wrote, which is why the framework invests in preview, approval, freezing, and replay rather than in graph visualization alone.

CrewAI is the other common reference point, and the split is language and deployment rather than orchestration philosophy. CrewAI is Python; open-multi-agent is TypeScript with a `>=20.0.0` Node engine requirement and an npm package, `@open-multi-agent/core`. If your services are Node, that is the deciding factor, not the agent model.

There is a third difference worth naming, because it is the one the repository's own package.json emphasizes: the description reads "Self-hosted TypeScript agent runtime with durable approvals and verifiable run records. Own it, approve it, audit it." The pitch is not capability breadth. It is that approvals are durable and run records are verifiable, which is a claim about recovery and evidence, not about how clever the planner is.

Licence, maintenance and the cost of upgrading

The licence is MIT, declared in the repository root LICENSE file and in package.json. MIT is permissive: it allows commercial and closed-source use, and it carries no copyleft obligation on your own code. It also comes with no warranty, which is the standard trade. Nothing here is legal advice; read the LICENSE file and your own counsel's view before shipping.

The repository is not archived, and the last push was on 2026-08-28, the same day as the v1.17.0 release. The two prior releases were v1.16.1 on 2026-08-21 and v1.16.0 on 2026-08-16. That is a release cadence measured in days across August 2026, and it is the concrete evidence for the project's current activity level. It says nothing about whether the API is stable.

The upgrade cost is the part the README does not address. There is a CHANGELOG.md at the repository root, so release-by-release changes are documented somewhere, but the README does not document a deprecation policy, a semantic-versioning commitment, or a rollback procedure for a bad upgrade. The root package.json version is `0.0.0` and marked private, which is a monorepo convention: the published version lives in the workspace package, currently `@open-multi-agent/core` at v1.17.0. If you pin, pin against the workspace package, not the root manifest. Treat the three-releases-in-a-month pattern as a reason to pin an exact version in your own package.json rather than accept a caret range.

Editorial conclusion

Adopt open-multi-agent if you are building a TypeScript backend and want the plan itself to be data you can approve, checkpoint and replay, rather than a graph you maintain by hand. Skip it if your workflow is a fixed pipeline with known steps, or if your team is not on Node.js 20 or newer. Before committing, verify two things in your own environment: that `npm create oma-app@latest` runs the keyless deterministic demo end to end, and that your chosen provider path is documented under docs/providers.md, including any fallback parser you would need for a local model that emits tool calls as text.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes