Agent Task Graph

The coordination substrate for a team of agents: a shared, mutable task list where each task carries an owner and explicit dependency edges, so a primary (orchestrator) agent can delegate work to specialized sub-agents and let their outputs unblock each other without a human hand-carrying state between them. It is the Agentic Workflow Patterns orchestrator-workers topology given a native, first-class data structure instead of an ad-hoc prompt: the plan is a graph, not a linear checklist.

Claude Code's Task System is the concrete instance. Its TaskUpdate tool exposes the graph directly: taskId, status (pending | in_progress | completed | deleted), owner (which agent holds the task), metadata, and the two edge-builders addBlocks: string[] and addBlockedBy: string[]. As sub-agents finish work they ping back to the primary agent; completing a task clears the blockedBy edges of its dependents, so blocked tasks become runnable in dependency order. The system is on by default when sub-agents are in play, and it "really helps in the planning phase" — you can lay out specialized agents and their Parallel: true/false structure up front and let the graph sequence execution.

The recurring team shape is the builder/validator pair: for every build task, a paired validation task that Depends On it, is Assigned To a validator agent, and gates on an executable check (a py_compile, a "contains required section" test). Coordination without dependency edges and without a channel for agents to communicate degrades into agents working past each other — the graph is what makes "more agents" cohere toward a common goal rather than just adding autonomy (see Agentic Simplicity).

Claims

A team of agents needs a shared task graph with explicit dependency edges and per-task ownership — not just parallel invocation — to coordinate toward one goal. principle — durable: without a way to express "B waits on A" and "who owns B," concurrent agents race and duplicate; the dependency graph is the minimum structure that makes delegation cohere.
Model task dependencies as blocks / blockedBy edges and let completing a task unblock its dependents automatically. best practice — context: orchestrating multiple sub-agents on interdependent work; the edge representation is what lets the orchestrator sequence execution without re-planning, and it's contingent on a runtime (like Claude Code's Task System) that acts on the edges.
Pair every builder agent with a validator agent whose task depends on the build and gates on an executable check. best practice — context: multi-agent builds where correctness must be enforced, not assumed; the pairing buys per-task self-validation but costs an extra agent per unit of work, so it earns its keep on work where a failed build is expensive to catch late.
Sub-agents report completion back to the primary agent, which then advances the blocked tasks. observation — the ping-back is the event that drives the graph forward; the primary agent is the scheduler, the sub-agents are workers.
More agents, more autonomy, and more compute do not always mean better outcomes — what matters is agents coordinated toward a common goal. principle — durable: added parallelism without coordination structure adds cost and error surface, not capability; this is Agentic Simplicity applied to team size. See Workflows vs Agents on the compounding-error risk of unbounded autonomy.
Decompose a large plan into atomic subtasks and hand each to a fresh agent/context window — five agents making 100-line changes beat one agent making a 500-line change. (best practice) — context: LLM coding where a long single run degrades into context compaction / overload; small tasks on fresh windows keep each agent "at maximum capacity," but the decompose step only pays when the plan is solid enough that the pieces are truly independent. A second independent source (Jaymin West) reaches the same decompose-to-fresh-context rule.
seeds (git-native, JSONL, sd CLI) is a second concrete instance: sd plan decomposes a large seed into one child seed per step and wires each step's blocks into the children's blockedBy edges. observation — the same blocks/blockedBy graph as Claude Code's Task System, materialised in a lightweight git-native issue tracker rather than a runtime; agents then sd ready to pull unblocked work in dependency order.
Wayfinder is a third concrete instance, and the first that types its nodes by resolution mode: a planning map materialised as GitHub issues + sub-issues with blocking relationships, each sub-issue scoped to one agent session, and each labelled research / prototype / grilling / task. observation — same blocks/blockedBy edges, but the nodes are unknowns to resolve rather than build tasks, and their type (see Resolution-Typed Tasks) routes how each is worked. The /to-tickets output is one artifact that reads two ways: a local tickets.md (edges as text, worked top-to-bottom) or a real tracker (native blocking links, so any unblocked ticket is on the frontier and several agents can run at once).
The medium-agnostic ticket artifact survives into flat markdown with its frontier semantics intact. observation — a tickets.md on screen reads: "Work the frontier: any ticket whose blockers are all done. This is a single ticket, so just do it," with each ticket carrying **Blocked by:** None — can start immediately. Same edges, no tracker — corroborating that the graph is the artifact and the backend is a Repo-Local Capability Binding detail. The same session shows the human overruling the decomposition ("these three slices are a little bit much — do it in one slice instead"): slicing is agent-proposed, human-ratified.
The node size has a stated unit: one ticket is "the size of a single context window or a single smart zone," and the operator clears between tickets. best practice — context: the same author running an 11-sub-issue spec where "each of these tickets is a single context window session," each ticket short because "most of the acceptance criteria is already in the main spec." This supplies the why behind this page's existing decompose-to-a-fresh-window claim — see Context Smart Zone — and its cost: a spec that holds the standard so each ticket can hold only its slice.

Agentic Workflow Patterns — the task graph is the orchestrator-workers pattern given a native runtime substrate (dynamic decomposition + delegation), not a new topology.
Workflows vs Agents — a team of task-owning sub-agents is agents-in-the-large; the graph is the predefined structure that keeps their combined autonomy bounded.
Agent Supervision — the builder/validator pair is automated supervision (agent gates agent); the human still supervises the orchestrator, but the graph internalizes some review.
Spec-Driven Development — the graph is generated from a spec/plan; the plan's ## Team Orchestration and ### Team Members sections are where the graph is declared.
Meta-Prompt — the reusable meta-prompt that writes the plan that declares the graph.
Agentic Simplicity — "more agents ≠ better" is the simplicity discipline applied to orchestration.
Agent Rituals — decomposition + priming the substrate is itself a ritual every planning agent runs; the graph is the output.
Map-First Planning — the specialization of this graph for planning under fog: nodes are session-sized unknowns, not build work, resolved in dependency order before a spec exists.
Resolution-Typed Tasks — the typing layer on top of the edges: what waits on what (the graph) vs. how each node resolves and whether a human must be present (the type).
Distillate: Claude Code Task System: Orchestrating a Team of Agents Through a Task Graph
Distillate: The Agentic Engineering Meta — a second instance (seeds/sd plan) with the same blocks/blockedBy edges, plus the decompose-to-fresh-context-window rationale.
Distillate: Skills v1.1: Wayfinder, the SDLC flow, and naming the artifact right — a third instance (Wayfinder) that materialises the graph as GitHub sub-issues and types its nodes by resolution mode.
Context Smart Zone — the limit that sets the node size: this page says decompose to a fresh window, that page says how big the piece may be and why the window must be fresh.
Repo-Local Capability Binding — why the same ticket set reads as local markdown or as native tracker issues: the skill names the verb, the repo binds it.
Distillate: The whole flow, end-to-end: the smart zone is the unit of work — an 11-sub-issue spec with each ticket sized to one context window, and the frontier/blocked-by edges surviving into flat markdown.

Agent Task Graph

Claims

Related

Linked from