// open-source TypeScript multi-agent framework

A self-organizing team of AI agents, in an environment you control.

Q: How does the coordinator turn a goal into a DAG?

It plans before any agent runs. The coordinator breaks the goal into tasks, infers their dependencies, and emits a directed acyclic graph. Independent tasks run in parallel; dependent ones wait for their inputs. Pass planOnly to review the graph first.

Q: Can agents in one team use different model providers?

Yes. Each agent declares its own model, so one team can mix a cloud model, a self-hosted endpoint, and a local Ollama instance. The coordinator routes each task to its agent, and the model follows.

Q: What happens when a node fails?

It is retried when the error may be transient, and marked FAILED when it is not. Budget exhaustion, malformed input, deliberate aborts, and non-retryable client errors skip the retry. A FAILED node holds its dependents; independent branches keep running. In recovery.mode: 'repairable', a Replanner can revise the unexecuted part of the graph instead of carrying it forward.

Q: How do I cap what a run costs?

Set maxCostBudget with your own estimateCost price table. OMA accumulates the estimate across the run and stops issuing calls once the cap is crossed. The check runs at turn and task boundaries, so it can overshoot by one model turn. maxTokenBudget caps tokens the same way, and modelRouting puts cheaper models on leaf tasks.

Q: We do not have an engineering team. How do we get this into production?

元定义科技 (YuanASI) delivers it for you. We scope the use case, build the agent team on OMA, connect it to your systems, and support it after launch. The framework stays MIT-licensed and free to run yourself. Reach us at yuanasi.com, by email, or on WhatsApp.

Every seam, an interface. Every run, a record. Describe the goal; the coordinator plans the rest, and every step stays in your hands.

★ 6,884GitHub stars 57contributors 24releasesMITlicense

team.tsfull script

const oma = new OpenMultiAgent({ maxConcurrency: 3 })
const team = oma.createTeam('security-analysis-team', { agents: [
  { name: 'attack-surface-reviewer', systemPrompt: '…', maxTurns: 2 },
  // … data-security-reviewer, supply-chain-reviewer, synthesizer
] })
const goal = 'Review this service for security vulnerabilities…'
const result = await oma.runTeam(team, goal)

decomposes into

parallel ×3

#4f90f545attack-surface-reviewer10.7s

#b47191e7data-security-reviewer34.8s

#d1c1ab67supply-chain-reviewer40.8s

#168862baafter 3synthesizer51.3s

real run · runTeam() · deepseek-v4-flash · 4 tasks · 122s · run 8412d609

01 Why OMA

From intent to a controlled, inspectable run.

Choose the topology, move ready work, gate or suspend at the right boundary, recover and revise, and keep evidence you can verify.

01plan → route

Start from an outcome—or an explicit graph.

Give runTeam() a goal and get a reviewable task DAG, or hand runTasks() the graph you wrote. Mode, governance, or an ExecutionRouter decides single agent or team.

runTeam · runTasks · mode · strategy: 'hybrid'

Review execution routing→

02schedule → dispatch

Move work as soon as dependencies are ready.

Downstream tasks start the moment their dependencies finish, with no round barriers. Approve each dispatch, and a task no agent can satisfy is rejected before it runs.

event-driven · onTaskDispatch · requires · taskResults

Open task scheduling→

03approve → suspend

Gate each boundary, decide out of process.

Gate the plan, a ready task, or a consequential tool call, each at its own boundary. Return { action: 'suspend' } and the decision waits in the checkpoint store until another process makes it.

onPlanReady · onToolCall · { action: 'suspend' } · decideApproval · restore

Open durable approvals→

04recover → revise

Resume from the last safe boundary, revise what has not run.

Restore resumes from the last safe boundary and replays committed tool results instead of re-running them. In repairable mode, a validated PlanPatch revises the part of the graph that has not run.

checkpoint · toolCallId · recovery.mode: 'repairable' · PlanPatch · maxCostBudget

Open adaptive recovery→

05inspect → verify

Turn a run into evidence you can check.

Receipts, traces, and the offline Run Viewer show what each run did. Turn on the run journal and verifyRun() proves what the model saw from the events alone; the same records feed EvalSets and CI gates.

receipt · TraceStore · RunJournal · verifyRun · EvalSet

Open the run journal→

06your environment

Run where your data already lives.

Cloud, local, or air-gapped models on your credentials, with three runtime dependencies. Tools are default-deny, egress policy bounds the built-in adapters, and Claude Code, Codex, or Gemini CLI join the DAG over ACP.

default-deny tools · egressPolicy · ShellExecutor · ACP

Open the egress policy→

Run evidence

Inspect what happened after every run.

The offline Run Viewer turns a completed run into reviewable evidence, without sending it to a hosted OMA service. With the run journal on, verifyRun() checks the same run again from its own events.