Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →evermind-ai/subagent-dag-orchestration
Use when a task breaks into several distinct steps that a separate sub-agent could each carry out. A DAG node dispatches to an agent on the roster and cannot call your own tools, so steps that are just your own tool calls (reading files, small edits, running commands) are not a DAG for being many - do those yourself. The bound is about who can carry the work, not what kind of work it is: when the roster carries a specialist for it (a coding agent for code changes, an on-call agent for long runs)
Passed 18 of 19 test cases with the skill, and 4 of 19 without it.
and 14 more in the full report
14 fixed4 passed either way1 still failing0 broke3 errored
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
One of 14 test cases the skill fixed. Same model, same prompt, with and without the skill.
In a previous turn during this conversation, a node named `data_loader` was executed. We need to run data loading again with new arguments. Provide the `run_subagent_dag` JSON array for this step.
| Checked | Without skill | With skill |
|---|---|---|
| Assigns a new unique ID such as data_loader_v2 instead of reusing data_loader | Missed | Passed |
The instructions your model reads when the skill loads.
The trigger is delegated work that breaks into several tasks.
The host's role decides what to delegate; this guide decides how to group the work.
A DAG node dispatches to an agent on the roster, including Raven-General; it cannot
call the host's tools. Choose from that tool's subagent parameter enum: agent names
on ordinary turns, worker labels when a Worker Table is bound. A worker label selects
the underlying agent together with that worker's brief. The roster describes the
underlying agents' capabilities; its names are not dispatch values on a worker turn.
The host's own coordination calls, such as reading a brief or
checking task status, are not delegated tasks and do not need a graph just because
there are several of them.
For the delegated tasks, test three things before dispatching them one at a time:
max_concurrent_subagents — spawn draws on the same allowance).spawn
can hand its result on too — it takes a node_id and a later task names it the same way
a node does — but only across a turn of yours; a graph needs none.subagent parameter also describes each worker's brief; choose a label that fits.If any of the three holds, express the whole task as one run_subagent_dag call
rather than dispatching sub-agents one at a time. Persistence is not one of the reasons:
every node's prompt and output is written to disk, and so is every spawn's.
Iteration is graphs in series, not a cycle in one graph. A graph is acyclic and
runs once. When the work loops — code changes feeding experiment rounds feeding the
next code change — dispatch one graph per round and drive the loop yourself: each
graph's outputs come back to you, and the next round's nodes reuse the same
instance handles, so each side keeps its context across rounds.
If none of the three holds, dispatch the work to one agent: use spawn if it is offered,
test cases passed, vs 4 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.