# Open Multi-Agent — full text for LLMs

> Self-hosted TypeScript agent runtime for multi-agent systems. Consequential actions wait for durable, tamper-evident approvals, and every run leaves a record you can verify offline, byte for byte. No telemetry and no hosted control plane. Drops into any Node.js backend.

This document assembles the substantive copy from open-multi-agent.com into a single
plain-text file for LLM ingestion. Source of truth for the API is the GitHub repository
and the docs at https://open-multi-agent.com.

- Install: `npm create oma-app@latest`
- Package: `@open-multi-agent/core` (npm)
- Latest release: v1.19.0
- License: MIT
- Runtime: Node.js 20+ (Node 18 reached end of life on 2025-04-30; Node 22 or 24 recommended), three runtime dependencies (Anthropic SDK, OpenAI SDK, Zod)
- Repository: https://github.com/open-multi-agent/open-multi-agent
- Maintainer: YuanASI (Shenzhen YuanASI Technology Co., Ltd.), https://yuanasi.com

## What it is

Open Multi-Agent (OMA) is an agent runtime, not a graph builder. It is goal-first, not
graph-first: you describe the outcome, and OMA owns the decomposition, the parallelism,
and the synthesis. You pass a goal, not a graph — a coordinator agent decomposes it into
a task DAG, parallelizes the independent nodes, and synthesizes the result. It is a
library, not a platform: it composes with the providers, protocols, and servers already
in your backend, with no daemon and no sidecar.

## Minimal example

```ts
import { OpenMultiAgent } from '@open-multi-agent/core'

const oma = new OpenMultiAgent({ defaultProvider: 'openai', defaultModel: 'gpt-5.4' })

const team = oma.createTeam('research-team', {
  name: 'research-team',
  agents: [
    { name: 'researcher', systemPrompt: 'Find the relevant facts.' },
    { name: 'analyst', systemPrompt: 'Compare evidence and identify tradeoffs.' },
  ],
  sharedMemory: true,
})

// coordinator plans the DAG, runs independents in parallel, synthesizes
const result = await oma.runTeam(team, 'Compare three approaches and recommend one.')
console.log(result.agentResults.get('coordinator')?.output)
```

`runTeam()` returns when the whole DAG resolves — no manual node wiring, no scheduler to
maintain. Any agent can override the defaults with its own `model` and its own `tools`
array; anything it does not list is unavailable to it.

## Capabilities

**Goal-driven coordinator.** You pass a goal, not a graph. The coordinator decomposes it
into a task DAG, runs the independent nodes in parallel, and synthesizes the final result.

**Execution routing and governance.** `runTeam()` can use an explicit `single` or `team`
mode, a custom `ExecutionRouter`, or the built-in deterministic router. Applications can
declare required roles and order; results expose both routing decisions and a
post-execution governance conclusion.

**Hybrid semantic routing (v1.14, opt-in).** Automatic routing stays deterministic by
default. `executionRouting.strategy: 'hybrid'` adds at most one no-tool model call, and
only where the deterministic router would otherwise choose Single. The model does not
choose the topology: a profiler returns a strict `TaskProfile` — independent evidence,
independent review, conflicting objectives, side-effect intent, permission isolation,
decomposability, parallelism, complexity, confidence — and a deterministic policy consumes
it alongside framework-computed facts. High-confidence signals can upgrade Single to Team;
low confidence keeps Single; v1 never turns Team into Single. The profiler is treated as a
hostile-input surface: it receives no system prompts, credentials, or tool
implementations, and it cannot call tools. A profile never creates `requiredRoles`,
approves a side effect, or proves governance was satisfied — the executed topology, the
final tool grants, and the `ExecutionReceipt` remain governance truth. Profiling usage is
charged to the run's token and cost budget, and is reported in
`semanticRoutingAssessment`.

**Event-driven task scheduling.** Ready tasks dispatch as soon as their dependencies
complete. Scheduling policies, hard capability requirements, task priority,
`onTaskDispatch` approval, structured dependency payloads, and `taskResults` make the
explicit DAG path controllable without reverting to round-based execution.

**Adaptive plan recovery (v1.14, opt-in).** A retry re-runs the same task; a full re-plan
discards what already succeeded. `recovery.mode: 'repairable'` is the option in between:
after a task succeeds, fails, or is rejected by consensus verification, a `Replanner` may
propose an append-only `PlanPatch` over the part of the graph that has not started —
adding tasks (`addTasks`), reassigning a pending or blocked one (`retargetPending`), or
skipping one (`supersedePending`). The patch lands on an outcome barrier rather than in a
retry loop: OMA validates agent eligibility, limits, task states, references, and the
resulting DAG, runs the optional `onPlanPatch` approval, applies the patch atomically, and
persists a checkpoint when checkpointing is enabled, before the triggering task completes
or cascades. Nothing is rewritten or deleted, and history stays truthful — a repaired
failure is still `failed` with `recoveredByRevision`, a replaced branch is `skipped` with
`supersededByRevision`, and accepted revisions surface in `result.planRevisions`, progress
events, and observability spans. Repairs are forward-only: OMA does not undo side effects
a task already performed, and `runFromPlan()` rejects repairable recovery because it is
exact replay. `onTaskOutcome` is the shorthand for applications that don't want a named
`Replanner` — configure one or the other, not both. Reference:
https://open-multi-agent.com/reference/adaptive-recovery/

**Mix any model in one team.** Each agent names its own model, and they cooperate inside a
single team. Built-in providers include Anthropic, OpenAI, Gemini, Bedrock, Azure OpenAI,
and DeepSeek, plus any OpenAI-compatible endpoint.

**Tools and MCP, default-deny.** An agent gets only the tools it is granted. Model Context
Protocol servers expose external systems under the same opt-in contract.

**Streaming and structured output.** Stream tokens and node-state transitions as the DAG
fills, or await a typed, schema-validated object when the run completes.

**Cross-provider reasoning.** One `thinking` config maps to Anthropic thinking, Gemini
`thinkingConfig`, OpenAI `reasoning_effort`, and DeepSeek V4 Flash's `thinking.type`
(where `thinking.effort` also accepts the DeepSeek-only value `'max'`, which is not
forwarded to OpenAI, Azure OpenAI, or GitHub Copilot). Reasoning streams as events, and
can be preserved across a provider switch when you opt in.

**External agents.** A team member can use a local `process` backend or an Agent Client
Protocol (`acp`) backend instead of a model. It joins the same task DAG, shared memory,
failure propagation, and result shape as an LLM-backed agent. The subprocess still owns
its own tools and local permissions; ACP permission prompts are not an OMA filesystem or
OS sandbox.

**Evaluation.** The `@open-multi-agent/core/eval` subpath runs versioned EvalSets and
scorers, persists EvalRecords, produces CI GateVerdicts, and can sample completed
production runs on a best-effort basis. Evaluation observes completed results and never
changes the business result.

**Fail closed on invalid input (v1.14).** Three validation paths moved from permissive to
strict: an invalid task dependency graph is rejected up front instead of executing a
partially valid plan; the coordinator fails closed on a plan it could not validate; and
task requirements are enforced as global hard constraints, so a task whose requirements no
agent satisfies is rejected rather than assigned to an ineligible agent
(`validateTaskRequirements` is exported for checking a roster before dispatch). This is a
real behavior change — a run that previously finished with an invalid DAG or an
unsatisfiable requirement now fails at validation time, surfacing a defect that was
already present. Correct graphs and rosters are unaffected.

## Platform and compatibility (v1.14.0)

Node.js 20 is the floor across `@open-multi-agent/core`, `@open-multi-agent/otel`, and
`create-oma-app`; Node 18 reached end of life on 2025-04-30. Node 22 or 24 is the
recommended runtime — 20 is a migration window that the next major release will remove, no
earlier than 2026-10-31. The bundled `openai` dependency moved from v4 to v6: user aborts
are now classified as cancellation rather than as a retryable failure, and an
OpenAI-compatible response containing the separate `custom` tool-call variant raises
`UnsupportedToolCallError` instead of collapsing into an empty successful turn. Every
public export from 1.13.0 is still exported and new result and configuration fields are
optional, so existing callers and serialized results keep type-checking. Adaptive recovery
adds a version 2 task-queue snapshot carrying plan-revision history;
`TaskQueue.fromSnapshot()` still accepts version 1 snapshots, so checkpoints written by
earlier releases remain restorable.

## You hold the controls

Handing real work to autonomous agents raises three fair questions — do they run off the
rails, burn the budget, or fail where you can't see it? Each one has an answer in the API.

**Stay in the loop.** Inspect the plan with `onPlanReady`, approve one ready task with
`onTaskDispatch` (or retain legacy round approval with `onApproval`), gate one
consequential tool call with `onToolCall`, and approve a mid-run plan repair with
`onPlanPatch`. A proposer→judge pass (`runConsensus`) has one agent check another's
output, and loop detection halts an agent that starts repeating.

**Control spend.** Route planning to a flagship model and leaf tasks to cheaper models
with `modelRouting`. `maxTokenBudget` caps cumulative input + output tokens;
`maxCostBudget` uses an application-owned `estimateCost` function so your own model and
provider price table stays authoritative. Both are circuit breakers checked after usage
is reported at turn and task boundaries, so a run can cross a configured ceiling by up
to one model turn. Provider invoices remain the source of truth for billed cost.

**Inspect, replay, resume.** Task-scoped results, routing decisions, and
`buildExecutionReceipt()` preserve compact execution evidence. Existing `onTrace`
callbacks remain supported. TraceRecord v2
sinks can write to `InMemoryTraceStore`, the persistent single-process `FileTraceStore`,
or the optional `createOtelTraceSink()` bridge in `@open-multi-agent/otel`; the application
owns the OpenTelemetry provider lifecycle. Open the offline Run Viewer after a run
(`oma run --dashboard`), freeze a reviewed plan with `createPlanArtifact()` and execute it
with `runFromPlan()`, or resume a crashed run from its last completed task. Prompt,
completion, tool payload, credential, and reasoning filtering is best-effort, so apply
your own sink policy before export. Checkpoints and shared-memory values are outside
telemetry redaction; wrap the durable store with `RedactingStore` when they may contain
secrets.

## What you can build

Three workflows, three explicit orchestration choices — each a runnable recipe with the
orchestration decision made explicit rather than implied.

**Adaptive customer support (support · escalation) — goal-driven, `runTeam()`.** A
coordinator selects the specialists a shipping or billing escalation actually needs, then
synthesizes their evidence. Outcome: a grounded response shaped around the actual support
goal.

**Contract review (legal ops · review) — explicit DAG, `runTasks()`.** Extract clauses
once, run compliance and summary work in parallel, then wait for both before producing the
notification. Outcome: a complete Markdown review with step-level retry.

**Incident postmortem (sre · operations) — explicit DAG, `runTasks()`.** Three
fixture-backed investigations start in parallel, then feed a root-cause hypothesis and a
final postmortem. Outcome: a traceable Markdown artifact with timing and token-cost
evidence.

These are prototypes with fixtures and stated limits, not customer deployments. Runnable
versions live in the goal-grouped examples catalog:
https://open-multi-agent.com/examples/

## Works with your stack

A library, not a platform. It composes with the providers, protocols, and servers already
in your backend.

- **Providers** — Anthropic, Gemini, OpenAI, Bedrock, Azure, DeepSeek, and more — or any OpenAI-compatible endpoint.
- **MCP** — connect Model Context Protocol servers as tools (native).
- **Vercel AI SDK** — bridge to 60+ AI SDK providers and hosts (compatible).
- **OpenTelemetry** — map TraceRecord v2 through the optional `@open-multi-agent/otel` adapter to an application-owned provider.
- **External agents** — run a local process or ACP coding agent as a first-class member of the same task DAG.
- **Express** — mount runTeam() behind a route handler (drop-in).
- **Any Node.js** — no daemon, no sidecar; three runtime deps (Node 20+).

Integration guides live at https://open-multi-agent.com/integrations/ (OpenTelemetry,
external agents over ACP, Anthropic, OpenAI, Gemini, DeepSeek, AWS Bedrock, Azure OpenAI,
Ollama, and any OpenAI-compatible endpoint).

## Common use cases

The shapes teams build most often with OMA, each a use-case guide with runnable TypeScript
at https://open-multi-agent.com/solutions/.

- **Run LLM calls in parallel** — several specialist agents work at once, return typed output, and an aggregator merges them; the coordinator handles the fan-out. https://open-multi-agent.com/solutions/parallel-llm-calls/
- **Goal-driven orchestration** — describe the goal instead of wiring the graph; the coordinator decomposes it into a task DAG at runtime and parallelizes it. https://open-multi-agent.com/solutions/goal-driven-orchestration/
- **Mixed-model agent teams** — each agent names its own provider (Claude, GPT, Gemini, or a local model), cooperating in one run with cost and latency you can watch. https://open-multi-agent.com/solutions/mixed-model-teams/
- **Local agents with Ollama** — run a team fully on your own machine, even the coordinator on a local model at $0 API cost, or a hybrid that keeps sensitive work local and bursts to the cloud. https://open-multi-agent.com/solutions/local-agents-ollama/
- **Durable shared memory** — MemoryStore persists namespaced key-value state and completed-task checkpoints across runs; semantic recall requires a separate memory layer. https://open-multi-agent.com/solutions/agent-memory/
- **Vercel AI SDK orchestration** — add multi-agent orchestration to an existing AI SDK app; the SDK talks to models while runTeam() decomposes the goal. https://open-multi-agent.com/solutions/vercel-ai-sdk-orchestration/

## FAQ

**How does the coordinator turn a goal into a DAG?**
A coordinator agent plans the work: it breaks the goal into discrete tasks, infers
dependencies between them, and emits a directed acyclic graph. Independent nodes run
concurrently; dependent nodes wait on their inputs. Pass planOnly to inspect the DAG
before any agent executes.

**Can agents in one team use different model providers?**
Yes. Each agent declares its own model, so a single team can mix a frontier cloud model,
a self-hosted endpoint, and a local Ollama instance. The coordinator routes each task to
the agent — and therefore the model — assigned to it.

**How do tools get exposed to an agent?**
Default-deny. An agent only has the tools it explicitly lists in its tools array;
everything else is unavailable. External systems are connected through MCP servers under
the same opt-in contract.

**What happens when a node fails?**
A failed node is retried under its task policy when the error may be transient. Budget
exhaustion, malformed input, deliberate aborts, and non-retryable client errors skip
pointless retries. Persistent failures surface on the node with FAILED state and an error,
downstream dependents are held, and independent branches can continue. With
`recovery.mode: 'repairable'` a `Replanner` can additionally propose an append-only patch
over the part of the graph that has not started.

**How do I keep a multi-agent run from going off the rails?**
Layered controls, all opt-in. onPlanReady hands you the decomposed plan to inspect before
any agent runs. `onTaskDispatch` gates one ready task, while `onApproval` preserves legacy
round gates. `onToolCall` can require confirmation for one consequential action, and
`onPlanPatch` gates a mid-run plan repair. Declared governance checks required roles and
order after execution; `runConsensus` and loop detection add result and behavior checks.

**How do I cap what a run costs?**
Use `maxCostBudget` with `estimateCost`; the estimator owns the per-model price table.
OMA accumulates the estimate across the run and stops issuing further calls after the cap
is crossed. Checks happen at turn and task boundaries, so the run can exceed the ceiling
by one model turn. `maxTokenBudget` provides the parallel cumulative-token ceiling, and
`modelRouting` can put cheaper models on leaf tasks.

**Does it stream, or only return at the end?**
Both. You can stream tokens and node-state transitions as the DAG fills, or simply await
runTeam() for a typed, schema-validated result object once the graph resolves.

**How does open-multi-agent relate to Claude Code's dynamic workflows?**
They make the same bet — the model plans the work at runtime instead of you wiring a fixed
graph. Claude's dynamic workflows run inside Claude Code, where Claude writes its own
orchestration scripts and fans out parallel subagents in a session. open-multi-agent embeds
that same goal-to-DAG idea in your own Node.js backend as an MIT library, on any provider,
with the plan kept as inspectable, replayable data. The two also compose: over ACP an
open-multi-agent team can run Claude Code itself as one of its agents.

## How it compares

Honest, sourced comparisons live at https://open-multi-agent.com/compare/. The through-line: OMA is goal-first (you describe the outcome; the coordinator builds the task DAG at runtime), TypeScript-native, three runtime dependencies, and it provides run-level token or estimated-cost circuit breakers through `maxTokenBudget` and `maxCostBudget` + `estimateCost`. Checks happen at turn and task boundaries and may cross the configured ceiling by one model turn. Most of the thirteen frameworks below cap steps or turns rather than tokens; Pydantic AI's `UsageLimits` is the notable exception, with a token-usage limit of its own.

- vs LangGraph — graph-first vs goal-first. LangGraph compiles a declarative state graph you define; OMA decomposes a goal at runtime. LangGraph's TypeScript port is GA and its persistence + time-travel ecosystem is deeper; OMA is leaner (3 deps) and goal-driven. https://open-multi-agent.com/compare/langgraph/
- vs CrewAI — Python vs TypeScript. CrewAI is a mature, batteries-included framework of role-based crews (~30 dependencies); OMA is a lean TypeScript runtime (3 deps). Comparable orchestration surface; the choice is the language stack. https://open-multi-agent.com/compare/crewai/
- vs AutoGen — conversation-driven vs goal-driven. AutoGen models work as a group chat over an actor runtime, with native OpenTelemetry; it is now in maintenance mode, superseded by the Microsoft Agent Framework. OMA is actively developed and TypeScript-native. https://open-multi-agent.com/compare/autogen/
- vs the OpenAI Agents SDK — handoffs vs decomposition. The Agents SDK is lightweight with best-in-class built-in tracing, strongest when you build on OpenAI; OMA is provider-neutral and decomposes a goal into a task DAG. https://open-multi-agent.com/compare/openai-agents-sdk/
- vs Mastra — lean core vs batteries-included. Mastra bundles agents + graph-based workflows + memory + RAG + evals (~32 core deps, built on the Vercel AI SDK); OMA keeps a 3-dep goal-driven core. https://open-multi-agent.com/compare/mastra/
- vs the Vercel AI SDK — different layers. The AI SDK is a lean, provider-neutral single-agent toolkit (3 deps, stopWhen); OMA is the multi-agent orchestration layer above it and can run on top of the AI SDK. https://open-multi-agent.com/compare/vercel-ai-sdk/
- vs VoltAgent — observability-first vs lean. VoltAgent bundles a full OpenTelemetry stack and supervisor/sub-agent networks (~44 core deps); OMA keeps a 3-dependency core and offers TraceStore plus an optional first-party OpenTelemetry adapter. https://open-multi-agent.com/compare/voltagent/
- vs Inngest AgentKit — deterministic routing vs runtime decomposition. AgentKit routes an agent network with state-based logic on Inngest (durable, replayable); OMA decomposes a goal into a task DAG at runtime with no orchestration service. https://open-multi-agent.com/compare/inngest-agentkit/
- vs LangChain — focused runtime vs broad ecosystem. LangChain is the framework + integration ecosystem (chains, AgentExecutor); its multi-agent orchestration is LangGraph. OMA is a lean, goal-driven, 3-dep TypeScript runtime. https://open-multi-agent.com/compare/langchain/
- vs LlamaIndex — orchestration-first vs retrieval-first. LlamaIndex centers on RAG over your data (~29 core deps) with agent workflows on top; OMA centers on orchestration and leaves retrieval to you. https://open-multi-agent.com/compare/llamaindex/
- vs Pydantic AI — different language + shape. Pydantic AI is type-safe, Python-native, with strong Logfire/OpenTelemetry and a token-usage limit (UsageLimits); OMA is TypeScript-native goal-driven orchestration whose maxTokenBudget applies across the whole DAG run. https://open-multi-agent.com/compare/pydantic-ai/
- vs Google ADK — code-first workflow agents vs runtime decomposition. ADK composes Sequential/Parallel/Loop agents (Gemini-first, ~24 deps incl. a web stack); OMA decomposes a goal at runtime, provider-neutral, 3 deps. https://open-multi-agent.com/compare/google-adk/
- vs Semantic Kernel — .NET/Azure vs Node/TypeScript. SK is Microsoft's C#-first enterprise SDK (converging with AutoGen into the Microsoft Agent Framework); OMA is a lean TypeScript-native goal-driven runtime. https://open-multi-agent.com/compare/semantic-kernel/

And, in context rather than head-to-head: Claude Code's dynamic workflows make the same runtime-planning bet in a different form factor — they run inside Claude Code, while OMA runs the goal-to-DAG idea in your own backend as an MIT library on any model. https://open-multi-agent.com/compare/claude-dynamic-workflows/

## Documentation

Getting started:
- Capabilities: https://open-multi-agent.com/capabilities/
- Introduction: https://open-multi-agent.com/getting-started/introduction/
- Quick Start: https://open-multi-agent.com/getting-started/quick-start/
- Three Ways to Run: https://open-multi-agent.com/getting-started/three-ways-to-run/

Guides:
- Orchestration Controls: https://open-multi-agent.com/guides/orchestration-controls/
- Control costs and budgets: https://open-multi-agent.com/guides/cost-budget-control/
- Production Checklist: https://open-multi-agent.com/guides/production-checklist/
- Architecture: https://open-multi-agent.com/architecture/

Reference:
- Execution routing: https://open-multi-agent.com/reference/execution-routing/
- Task scheduling and dispatch: https://open-multi-agent.com/reference/task-scheduling/
- Durable approval gates: https://open-multi-agent.com/reference/durable-approvals/
- Providers: https://open-multi-agent.com/reference/providers/
- Tool configuration: https://open-multi-agent.com/reference/tool-configuration/
- Structured input: https://open-multi-agent.com/reference/structured-input/
- Observability: https://open-multi-agent.com/reference/observability/
- Observability migration: https://open-multi-agent.com/reference/observability-migration/
- Observability performance: https://open-multi-agent.com/reference/observability-performance/
- Run event journal: https://open-multi-agent.com/reference/run-journal/
- Shared memory: https://open-multi-agent.com/reference/shared-memory/
- Checkpoint & resume: https://open-multi-agent.com/reference/checkpoint/
- Adaptive recovery: https://open-multi-agent.com/reference/adaptive-recovery/
- Plan preview & replay: https://open-multi-agent.com/reference/plan-replay/
- Context management: https://open-multi-agent.com/reference/context-management/
- Consensus: https://open-multi-agent.com/reference/consensus/
- Model routing: https://open-multi-agent.com/reference/model-routing/
- External agents: https://open-multi-agent.com/reference/external-agents/
- Evaluation: https://open-multi-agent.com/reference/evaluation/
- Egress policy: https://open-multi-agent.com/reference/egress-policy/
- CLI: https://open-multi-agent.com/reference/cli/

## Blog

- Open Multi-Agent v1.14 — Repair the Plan, Keep the Record: https://open-multi-agent.com/blog/v1-14-adaptive-recovery-hybrid-routing/
- Best TypeScript Multi-Agent Frameworks in 2026 — Choose by Workflow: https://open-multi-agent.com/blog/best-typescript-multi-agent-frameworks-2026/
- Competitive Monitoring — Isolate Each Source Before Comparing Them: https://open-multi-agent.com/blog/competitive-monitoring-contradiction-detection/
- Support Tickets — A Fixed Pipeline and a Routed Agent Team: https://open-multi-agent.com/blog/customer-support-routing-playbook/
- Incident Postmortems — Parallel Investigation, Serial Judgment: https://open-multi-agent.com/blog/incident-postmortem-parallel-investigation/
- Five Seams That Decide Whether a Workflow Needs a Team: https://open-multi-agent.com/blog/multi-agent-application-patterns-field-note/
- Translation Drift — Route the Back-Translation to Another Model: https://open-multi-agent.com/blog/translation-quality-cross-model-review/
- Open Multi-Agent v1.13 — Route, Govern, Schedule, and Prove the Run: https://open-multi-agent.com/blog/v1-13-execution-routing-governance-scheduling/
- Open Multi-Agent v1.12.1 — Evaluation, Offline Inspection, and a No-Key First Run: https://open-multi-agent.com/blog/v1-12-1-evaluation-zero-key/
- A 100% Local Multi-Agent Team in TypeScript (Ollama + Gemma, $0 API Cost): https://open-multi-agent.com/blog/local-multi-agent-team-ollama-gemma/
- From Transcript to Typed Action Items: Three Parallel Agents in TypeScript: https://open-multi-agent.com/blog/meeting-summarizer-parallel-agents/
- Goal In, DAG Out: How Open-Multi-Agent Turns a Goal into a Task DAG: https://open-multi-agent.com/blog/goal-to-task-dag-coordinator/
- Give Your TypeScript AI Agents Long-Term Memory with TencentDB-Agent-Memory: https://open-multi-agent.com/blog/agent-long-term-memory-tencentdb/
- Goal-Driven Agent Orchestration vs Explicit Graphs — A TypeScript Framework Taxonomy: https://open-multi-agent.com/blog/goal-driven-vs-explicit-graphs/
- 5 walls multi-agent frameworks hit (Mastra .network() → Supervisor receipts): https://open-multi-agent.com/blog/multi-agent-framework-walls/
- How to Run a Mixed-Model AI Agent Team in TypeScript: https://open-multi-agent.com/blog/mixed-model-agent-team/
- Adding Multi-Agent Orchestration to a Vercel AI SDK App: https://open-multi-agent.com/blog/multi-agent-vercel-ai-sdk/

## Changelog

The complete release history, newest first, with additions, breaking changes,
published package versions, and upgrade notes for every version back to v1.0.0:
https://open-multi-agent.com/changelog/ (per-release anchors follow the version,
e.g. https://open-multi-agent.com/changelog/#v1-14-0). It mirrors the GitHub
releases at https://github.com/open-multi-agent/open-multi-agent/releases.

## Mentioned

"A brilliant TypeScript-native multi-agent orchestration framework."
— GithubAwesome, GitHub Trending Monthly #6.

## Project links

- GitHub: https://github.com/open-multi-agent/open-multi-agent
- npm: https://www.npmjs.com/package/@open-multi-agent/core
- Examples by goal: https://open-multi-agent.com/examples/
- Solutions: https://open-multi-agent.com/solutions/
- Integrations: https://open-multi-agent.com/integrations/
- Showcase: https://open-multi-agent.com/showcase/
- Compare: https://open-multi-agent.com/compare/
- Changelog: https://open-multi-agent.com/changelog/
- Contact: https://open-multi-agent.com/contact/ (bugs and usage questions go to GitHub issues/discussions; security reports and commercial work go to email)
- License: MIT