open-multi-agent: TypeScript-Native Multi-Agent Orchestration From Goal to Task DAG

The bottom line: open-multi-agent is a TypeScript-native framework that converts a single goal into an executable task DAG with three runtime dependencies. One runTeam(team, goal) call triggers a coordinator agent that decomposes the goal, schedules independent tasks in parallel, and synthesizes results. 6.3k GitHub stars, v1.5.0 as of May 30, 2026, with MCP support, mixed-provider teams, and post-run HTML trace dashboards.


The Core Idea: Goals, Not Graphs

Most multi-agent orchestration tools make you draw the graph. LangGraph [1] compiles a declarative graph (nodes, edges, conditional routing) that you define upfront. CrewAI [2] uses sequential/parallel task chains you wire together. Open-multi-agent flips this: you provide a team of agents and a goal, and a coordinator agent dynamically decomposes the goal into a task DAG at runtime [3].

The difference is fundamental. With LangGraph you describe how agents should collaborate. With open-multi-agent you describe what you want and the coordinator figures out the collaboration structure.

Goal → Coordinator → Task DAG → Parallel execution → Synthesized result

This is closer to how production teams work. A project lead decomposes a specification into tasks, identifies dependencies, parallelizes independent work, and integrates the output. The coordinator is that lead, implemented as an LLM agent with system prompt awareness of the agent roster and their capabilities.


Three Execution Modes

Open-multi-agent exposes three modes, each solving a different orchestration problem.

Single Agent: runAgent()

The simplest mode — one agent, one prompt. Useful for isolated tasks where you don’t need team collaboration.

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

const orchestrator = new OpenMultiAgent({
  defaultModel: 'claude-sonnet-4-6',
})

const result = await orchestrator.runAgent({
  name: 'researcher',
  model: 'claude-sonnet-4-6',
  systemPrompt: 'Research and summarize technical topics.',
  tools: ['bash', 'file_write'],
}, 'Research the current state of WebGPU adoption and write a summary to /tmp/webgpu.md')

No team setup. No DAG construction. Just an agent and a task.

Auto-Orchestrated Team: runTeam()

This is the headline feature. Declare a team with multiple agents, each with a role, model, and toolset. The coordinator decomposes the goal into a task DAG, assigns tasks to the best-suited agent, parallelizes where possible, and produces a final result [3].

import { OpenMultiAgent, type AgentConfig } from '@open-multi-agent/core'

const agents: AgentConfig[] = [
  {
    name: 'architect',
    model: 'claude-sonnet-4-6',
    systemPrompt: 'Design clean API contracts with OpenAPI specs.',
    tools: ['file_write'],
  },
  {
    name: 'developer',
    model: 'claude-sonnet-4-6',
    systemPrompt: 'Implement runnable TypeScript from spec documents.',
    tools: ['bash', 'file_read', 'file_write', 'file_edit'],
  },
  {
    name: 'reviewer',
    model: 'claude-sonnet-4-6',
    systemPrompt: 'Review code for correctness, security, and style violations.',
    tools: ['file_read', 'grep'],
  },
]

const orchestrator = new OpenMultiAgent({
  defaultModel: 'claude-sonnet-4-6',
  onProgress: (event) => console.log(event.type, event.task ?? event.agent ?? ''),
})

const team = orchestrator.createTeam('api-team', {
  name: 'api-team',
  agents,
  sharedMemory: true,
})

const result = await orchestrator.runTeam(
  team,
  `Create a REST API for a todo list in ${process.cwd()}/.agent-workspace/todo-api/`
)

console.log(result.success, result.totalTokenUsage.output_tokens)

The coordinator’s output reveals the DAG structure at runtime:

agent_start coordinator
task_start design-api
task_complete design-api
task_start implement-handlers
task_start scaffold-tests         // independent tasks run in parallel
task_complete scaffold-tests
task_complete implement-handlers
task_start review-code            // unblocked after implementation
task_complete review-code
agent_complete coordinator
Success: true
Tokens: 12847 output tokens

The design-api task completes before implement-handlers and scaffold-tests start — a clear dependency edge. scaffold-tests and implement-handlers run in parallel because they share no transitive dependency. review-code waits for the implementation to finish.

Explicit Task Pipeline: runTasks()

When you need precise control over the task graph, skip the coordinator and define assignments directly.

const result = await orchestrator.runTasks(team, [
  {
    title: 'Design the data model',
    description: 'Write a TypeScript interface spec to /tmp/spec.md',
    assignee: 'architect',
  },
  {
    title: 'Implement the module',
    description: 'Read /tmp/spec.md and implement the module in /tmp/src/',
    assignee: 'developer',
    dependsOn: ['Design the data model'],
  },
  {
    title: 'Write tests',
    description: 'Read the implementation and write Vitest tests.',
    assignee: 'developer',
    dependsOn: ['Implement the module'],
  },
  {
    title: 'Review code',
    description: 'Review /tmp/src/ and produce a structured code review.',
    assignee: 'reviewer',
    dependsOn: ['Implement the module'], // parallel with Write tests
  },
])

This is comparable to LangGraph’s compiled graph approach but with a simpler API — titles replace node IDs, dependsOn replaces edges, and the framework handles scheduling.


Scheduling Strategies

The coordinator uses one of four scheduling strategies when auto-assigning unassigned tasks [3]:

Strategy Behavior
dependency-first Deepest dependency chain gets priority
round-robin Tasks distributed evenly across available agents
least-busy Agent with fewest queued tasks gets the next task
capability-match Task description matched against agent system prompts

capability-match is the most sophisticated — it semantically compares task descriptions against agent system prompts and tool sets, routing data modeling tasks to the architect agent and implementation tasks to the developer.


Mixed-Provider Teams

Teams aren’t locked to a single provider. You can mix Anthropic, OpenAI, Gemini, Groq, and local models (Ollama, vLLM, LM Studio) in the same team [3].

const agents: AgentConfig[] = [
  {
    name: 'strategist',
    model: 'claude-opus-4-6',
    provider: 'anthropic',
    systemPrompt: 'Plan high-level approaches and decompose problems.',
    tools: ['file_write'],
  },
  {
    name: 'implementer',
    model: 'gpt-5.4',
    provider: 'openai',
    systemPrompt: 'Implement plans as working code.',
    tools: ['bash', 'file_read', 'file_write'],
  },
  {
    name: 'local-validator',
    model: 'llama-4',
    provider: 'ollama',
    systemPrompt: 'Validate output against project conventions.',
    tools: ['file_read', 'grep'],
  },
]

The framework normalizes tool calls, streaming, and thinking/reasoning across providers. The thinking config maps to Anthropic extended thinking, Gemini thinkingConfig, and OpenAI reasoning_effort — all through a single unified interface.


MCP Integration

Open-multi-agent supports standard MCP servers via connectMCPTools() [3]. This means any tool exposed through the Model Context Protocol — databases, APIs, vector stores, browser automation — is available to any agent in the team.

import { connectMCPTools } from '@open-multi-agent/core/mcp'

const mcpTools = await connectMCPTools({
  command: 'npx',
  args: ['-y', '@modelcontextprotocol/server-postgres', '--connection-string', process.env.DATABASE_URL],
})

const agent: AgentConfig = {
  name: 'data-analyst',
  model: 'claude-sonnet-4-6',
  systemPrompt: 'Query and analyze data from PostgreSQL.',
  tools: [...mcpTools],
}

The CA-MCP paper [4] proposes a shared context store for MCP servers that reduces LLM calls by 60% and execution time by 67.8% compared to traditional central-LLM orchestration. Open-multi-agent’s shared memory interface (default in-process KV, swappable with Redis or Postgres) aligns with this architecture — agents can coordinate through persistent memory rather than passing messages through the LLM.


Human-in-the-Loop: Approval Gates

A production build log about AI orchestration is incomplete without discussing human oversight. Open-multi-agent provides three hooks [3]:

  • onPlanReady — Approve or reject the coordinator’s DAG before any agent executes a task
  • onApproval — Between task rounds, approve the next batch of parallel tasks
  • planOnly: true — Preview the plan without executing
const result = await orchestrator.runTeam(team, goal, {
  onPlanReady: (plan) => {
    console.log(`Plan: ${plan.tasks.length} tasks across ${plan.agents.length} agents`)
    return prompt('Approve? (y/n)') === 'y'
  },
})

This is critical for production workflows. The HN discussion about multi-agent orchestration [5] highlights that confidence calibration — knowing when to stop automated execution and surface ambiguity for human review — is the hardest problem to get right.


Observability and Traces

Post-run, open-multi-agent generates an HTML dashboard showing the executed task DAG with spans, token usage, and agent activity [3]. API keys and bearer tokens are automatically redacted from traces, bash output, and the dashboard.

The tracing system fires onProgress events and onTrace spans during execution, which can be piped into external observability systems:

const orchestrator = new OpenMultiAgent({
  defaultModel: 'claude-sonnet-4-6',
  onTrace: (span) => {
    console.log(`[TRACE] ${span.name}: ${span.duration}ms, ${span.tokenUsage?.total ?? 0} tokens`)
  },
})

For comparison, the production patterns survey [5] found most teams built their own observability — logging every run with input, output, token usage, and latency. Open-multi-agent’s built-in tracing and dashboard reduce the custom instrumentation burden.


Production Usage: temoda

Open-multi-agent is explicitly deployed in production at temoda, a task management platform [3]. It’s been running as the orchestration backend, handling multi-agent Slack workflows and automated code generation pipelines.

The v1.5.0 release (May 30, 2026) features a CLI binary (oma) for shell and CI use [3]. This enables non-interactive multi-agent pipelines in GitHub Actions, cron jobs, or serverless environments without a TypeScript runtime:

oma run --team team.json --goal "Convert all markdown files in docs/ to PDF with consistent styling"

How It Compares

Aspect open-multi-agent LangGraph CrewAI
Graph definition Auto-generated by coordinator Declared in code Task chains
Runtime TypeScript Python Python
Team providers 12+ (Anthropic, OpenAI, Gemini, local) LangChain ecosystem OpenAI, Anthropic
MCP support Native (connectMCPTools) Via LangChain Manual
Human-in-loop onPlanReady, onApproval, planOnly interrupt nodes Manual callback
Dependencies 3 runtime deps Heavy (LangChain ecosystem) Moderate
HTML dashboard Built-in Via LangSmith External
CLI Yes (oma) No No
Stars 6.3k 120k+ 15k+
License MIT MIT MIT

Getting Started

npm install @open-multi-agent/core

Migrating from the deprecated @jackchen_me/open-multi-agent? The package moved to @open-multi-agent/core in v1.5.0.

Node.js >= 18 required. Full examples in the repo’s examples/ directory [3].



References

[1] LangGraph documentation — https://langchain-ai.github.io/langgraph/

[2] CrewAI framework — https://github.com/crewAIInc/crewAI

[3] open-multi-agent repository — https://github.com/open-multi-agent/open-multi-agent

[4] CA-MCP: Context-Aware MCP with Shared Context Store — https://arxiv.org/abs/2601.11595

[5] Ask HN: How are you orchestrating multi-agent AI workflows in production? — https://news.ycombinator.com/item?id=47660705

[6] Anthropic MCP: Code execution with MCP — https://www.anthropic.com/engineering/code-execution-with-mcp

  • Hermes Tutorials — Hermes Agent setup, configuration, and advanced workflows
  • ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from NiteAgent.

← Back to all posts