open-multi-agent: Open Multi-Agent: The Framework That Turns Goals Into Agent Graphs

A TypeScript-native orchestration engine that plans work at runtime, pauses for human approval on consequential actions, and keeps the whole run auditable from start to finish.

8 to 10 min read • View on GitHub • More from JackChen-me

A goal document on a desk transforms into a branching network of task cards, with one branch paused behind an approval gate while others continue moving. A human hand hovers near a stamp that signals approval, making the run feel like a controlled command center rather than a fantasy machine. This visual explains how OMA turns a goal into a runtime DAG and inserts human review when needed. — OMA does not ask you to pre-draw the workflow. It turns the goal into the workflow, then pauses the parts that need judgment.

Describe the goal, not the graph. A self-organizing team of agents that runs in your environment, pauses for approval on consequential actions, and leaves a verifiable record of every run.

Jack Chen, Creator of Open Multi-Agent · open-multi-agent/open-multi-agent

Key Takeaways

OMA shifts the developer’s job from drawing a workflow to setting the policies that let the workflow emerge at runtime.
Its main edge is not more agents. It is a coordinator that turns a goal into a DAG, then keeps execution auditable and resumable.
The framework treats approval, checkpoints, and concurrency as first-class runtime concerns, not afterthoughts.
OMA is strongest for TypeScript and Node teams that want production control without giving up agent flexibility.

The Graph Is the Output

Most agent frameworks make you design the graph first. OMA flips that. You give it a goal, and a coordinator turns that goal into a task DAG after the run begins. That sounds subtle until you realize it changes the developer’s job from workflow architect to policy designer.

That distinction is the whole story. A graph-first framework asks you to anticipate the shape of the work. OMA asks you to define the rules for how work should be split, routed, paused, and resumed.

A close-up scheduler board shows three task lanes. Two lanes run in parallel, one lane waits behind a lock icon, and a checkpoint ledger sits beside it. A second hand is blocked from writing into the same message history, which explains how OMA combines concurrency with per-agent safety. — Parallel work is easy to promise. The harder part is preventing agents from stepping on each other. OMA makes both visible.

This diagram shows the runtime path from a goal to a live DAG, including the pause point for approvals and the checkpoint that makes resume possible.

Why That Matters More Than It Sounds

The practical payoff is smaller surface area. In graph-first systems, you own every node and edge. In OMA, you own the policy that shapes the graph. That is easier to reason about, easier to review, and easier to explain to a team that does not want orchestration logic scattered across a codebase.

It also fits the way production teams actually work. Policies get reviewed. Goals change. Tool access changes. Human approvals get added after the first incident, not before. A runtime coordinator lets those changes land without rewriting the entire flow.

Dimension	OMA	Graph-first frameworks	Chat-first frameworks
Workflow definition	Goal plus policy	Explicit nodes and edges	Conversation turns
Runtime planning	Built in	Mostly manual	Limited
Human approval	First-class	Usually custom	Usually custom
Durability	Checkpointed runs	Depends on implementation	Often ephemeral
Concurrency	Scheduler and locks	Vary by framework	Often simple or ad hoc
TypeScript fit	Native	Usually secondary	Strong for UI, lighter for orchestration
Auditability	Traceable run state	Possible, but developer-built	Often partial

A Coordinator, Not a Static Workflow

The codebase reflects that philosophy. OMA starts with a coordinator agent, then moves through task profiling, DAG construction, scheduling, and agent assignment. The interesting move is semantic routing. Tasks are not just queued. They are profiled so the system can decide which agent is best suited to handle them.

The repository is built around a TypeScript core, with Node.js 20+ as the runtime and `zod` for validation. That matters because it makes the framework feel native to modern backend teams that already live in the JavaScript ecosystem.

// Conceptual flow from the repo's orchestration layer
const goal = "Analyze this repo and draft a release plan";

const coordinator = new OpenMultiAgent({
  maxConcurrency: 6,
  onToolCall: async (call) => {
    if (call.consequential) {
      return suspendForApproval(call);
    }
    return executeTool(call);
  },
});

const run = await coordinator.plan(goal);
const dag = await run.buildTaskDag();
await coordinator.schedule(dag);

The Safety Valve Is Built In

This is where OMA stops looking like a clever demo and starts looking like infrastructure. Shell commands and file writes are not treated as ordinary tool calls. They can trigger a suspend, save state, and wait for a human to approve the action before the run continues.

That pattern matters because it makes approval a runtime event, not a product policy scribbled in a README. The state survives the pause. The run can resume later. For long-running or sensitive tasks, that is the difference between a toy and a system you can trust.

Why It Can Run Hot Without Falling Apart

The concurrency story is equally important. OMA uses a scheduler to handle parallel tasks, an agent pool to enforce max concurrency, and per-agent locks so two tasks do not corrupt the same message history. In plain terms, it parallelizes hard work without letting shared state turn into a race condition.

The design is disciplined rather than magical. It is a turn-based agent loop, a semaphore-backed pool, and durable checkpoints around the fragile moments. That combination is what makes the runtime coordinator credible.

What OMA Is Actually Competing Against

OMA is not trying to win by out-featuring every framework. It is making a cleaner architectural bet. Compared with LangGraph, it is less graph-first and more goal-first. Compared with CrewAI and AutoGen, it is more TypeScript-native and more explicit about durable approval and scheduling. Compared with the Vercel AI SDK, it goes deeper on orchestration rather than streaming and UI.

Project	Core model	Best at	OMA’s difference
OMA	Runtime-planned DAG with policy gates	Dynamic orchestration in Node and TypeScript	The graph is generated from the goal
LangGraph	Explicit state graph	Fine-grained workflow control	Requires more upfront graph design
CrewAI	Role-based agent crews	Simple team-style coordination	Less centered on runtime DAG creation
AutoGen	Conversational agents	Multi-agent conversation patterns	Less opinionated about durable orchestration
Vercel AI SDK	Streaming and app integration	LLM UI and developer experience	Not built as a multi-agent scheduler

The market gap is clear. There are plenty of tools for talking to models. Fewer tools help you run a governed team of agents in production, with audit trails and approval points baked in.

The Bet Behind the Project

OMA is betting that the next useful layer in agent systems is orchestration policy. Not bigger prompts. Not more tools. Policy: how goals become tasks, how tasks become schedules, when a run pauses, and how a human gets back into the loop without losing state.

That is a serious bet. If it holds, frameworks like OMA will look less like libraries and more like control planes for agent work. If it does not, they will still have clarified where the hard problems live. Either way, the graph is no longer the point. The rules are.