{"slug": "goal-in-dag-out-how-open-multi-agent-turns-a-goal-into-a-task-dag", "title": "Goal In, DAG Out: How Open-Multi-Agent Turns a Goal into a Task DAG", "summary": "Open-multi-agent, a TypeScript framework, introduces a coordinator agent that automatically decomposes a user's goal into a task DAG, assigns tasks to team agents, runs independent tasks in parallel, and synthesizes the final result. This eliminates the need for manual graph wiring, as demonstrated by a research and writing example using DeepSeek models.", "body_md": "Most TypeScript agent frameworks make you draw the graph yourself. You declare the nodes, wire the edges, decide what runs after what, where it branches, where it joins. It works, right up until the goal shifts and you are back in the graph editor re-wiring a pipeline you already built once.\n\nThere is another way to model this: describe the goal, and let a coordinator build the graph for you.\n\nThat is what `runTeam()`\n\ndoes in open-multi-agent. You hand it a team and a sentence. It hands back a result. In between, a coordinator agent decomposes the goal into a task DAG, assigns the tasks to your agents, runs the independent ones in parallel, and synthesizes the final answer. There are no edges to wire.\n\nThis post is about what happens in that \"in between,\" because the mechanism is the whole point.\n\n``` js\nimport { OpenMultiAgent } from '@open-multi-agent/core'\n\nconst orchestrator = new OpenMultiAgent({\n  defaultModel: 'deepseek-v4-flash',\n  defaultProvider: 'deepseek',\n})\n\nconst team = orchestrator.createTeam('research', {\n  name: 'research',\n  agents: [\n    { name: 'researcher', model: 'deepseek-v4-flash', provider: 'deepseek',\n      systemPrompt: 'You research topics and gather concrete facts.' },\n    { name: 'writer', model: 'deepseek-v4-flash', provider: 'deepseek',\n      systemPrompt: 'You turn research notes into clear prose.' },\n  ],\n  sharedMemory: true,\n})\n\nconst result = await orchestrator.runTeam(\n  team,\n  'Research the tradeoffs of TypeScript decorators, covering the stage-3 standard ' +\n  'versus the legacy experimental implementation, runtime and bundle-size cost, and ' +\n  'current framework support, then write a clear 500-word explainer for a team ' +\n  'deciding whether to adopt them.',\n)\n\nconsole.log(result.agentResults.get('coordinator')?.output)\n```\n\nThree things to notice before we go under the hood:\n\n`model`\n\n. The orchestrator's `defaultModel`\n\nis used by the coordinator; worker agents carry their own. (Swap `deepseek`\n\nfor any supported provider: Anthropic, OpenAI, Gemini, a local model, and so on.)Run this and the framework does seven things. Here they are, in order.\n\n`runTeam()`\n\nspins up a temporary agent called `coordinator`\n\n. It is not part of your roster. The framework creates it for this run and discards it afterward. It receives your goal, the names of your agents, and one instruction:\n\nDecompose the following goal into tasks for your team (researcher, writer). Return ONLY the JSON task array in a\n\n`json`\n\ncode fence.\n\nThe coordinator answers with a JSON array of task specs. Here is a real decomposition from the run above:\n\n```\n[\n  { \"title\": \"Research stage-3 vs legacy experimental decorators\",\n    \"description\": \"Gather the syntax and behavioral differences ...\",\n    \"assignee\": \"researcher\", \"dependsOn\": [] },\n  { \"title\": \"Research runtime and bundle-size cost of decorators\",\n    \"description\": \"Investigate helper code, tree-shaking, benchmarks ...\",\n    \"assignee\": \"researcher\", \"dependsOn\": [] },\n  { \"title\": \"Research current framework support for decorators\",\n    \"description\": \"Survey Angular, NestJS, TypeORM, MobX ...\",\n    \"assignee\": \"researcher\", \"dependsOn\": [] },\n  { \"title\": \"Write 500-word explainer on decorator tradeoffs\",\n    \"description\": \"Using the three research outputs, write the explainer ...\",\n    \"assignee\": \"writer\",\n    \"dependsOn\": [\n      \"Research stage-3 vs legacy experimental decorators\",\n      \"Research runtime and bundle-size cost of decorators\",\n      \"Research current framework support for decorators\"\n    ] }\n]\n```\n\nEach task carries a `title`\n\n, a `description`\n\n(the actual instruction the assigned agent will receive), an `assignee`\n\n, and `dependsOn`\n\n, a list of task titles it must wait for. That last field is the DAG, expressed as data instead of as wiring. Notice the coordinator chose to split the research into three independent tasks and make the write task depend on all three. The exact split varies between runs, because the coordinator is an LLM; this was one real plan.\n\nThis step costs one extra LLM call. The coordinator runs with a `maxTurns`\n\nof 3 by default. Keep that overhead in mind; we come back to it at the end.\n\nThe specs load into a `TaskQueue`\n\n. The title-based `dependsOn`\n\nreferences resolve to real task IDs, so the queue knows the true shape of the graph. A task becomes \"ready\" only once every task it depends on has completed. Tasks with no dependencies are ready immediately.\n\nIf the coordinator fails to return usable JSON, the run does not crash. The framework falls back to one task per agent, each handed the original goal as its description. You get a degraded run, not an exception.\n\nThe coordinator usually fills in `assignee`\n\n, but it does not have to. Any task left unassigned is handed to the `Scheduler`\n\n, which assigns it to an agent. The default strategy is `dependency-first`\n\n; you can also pick `round-robin`\n\n, `least-busy`\n\n, or `capability-match`\n\n, which scores each agent's name and system prompt against the task.\n\nTasks run through an `AgentPool`\n\n. Independent tasks (nothing pending in their `dependsOn`\n\n) run concurrently, up to `maxConcurrency`\n\n, which defaults to 5. Dependents wait until their inputs are done, then become ready and dispatch. In the real run above, the three research tasks had no dependencies, so they all started in the same instant and ran together; the write task waited until all three finished. You did not schedule any of that. The graph shape decides what can overlap, and the pool runs as much of it in parallel as the limit allows.\n\nAfter each task completes, its output is written to the team's shared memory. That is how the `writer`\n\nsees the `researcher`\n\n's findings: by the time the write task is ready, the three research results are already in memory. Agents communicate through this shared store rather than by you threading outputs from one call into the next.\n\nOnce the queue drains, the coordinator runs a second time. This pass reads every task output and writes the final answer to the goal. This is the result you read from `agentResults.get('coordinator')`\n\n.\n\nWant to inspect the plan itself rather than the final prose? The task records are on the result as `result.tasks`\n\n(each with `title`\n\n, `assignee`\n\n, `status`\n\n, and `dependsOn`\n\n), and you can get just the plan without executing anything by calling `runTeam(team, goal, { planOnly: true })`\n\n.\n\n`runTeam()`\n\nresolves to a `TeamRunResult`\n\n: an `agentResults`\n\nmap keyed by agent name (here `coordinator`\n\n, `researcher`\n\n, `writer`\n\n), a `totalTokenUsage`\n\nfigure, and the `tasks`\n\nrecord list with statuses and metrics. Everything that happened is inspectable after the fact.\n\nHere is the actual output, running the code above against DeepSeek (`deepseek-v4-flash`\n\n):\n\nThe coordinator decomposed the goal into three parallel research tasks and one dependent write task, ran the research concurrently, persisted each result, and synthesized the final explainer. `runTeam()`\n\nfinished `success=true`\n\n; the explicit `runTasks()`\n\nversion below ran the same way.\n\nFailures do not cascade past their own dependents. A failed task is marked `failed`\n\n, and any task that depends on it stays `blocked`\n\n. Every task that does not depend on the failure keeps running to completion. You end the run with partial results plus a clear record of which branch broke, instead of one error tearing down the whole graph.\n\nGoal-first is not a silver bullet, and the framework is explicit about that.\n\n**Simple goals skip the coordinator entirely.** If the goal is short (200 characters or fewer) and contains no coordination directives, `runTeam()`\n\nshort-circuits: it picks the best-matching agent and runs it directly, with no decomposition and no synthesis pass. There is no reason to pay for two extra LLM calls to \"Summarize this paragraph.\" (This is exactly why the quickstart goal above is spelled out in detail: a one-liner would have been routed straight to a single agent.)\n\n**When you need determinism, write the graph yourself.** The coordinator is an LLM, so its decomposition can vary run to run (the example above produced three research tasks on one run and a single research task on another). If you need the exact same pipeline every time (CI, regulated workflows, anything you have to reason about precisely), use `runTasks()`\n\nand supply the DAG directly:\n\n``` js\nconst result = await orchestrator.runTasks(team, [\n  {\n    title: 'Research decorator tradeoffs',\n    description: 'Gather concrete pros and cons of TypeScript decorators.',\n    assignee: 'researcher',\n  },\n  {\n    title: 'Write the explainer',\n    description: 'Using the research notes, write a 500-word explainer.',\n    assignee: 'writer',\n    dependsOn: ['Research decorator tradeoffs'],\n  },\n])\n```\n\nSame queue, same scheduler, same parallel execution. You just own the graph instead of asking for one. (You can also pin a coordinator-generated plan and replay it deterministically, but that is a separate post.)\n\nSo the tradeoff is concrete:\n\n`runTeam()`\n\nis goal-first: flexible, two extra LLM calls of planning overhead, a plan that can change between runs.`runTasks()`\n\nis graph-first: deterministic and cheaper per run, but you maintain the graph.This is the distinction that actually matters when you choose a framework. Graph-first tools (you wire the nodes) trade maintenance for control and determinism. Goal-first (you describe the outcome) trades an extra planning pass and a non-deterministic plan for flexibility. open-multi-agent ships both behind one API, so you can start goal-first and drop to an explicit graph on the paths that have to be locked down. I wrote more about that split in [Goal-Driven Agent Orchestration vs Explicit Graphs](https://dev.to/jackchenme/goal-driven-agent-orchestration-vs-explicit-graphs-a-typescript-framework-taxonomy-6i3).\n\n```\nnpm install @open-multi-agent/core\n```\n\nThe [team-collaboration example](https://github.com/open-multi-agent/open-multi-agent/blob/main/packages/core/examples/basics/team-collaboration.ts) is the smallest end-to-end `runTeam()`\n\nrun. If you want to see how far this goes, the [Gemma 4 local example](https://github.com/open-multi-agent/open-multi-agent/blob/main/packages/core/examples/providers/gemma4-local.ts) puts a 5B local model in the coordinator seat: it does the JSON decomposition and the synthesis on your own machine.\n\nOne honest caveat: community and production validation are still early. If you run the coordinator on a real workload, I would like to hear where its plan held up and where you had to drop to `runTasks()`\n\n.", "url": "https://wpnews.pro/news/goal-in-dag-out-how-open-multi-agent-turns-a-goal-into-a-task-dag", "canonical_source": "https://dev.to/jackchenme/goal-in-dag-out-how-open-multi-agent-turns-a-goal-into-a-task-dag-1n0m", "published_at": "2026-06-21 06:40:44+00:00", "updated_at": "2026-06-21 07:06:50.874215+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "large-language-models", "natural-language-processing"], "entities": ["OpenMultiAgent", "DeepSeek", "TypeScript", "Anthropic", "OpenAI", "Gemini"], "alternates": {"html": "https://wpnews.pro/news/goal-in-dag-out-how-open-multi-agent-turns-a-goal-into-a-task-dag", "markdown": "https://wpnews.pro/news/goal-in-dag-out-how-open-multi-agent-turns-a-goal-into-a-task-dag.md", "text": "https://wpnews.pro/news/goal-in-dag-out-how-open-multi-agent-turns-a-goal-into-a-task-dag.txt", "jsonld": "https://wpnews.pro/news/goal-in-dag-out-how-open-multi-agent-turns-a-goal-into-a-task-dag.jsonld"}}