TypeScript Multi-Agent Orchestration: Building Task DAGs with open-multi-agent

The bottom line: open-multi-agent is a TypeScript-native multi-agent orchestration framework that takes a goal, decomposes it into a task DAG via a single LLM call, and parallelizes execution across any provider — Claude, ChatGPT, Gemini, DeepSeek, or local models. Three runtime dependencies, one runTeam() call, and you’re orchestrating agents at scale.

Why Task DAGs for Multi-Agent Orchestration?

Most multi-agent frameworks use one of three coordination patterns: sequential chains, routing topologies, or DAG-based decomposition. Sequential chains are simple but waste parallelism. Routing topologies (like LangGraph’s state machines) are expressive but require manually defining every edge.

Task DAGs occupy a sweet spot. A coordinator agent analyzes a goal and produces a dependency graph where independent tasks can run in parallel and dependent tasks block on their prerequisites. The result is automatic parallelism without manual graph construction.

The 2026 production landscape [1] shows DAG-based orchestration becoming the default for multi-agent workloads — frameworks like LangGraph, Mastra, and now open-multi-agent all converge on DAG topologies.

Architecture Overview

open-multi-agent’s architecture is deliberately minimal. Three runtime dependencies, two core primitives:

The Primitive: runTeam()

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

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

const result = await orchestrator.runTeam({
  goal: 'Build a CLI tool that analyzes npm package dependencies, detects security vulnerabilities, and generates a markdown report',
  maxParallel: 5,
});

That single call triggers the full pipeline: goal decomposition → task DAG construction → parallel execution → result synthesis.

How Decomposition Works

The coordinator receives the goal and produces a task DAG in one LLM call. Each task node specifies:

• Name — what to build or analyze
• Model — which LLM to use (override the default)
• Tools — available tool set for this task
• Dependencies — task IDs that must complete first
• Output format — structured schema for the deliverable

// The coordinator internally produces something like:
const dag = {
  tasks: [
    { id: 't1', name: 'analyze-dependencies', model: 'claude-sonnet-4-6',
      tools: ['bash', 'file_read'], dependsOn: [] },
    { id: 't2', name: 'vuln-scan', model: 'gpt-4o',
      tools: ['bash', 'web_search'], dependsOn: ['t1'] },
    { id: 't3', name: 'generate-report', model: 'gemini-2.5-pro',
      tools: ['file_write'], dependsOn: ['t1', 't2'] },
  ]
};

Tasks without dependencies (t1) execute immediately in parallel. Tasks that depend on others (t2, t3) wait for their prerequisites.

Multi-Provider Strategy

A key differentiator is per-task model assignment. You’re not locked into one provider. The security scan task might use GPT-4o for its superior tool-calling, while the report generation uses Gemini 2.5 Pro for its long-context window.

const orchestrator = new OpenMultiAgent({
  defaultModel: 'claude-sonnet-4-6',
  providers: {
    openai: { apiKey: process.env.OPENAI_API_KEY },
    anthropic: { apiKey: process.env.ANTHROPIC_API_KEY },
    google: { apiKey: process.env.GEMINI_API_KEY },
    deepseek: { apiKey: process.env.DEEPSEEK_API_KEY },
    local: { baseUrl: 'http://localhost:11434/v1' },
  }
});

This multi-provider approach aligns with the 2026 trend of polyglot agent systems [2] where teams pick the best model for each subtask rather than routing everything through one provider.

Comparison with Existing Frameworks

The multi-agent framework space has consolidated around a few dominant patterns in 2026 [3]:

Framework	Approach	Language	DAG Native	Multi-Provider
open-multi-agent	Goal → DAG decomposition	TypeScript	Yes (automatic)	Yes
LangGraph	State machine graph	Python/TS	Semi (manual edges)	Via adapters
Mastra	Workflow-based orchestration	TypeScript	Semi (agent workflows)	Yes
CrewAI	Role-based delegation	Python	No (sequential/routing)	Via providers
OpenAI Agents SDK	Hierarchical delegation	Python/TS	No	OpenAI only

The critical difference: open-multi-agent produces the DAG automatically from a single goal description. LangGraph and Mastra require you to define the graph topology yourself. For complex multi-step workflows, this is a significant ergonomic advantage.

MCP Integration

open-multi-agent supports the Model Context Protocol (MCP) for tool discovery and execution [4]. This means any MCP-compatible server can be attached as a tool source:

const orchestrator = new OpenMultiAgent({
  defaultModel: 'claude-sonnet-4-6',
  mcpServers: [
    { name: 'filesystem', command: 'npx', args: ['@modelcontextprotocol/server-filesystem', '/tmp'] },
    { name: 'github', command: 'npx', args: ['@modelcontextprotocol/server-github'] },
    { name: 'postgres', command: 'npx', args: ['@modelcontextprotocol/server-postgres'] },
  ]
});

MCP integration means the agent team can interact with databases, file systems, version control, and APIs through a standardized interface — no custom tool wiring needed.

Live Tracing

Every runTeam() execution produces a trace that can be visualized in the built-in tracing UI:

npm run trace --session-id <session-id>

The trace shows the full DAG with timing, token usage per task, and inter-task data flow. This is invaluable for debugging orchestrations where one slow task blocks the entire pipeline.

When to Use open-multi-agent

• You need automatic parallelism. Manual graph construction is tedious and error-prone. open-multi-agent’s coordinator handles it in one LLM call.

• You want multi-provider by default. Per-task model assignment isn’t bolted on — it’s the design. Use Claude for reasoning, Gemini for context, GPT-4o for tool use.

• You’re in the TypeScript ecosystem. Three runtime dependencies. No Rust compilation, no Python virtualenvs. npm install and go.

• You want MCP-native tools. If you’ve already built MCP servers, they plug in without adapters.

Current Limitations

• Single coordinator as bottleneck. The coordinator produces the DAG in one LLM call. For very complex goals, that call can be slow or produce suboptimal decompositions. Hierarchical decomposition (nested coordinators) is on the roadmap.

• No persistent state. The framework is stateless — every runTeam() starts fresh. For long-running agent systems that need memory across invocations, you’d need to wrap it with an external knowledge store.

• Young ecosystem. As of June 2026, the project has been public for roughly two months. The plugin ecosystem and community tooling are thin compared to LangChain’s.

Build Log: What I Built

I used open-multi-agent to build a code analysis pipeline that:

1. Discovers all TypeScript packages in a monorepo (task t1)
2. Analyzes dependency graphs for each package (t2–tN, parallel)
3. Scans for known vulnerable versions (tN+1–tN+M, parallel)
4. Generates a consolidated markdown report (t-final)

The coordinator decomposed the goal into 12 tasks across 3 layers. Total LLM calls: 1 for decomposition + 12 task executions. Without parallelism that would be 13 sequential calls; with open-multi-agent’s DAG, the depth was only 3 layers, giving a ~4x speedup.

The entire build — from npm install to working pipeline — took about 2 hours. Most of that was writing the tool implementations; the orchestration logic was handled by the framework.

Key Takeaways

1. DAG decomposition is the right abstraction for multi-agent work — it automatically discovers parallelism without manual graph construction.

2. Multi-provider isn’t a luxury, it’s a necessity — different models excel at different subtasks. open-multi-agent’s per-task model assignment reflects real production needs.

3. Three-dependency frameworks win — the “just works” factor of a minimal dependency tree can’t be overstated. No build-time code generation, no heavy runtime.

4. MCP integration is becoming table stakes — by mid-2026, any serious agent framework must support MCP for tool discovery. open-multi-agent’s first-class MCP support is a strong differentiator.

→ Try it yourself. npm install @jackchen_me/open-multi-agent and write your first runTeam() call in under 60 seconds. The GitHub repo [5] has examples for code generation, research synthesis, and data pipeline orchestration.

---

References

[1] Multi-Agent in Production in 2026: What Actually Survived — A field guide to agent orchestration patterns that made it to production. https://medium.com/@Micheal-Lanham/multi-agent-in-production-in-2026-what-actually-survived-f86de8bb1cd1

[2] Agent Orchestration 101: Making Multiple AI Agents Work as One — Lyzr’s 2026 enterprise guide to the 5 orchestration patterns. https://www.lyzr.ai/blog/agent-orchestration/

[3] 7 Multi-Agent Orchestration Platforms: Build vs Buy in 2026 — Augment Code’s comparison of orchestration platforms including architecture, pricing, and deployment models. https://www.augmentcode.com/tools/multi-agent-orchestration-platforms-build-vs-buy

[4] Model Context Protocol (MCP) — Standard protocol for connecting AI agents to tools and data sources. https://modelcontextprotocol.io/

[5] open-multi-agent on GitHub — TypeScript multi-agent orchestration framework. Three runtime dependencies, one runTeam() call. https://github.com/open-multi-agent/open-multi-agent

---

Related Reads

• TypeScript Discriminated Unions: Exhaustive Pattern Matching — CodeIntel
• TypeScript Error Handling: 4 Patterns Tested Against Production Failures — CodeIntel
• Build Log: Multi-Agent Research Pipeline with OpenClaw — ToolBrain
• Hermes Agent Multi-Agent Setup Guide 2026: Run Specialized AI Agents — ToolBrain

← Back to all posts