Dynamic and explicit orchestration
runTeam() builds a task DAG from a goal. runTasks() runs a graph you define, and runAgent() covers the single-agent case.
LlamaIndex started as a data/RAG framework and grew agent workflows on top; open-multi-agent starts from orchestration. If your problem is retrieval over your data, they lead from opposite ends.
Your core problem is RAG over your own data; indexing, retrieval, query engines; and you want agents that build on that, in Python.
Your core problem is coordinating several agents, dependencies, approvals, and recovery steps in TypeScript. You can connect the retrieval layer you already use.
| Dimension | open-multi-agent | LlamaIndex |
|---|---|---|
| Language / runtime | TypeScript-native; embeds in any Node.js 18+ backend | Python; a TypeScript port (LlamaIndex.TS) also exists |
| Orchestration model | Three modes: one agent, an explicit task DAG, or a goal decomposed by the coordinator at runtime | Data / RAG-first (indexing, retrieval, query engines) plus agent workflows (AgentWorkflow, FunctionAgent) |
| Runtime dependencies | 3 direct (Anthropic SDK, OpenAI SDK, Zod); extra providers and MCP are opt-in peers | ~29 direct in llama-index-core (RAG-oriented: numpy, nltk, tiktoken, networkx, …) |
| Mixed-model teams | Yes; each agent can use its own cloud or local model in one team | Yes; per-agent model |
| Run-budget control | Token and estimated-USD ceilings through maxTokenBudget, or maxCostBudget with your estimateCost price table | No hard token cap |
| Observability | TraceRecord v2 + TraceStore, an optional first-party OTel adapter, and an offline post-run Run Viewer | An instrumentation module plus integrations (Arize, Langfuse, and others) |
OMA is more than goal decomposition and a small dependency count. These are current framework capabilities documented in the project README.
runTeam() builds a task DAG from a goal. runTasks() runs a graph you define, and runAgent() covers the single-agent case.
Inspect and approve plans, freeze and replay them as data, validate outputs with Zod, stream per agent, cancel runs, or add a proposer and judge consensus loop.
The scheduler runs independent branches in parallel. Retries and checkpoints let an interrupted run resume without repeating completed tasks.
Bound work with turn, token, estimated-cost, timeout, context, and loop controls. Tools are default-deny, and trace payloads redact secrets by default.
Run in your Node.js backend, locally, offline, or air-gapped. Mix cloud and local models, connect MCP tools, and bring external agents through ACP or process backends.
Stable run identity, TraceStore, and the offline DAG and Waterfall Viewer work without a hosted service. An optional OTel adapter and EvalSets connect runs to production telemetry and CI gates.
LlamaIndex is retrieval-first: its center of gravity is indexing your data and querying it, with agent workflows layered on top. open-multi-agent is orchestration-first: it decomposes a goal into a task DAG and coordinates agents, and leaves retrieval to you. They overlap only at the edges; a RAG-heavy application leans toward LlamaIndex; a multi-agent coordination problem leans toward OMA. LlamaIndex carries ~29 core dependencies for all that data tooling; OMA carries three.
LlamaIndex fits when retrieval over your own data is the main problem and you want its loaders, indexes, retrievers, query engines, and agent workflows in the same stack.
LlamaIndex on GitHub↗open-multi-agent fits when orchestration is the heart of the problem: a coordinator that decomposes a goal into a parallel task DAG, TypeScript-native, three dependencies, and a hard maxTokenBudget. It doesn’t ship retrieval; you bring whatever RAG or tools you like; which keeps the core small and the orchestration general.
open-multi-agent is MIT-licensed and free to run yourself. When you need it delivered, integrated, or supported on a deadline, 元定义科技 (YuanASI) offers commercial delivery and support.