// capabilities · v1.19.0

From a goalto a governed run.

Run the no-key demo→v1.19 release notes↗

One TypeScript runtime for goal-driven teams and explicit task DAGs. Route the topology, schedule ready work, gate consequential actions, and keep the evidence in your own environment.

released · @open-multi-agent/[email protected]
  1. 01input

    Goal or DAG

    Start with an outcome through runTeam(), or supply the task graph through runTasks().

  2. 02route

    Single or team

    An explicit mode, governance policy, or ExecutionRouter selects the topology.

  3. 03schedule

    Ready work moves

    The event-driven scheduler starts dependents as soon as their prerequisites complete.

  4. 04govern

    Policy gates dispatch

    Approve the plan, each ready task, and every consequential tool call at the right boundary — or suspend one and decide out of process.

  5. 05evidence

    A receipt closes the run

    Routing, task results, traces, usage, and governance conclusions stay inspectable.

01 runtime surface

Six capability layers. One execution contract.

The layers below are shipped in the public package. Each one links to the version-matched Reference or guide.

01
plan · route

Choose the execution topology.

Generate a reviewable task DAG from a goal, execute a graph you define, or short-circuit eligible work to one agent. Explicit mode and governance declarations win; custom routers remain advisory and fall back safely. Opt into hybrid routing and one semantic assessment runs only where the deterministic router would have settled for a single agent — the policy that decides stays deterministic.

runTeam · runTasks · mode · ExecutionRouter · TaskProfiler · routingDecisionExecution routing→
02
schedule · dispatch

Move work when dependencies are ready.

Event-driven execution removes unrelated round barriers. Choose dependency-first, round-robin, least-busy, capability-match, or composite assignment, with hard task requirements and task-scoped results.

onTaskDispatch · requires · taskResults · dependencyPayloadTask scheduling→
03
control · govern

Put policy at the right boundary.

Declare required or preferred roles, ordered review paths, and budget-aware degradation. Gate plans, ready tasks, and consequential tools separately, then inspect governanceConclusion instead of inferring compliance. A gate can also suspend: the pending request and the reviewer decision persist beside the checkpoint, so the decision happens outside the callback and the run resumes on exactly the content that was reviewed.

governance · onPlanReady · onTaskDispatch · onToolCall · decideApprovalOrchestration controls→
04
bound · recover · revise

Stop new work, settle safely, revise what has not run.

Retries, model fallbacks, timeouts, loop detection, and token or estimated-cost budgets bound execution. Checkpoints persist safe runner boundaries as well as completed tasks, so restore skips finished work and replays a committed tool result rather than running that tool a second time. Opt into repairable recovery and a run revises the part of its graph that has not executed yet — each patch validated, gated, and applied atomically before any original dependent starts.

fallbacks · budgets · checkpoint · restore · toolCallId · PlanPatch · onPlanPatchAdaptive recovery→
05
inspect · evaluate

Turn a run into reviewable evidence.

Stable run identity, execution receipts, TraceStore, the offline Run Viewer, and optional OpenTelemetry make the run inspectable. An opt-in run journal adds the record telemetry cannot give you — every adapter call and the lineage of each block the model saw — and verifyRun() checks a finished journal cold. EvalSets, Scorers, reports, and gates turn that evidence into regression checks.

receipt · TraceStore · renderRunViewer · RunJournal · verifyRun · EvalSetObservability and evaluation→
06
models · tools

Bring the environment you already use.

Mix cloud and local models in one team, connect MCP servers as opt-in tools, and run external coding agents through ACP or process backends. Hand an agent prior turns and images as structured input, take images and files back from a tool, confine framework-owned model traffic to loopback or an origin allowlist, and choose where the built-in bash runs. Core remains an embeddable library, not a hosted service.

providers · MCP · ACP · modelOutput · egressPolicy · ShellExecutorIntegrations→
02 truth boundary

What this runtime does—and what it does not claim.

The public site follows the latest package released on both GitHub and npm. Development-only main features stay out of the shipped surface until they are published.

Published
Routing, governance, event-driven scheduling, dispatch approval, suspendable durable approvals, receipts, structured handoffs, model fallbacks, egress policy, pluggable shell execution, the opt-in run journal, the opt-in authoritative run store with execution leases, plan revision, and hybrid semantic routing are all in the published package.
Recovery
Checkpoint restore resumes at safe runner boundaries and replays committed tool results instead of re-running them, but external process and ACP backends stay task-grained, and a tool that ran without its result reaching the store runs again — use the exposed toolCallId as an idempotency key. The snapshot stays the recovery anchor and the run journal only extends it. An opt-in run store adds an authoritative lifecycle record, an execution lease, and a fencing token, so one worker at a time advances a run; it does not make external side effects exactly-once, and it claims cross-process atomicity only where you declare a backend that has it. Plan revision is forward-only: it appends replacement work and never undoes a side effect a task already performed.
Product layer
OMA is a self-hosted runtime library. It does not claim a hosted tenant, project, thread, seat, or RBAC control plane.
03 start with evidence

Run the local demo, then inspect the runtime.

Run the no-key demo→See the architecture→