// capabilities · v1.16.0

From a goalto a governed run.

Run the no-key demo→v1.16 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/core@1.16.0
  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. 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.

governance · onPlanReady · onTaskDispatch · onToolCallOrchestration 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 completed task boundaries so restore can skip work already done. 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 · 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. 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
Routing, governance, event-driven scheduling, dispatch approval, receipts, structured handoffs, model fallbacks, opt-in plan revision, and opt-in hybrid semantic routing are all in the published package.
Recovery
Checkpoint restore resumes at completed task boundaries. It is not mid-task recovery or an authoritative exactly-once RunStore. 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 v1.16 architecture→