// capabilities · v1.13.0

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.

  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.

runTeam · runTasks · mode · ExecutionRouter · 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.

governance · onPlanReady · onTaskDispatch · onToolCallOrchestration controls
04
bound · recover

Stop new work, settle safely, resume by task.

Retries, model fallbacks, timeouts, loop detection, and token or estimated-cost budgets bound execution. Checkpoints persist completed task boundaries so restore can skip work already done.

fallbacks · budgets · checkpoint · restoreCheckpoint and resume
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. EvalSets, Scorers, reports, and gates turn that evidence into regression checks.

receipt · TraceStore · renderRunViewer · EvalSet · GateVerdictObservability 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. Core remains an embeddable library, not a hosted service.

providers · MCP · ACP · process backend · default-denyIntegrations
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
v1.13.0: routing, governance, event-driven scheduling, dispatch approval, receipts, structured handoffs, and model fallbacks.
Recovery
Checkpoint restore resumes at completed task boundaries. It is not mid-task recovery or an authoritative exactly-once RunStore.
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.