Open Multi-Agent: Runtime DAGs in TypeScript

“Use several agents” is not an architecture. The difficult part is deciding which work can run concurrently, which result unblocks another task, what state workers share, and how a failed branch affects the final answer. Open Multi-Agent (OMA) turns those questions into a runtime task graph instead of hiding them in a group chat.

The project is a TypeScript-native orchestration framework for Node.js applications. A coordinator can translate a goal into a directed acyclic graph (DAG), a deterministic scheduler executes ready tasks, and a synthesizer assembles the result. You can also provide the graph yourself when predictability matters more than automatic planning.

TL;DR

• OMA is strongest when a task has real parallel branches and explicit dependencies—not when you simply want several personas to talk.
• It can mix LLM workers, Claude Code, Gemini CLI, Codex, ACP agents, and local processes while retaining ownership of scheduling and budgets.
• planOnly, persisted runs, replay, approval gates, and deterministic pipelines make the system inspectable.
• Built-in tools are now default-deny, but older examples and pinned versions may retain broader behavior. Audit the exact release.
• Start with an explicit task graph. Let a coordinator generate graphs only after you have evaluation data for plans.

What the project actually does

Open Multi-Agent was released in April 2026 under MIT. It installs as @open-multi-agent/core and runs in your own Node.js environment. It should not be confused with OMAR, the tmux-based Open Multi-Agent Runtime, or with academic “open multi-agent systems.”

OMA describes itself as a TypeScript framework for dynamic, inspectable task graphs rather than a hosted agent service. Source: GitHub repository.

OMA exposes three useful execution shapes:

Mode	Who defines the work graph?	Best use
runAgent()	Nobody; one worker handles one prompt	Baseline and simple tasks
runTeam()	Coordinator model creates a DAG	Open-ended goals with measurable planning quality
runTasks()	Application supplies tasks and dependencies	Repeatable production workflows

There is also direct fan-out for MapReduce-style jobs. The distinction is healthy: not every problem needs a planner model, and not every parallel workload needs a multi-agent conversation.

Why a DAG is better than a chat transcript

Suppose a release-readiness review needs four artifacts: API compatibility, dependency risk, migration documentation, and test evidence. Compatibility and dependency checks can run in parallel. Documentation needs the compatibility result. The final recommendation needs all three branches.

inspect-api ───────> write-migration ──┐
                                      ├─> final-review
scan-dependencies ────────────────────┤
run-tests ────────────────────────────┘

A DAG makes “ready,” “blocked,” “failed,” and “complete” concrete scheduler states. A group chat leaves the model to infer those states from prose. That difference matters as the run gets longer or resumes after a crash.

The graph also provides a natural unit for budget and evidence. Each task can record its assignee, inputs, dependencies, token use, output, verification, and status. If the final synthesis is wrong, you can locate the branch that supplied bad evidence instead of rereading a long conversation.

Automatic planning is the risky part

The coordinator receives a goal and emits tasks plus dependency edges. Independent tasks then run concurrently. This is appealing, but an invalid plan can waste more tokens than a weak worker answer.

Use planOnly: true to inspect generated graphs before execution. In CI or cost-sensitive environments, validate at least these invariants:

• the graph is acyclic;
• every dependency names an existing task;
• tasks with write access do not target the same files concurrently;
• the coordinator has not assigned tools beyond an agent’s authority;
• the graph stays below task, depth, token, and wall-clock limits;
• required verification and synthesis nodes exist.

For repeatable workflows, encode the graph with runTasks(). Automatic DAG creation is most valuable when the goal genuinely changes shape between runs.

Mixing external coding agents

OMA’s current external-agent integration can place ACP or process-backed workers inside the same DAG. That means a Claude Code, Gemini CLI, Codex, or another agent process can own a task while OMA retains planning, scheduling, shared memory, budget accounting, and failure propagation.

External workers are task executors; OMA remains the control plane. Source: External coding agents guide.

This is a more useful interoperability story than pretending every coding agent has the same native protocol. Claude Code, for example, uses an ACP adapter in the documented setup. Process backends can bridge tools that do not speak ACP at all.

The boundary needs discipline. Give each external process a narrow working directory, an explicit environment, and a timeout. Shared memory should exchange task artifacts, not become an unfiltered bucket of prompts, secrets, and tool output.

Security improved after a serious default

OMA’s early behavior gave agents built-in tools implicitly, including unsandboxed bash. The v1.7 release changed that to default-deny: built-ins require a positive tools or toolPreset grant. The release note explicitly connects the old default to prompt-injection-driven command execution and exfiltration risk.

The release history is required reading because tool defaults and security controls evolved quickly. Source: OMA releases.

That candid change is a positive sign, but it creates an upgrade trap. Code written against an old release may rely on implicit tools. Teams may “fix” the upgrade by setting defaultToolPreset: 'full', restoring the dangerous behavior globally.

A safer migration grants capabilities per role:

• planners: no file or shell tools;
• researchers: allowlisted web access and read-only memory;
• developers: scoped file read/write and sandboxed commands;
• reviewers: read-only files, grep, and test evidence;
• synthesizers: task artifacts only.

Also separate tool authorization from task assignment. A coordinator may assign a developer task, but it should not be able to silently expand that developer’s capabilities.

Consensus and verification are not magic

Recent OMA releases add consensus or adversarial verification: proposers generate answers and judges evaluate them. This can reduce one-model blind spots, but voting does not turn opinions into evidence.

For code tasks, prefer executable checks—tests, type checks, linters, schema validation, and diff policies. Use model judges for qualities that deterministic tools cannot measure well, such as whether a migration explanation is understandable. Even then, blind the judge to irrelevant identity cues and keep the rubric versioned.

The cost grows quickly. If three workers and two judges each receive the same large repository context, a “small” verification step becomes five expensive calls. Pass task-scoped artifacts and cache shared prefixes where the provider supports it.

Observability should answer operational questions

Live progress events are useful for a UI, but production observability needs more than animated nodes. A run record should answer:

• Why did this task become ready?
• Which plan version created it?
• What tool authority did its worker hold?
• Which model and provider served the call?
• What input artifact version did it read?
• Did a retry repeat a side effect?
• Which evidence reached final synthesis?

Persisted run data and an offline viewer are valuable because they decouple investigation from a live process. Apply explicit privacy rules: prompts, tool output, and shared memory routinely contain source code or credentials.

A practical adoption test

Pick one workflow whose dependency graph humans can draw. Run it three ways: a strong single agent, an explicit OMA pipeline, and a coordinator-generated OMA team. Measure task success, wall time, tokens, retries, human interventions, and reproducibility.

The explicit graph should be the first production candidate. It tells you whether parallelism and artifact boundaries help before adding planner variability. If automatic planning later beats it on diverse goals without increasing unsafe writes or cost, graduate runTeam() behind graph validation and approval.

This progression complements the harness approach discussed in Copilot SDK Meets Agent Framework. A harness improves one agent’s operating loop; OMA focuses on turning multiple workers into a dependency-aware execution graph.

When OMA is a good fit

OMA makes sense for a TypeScript backend that needs self-hosted, provider-flexible orchestration and has tasks with observable parallel structure. It is particularly interesting when existing coding agents must become workers without surrendering control of the full workflow to any one vendor.

It is a poor fit for a short support bot, a linear two-step automation, or a team that cannot yet evaluate one agent reliably. A dynamic DAG multiplies the number of decisions you need to test. The orchestration is open source; the operational complexity is still yours.

FAQ

Is Open Multi-Agent a hosted service?

No. The core framework runs in your Node.js environment with your infrastructure and provider credentials.

Does it require the coordinator to generate every graph?

No. Use runTasks() for an application-defined graph, runTeam() for coordinator planning, or runAgent() for a single worker.

Can it run Codex or Claude Code?

Current documentation supports external agents through ACP or local process backends. Each integration still needs its own adapter, permissions, and lifecycle handling.

Are built-in tools safe by default?

Current releases default to no built-in tools unless granted. Verify your pinned version and avoid restoring a global full-tool preset merely to preserve old behavior.

Does consensus guarantee correct results?

No. Consensus can expose disagreement, but correlated models can agree on the same mistake. Prefer executable verification where possible.

Bottom line

Open Multi-Agent’s most important idea is not “more agents.” It is making decomposition, dependencies, authority, and evidence visible as run data. A dynamic DAG can unlock real parallelism, but it also makes the coordinator’s plan part of your executable control plane.

Treat that plan like untrusted code: validate it, constrain it, observe it, and keep a deterministic alternative for workflows that must behave the same tomorrow.