Task Decomposition for AI Coding Agents: Draw the Graph First

Across 20,574 real coding-agent sessions, the most common failure was not the agent misreading a vague request — it was the agent violating a constraint the developer had already stated (Tang et al.: How Coding Agents Fail Their Users¹). That finding moves the fix somewhere uncomfortable. If the rule was in the prompt and the agent broke it anyway, sharpening the prompt is aimed at the wrong thing, and the real question is where the rule should live instead.

Your Agent Violates Constraints You Already Stated

When an agent goes off-script, the reflex is to reopen the prompt and sharpen the wording. The largest observational study of how coding agents fail suggests the wording was usually fine.

Tang et al. annotated misalignment episodes across 20,574 coding-agent sessions and sorted them into seven recurring symptoms. The most prevalent symptom is not misunderstanding. It is S3, Developer Constraint Violation — defined as violating an explicit developer constraint — carried by 38.33% of episodes. The taxonomy allows multi-label assignment, so those seven shares deliberately do not sum to 100. An episode can be both a constraint violation and a misread intent (Tang et al.: How Coding Agents Fail Their Users¹).

The cause profile underneath it is the part that should change your behavior:

“73.68% of S3 episodes are attributed to C6 (Instruction-Following Failure)”

A second team reached the same place from a different direction. Hasan and Biswas mined the GitHub issue trackers of 13 foundational code models for confirmed safety failures, and their top category matches to within two points:

“The top threats, namely Constraint Violations (40.4%), Destructive Operations (24.5%), Authorization Bypasses (18.3%), and Deception (15.7%), dominate real-world failures.”

Two datasets, two methods, one answer. And the failures are not exotic — Hasan and Biswas note they arise during benign, goal-directed use, which means the ordinary Tuesday-afternoon session is the sample.

The bill lands on you rather than on the system. In Tang et al.’s data, 90.50% of episodes impose effort and trust costs rather than irreversible system damage, yet 91.49% of visible resolutions still require explicit user correction — you are the error handler. Worse, the failures compound instead of resetting: a session containing misalignment raises the probability of misalignment in the next session to 0.519 against 0.336 otherwise.

The move is therefore: stop encoding constraints as sentences and start encoding them as things the harness can refuse — a file the agent may not write, a contract it may not change, a check that fails loudly.

Underspecification Is the Smaller Problem

“Write clearer requirements” is the natural next thought, and it quietly absorbs more of the problem than it has earned. The same paper carries a separate cause taxonomy. Its ambiguity category — C1, Underspecified Instruction, covering instructions that are ambiguous, underspecified, or inconsistent — accounts for 15.36% (Tang et al.: How Coding Agents Fail Their Users¹). Set that against the 73.68% of constraint violations attributed to instruction-following failure and the ranking is clear enough to plan around.

The problem is not that you failed to say it. It is that saying it was never load-bearing.

That does not make specification worthless — it relocates it. A specification that only exists as prose in a context window competes for attention with everything else in that window. A specification expressed as structure does not compete; it either holds or it fails a check.

Put the Decomposition Outside the Prompt

Splitting an epic into subtasks is not the win. Where the split lives decides whether the split pays for itself, and the naive form loses to doing nothing.

IBM researchers benchmarked decomposition against a monolithic run on two agentic coding workloads, and the result cuts against the usual assumption:

“Our results show that decomposition alone does not necessarily reduce retry cost. In the Kubernetes root cause analysis workload, the static decomposition baseline produced a retry cost of 1,632 +/- 145 tokens versus 904 +/- 17 tokens for the monolithic baseline because failures forced reruns of downstream subtasks.”

Their static baseline is a decomposition whose structure “must be known and fixed at design time,” run with fixed subtasks and no runtime branching — a hardcoded pipeline, not a list of steps pasted into a prompt. The mechanism of the loss is stated plainly: “fixed sequential execution must rerun all downstream subtasks from the point of failure.” A subtask list typed into your prompt has neither runtime branching nor a validated handoff. That is my reason for moving it out, not the paper’s finding.

What turned the result around was structure with gates at each edge. In the runtime-structured configuration, “a failed subtask’s output is not written to the State Manager and is never visible to downstream subtasks.” Retry cost on the same workload fell to 436 ± 132 tokens (Asthana et al.: Runtime-Structured Task Decomposition³).

Take an ordinary epic — “Add tenant-scoped rate limiting to the public API” — and cut it at its layer boundaries:

n1  schema      migrations/0042_tenant_rate_limits.sql    depends: —
n2  middleware  internal/middleware/ratelimit.go          depends: n1
n3  admin-ui    web/admin/src/settings/RateLimits.tsx     depends: n1, n2
n4  docs        docs/api/rate-limits.md                   depends: n2

n2 is where this epic actually fails. Deciding what counts as a tenant on a partly unauthenticated route is a judgment call, and the agent will make one. Inside a pipeline with no branching, that failure takes n3 and n4 down with it. That is three nodes of blast radius for one bad decision, plus whatever the admin screen already wrote against the wrong policy shape. With a validated handoff on n2’s output, the rerun is one node, because nothing downstream ever saw the bad result.

Do not expect the agent to draw these seams for you. Gao’s benchmark over 2,209 real skills found that “task decomposition quality is the primary bottleneck: standard LLM decomposition reaches only 34.2% category recall at the step level” (Xueping Gao: Compositional Skill Routing for LLM Agents⁴). Granularity is the hard part, and it is the part models are worst at. Where to cut is a sizing question — how to size tasks for AI coding agents argues layer boundaries are the most reliable seams. Each of n1 through n4 sits inside one layer. What goes inside a node once you have it is a separate craft, covered in the anatomy of a perfect AI agent task.

Give Every Node Owned Files and Owned Contracts

Author’s judgment. The prescription in this section — that assigning each node a file glob and an interface contract fixes the collision — is my inference, not a measured result. It follows from three sourced premises: CooperBench’s agents worked without assigned ownership and overwrote each other, the Claude Code worktrees documentation ships file isolation but no guidance on who owns what, and Cognition names the root cause as assumptions never prescribed upfront. No benchmark I found has tested an assigned-ownership arm.

CooperBench put two coding agents on interdependent features in the same repository and measured what happens. Agents working together achieved on average 30% lower success rates than the same agents doing both tasks individually. The GPT-5 and Claude Sonnet 4.5 configurations landed at only 25% success under two-agent cooperation — roughly half the rate of a single agent (Khatua et al.: CooperBench⁵). The collision is not an edge case: in that dataset, 77.3% of tasks have conflicting ground-truth solutions.

“agents often hold incorrect expectations about their partner’s plans, observations and duplicate work despite warnings and overwrite changes they believe will merge cleanly”

“Merge cleanly” is the footgun in that sentence. A textually clean merge is not a correct merge, and the paper separates the two problems precisely:

“Merge conflicts are fundamentally a spatial coordination problem: agents must agree on who edits which lines… However, task success requires semantic coordination: understanding what to implement, not just where.”

So each node needs two edges, not one. The file glob is the spatial edge and stops overwrites. The named contract is the semantic edge and stops the merge that succeeds while losing the meaning. n2 renaming a field on RateLimitPolicy while n3 renders a form against the old shape produces zero conflicts and one broken screen.

The spatial half already ships as product. Claude Code’s worktrees isolate parallel sessions at the filesystem level, and the docs are explicit about the division of labor: “Worktrees are one of several ways to run Claude in parallel. They isolate file edits, while subagents and agent teams coordinate the work itself” (Claude Docs: Run Parallel Sessions with Worktrees⁶). The page documents creation, cleanup, base branches, and subagent isolation — and says nothing about how a human decides which session owns which files. The enforcement mechanism is shipped. The decision it enforces is yours.

The semantic half is where ambiguity actually attaches. Hamel Husain’s framing is that the model often is not the problem at all: “A really common way that the model is not the problem is query disambiguation. The LLM doesn’t have a chance because the user is asking a very ambiguous question and isn’t providing enough context.” The article’s worked example is an agent asked to clean up the authentication service. It cannot know whether it may alter the public API, introduce a dependency, modify the database schema, or change existing error behavior (Arize: Hamel Husain Explains Why AI Evals Fail⁷). Those four questions are contract questions, and a node that names its contracts has answered them before the agent starts.

Bad: “Agent B: build the admin screen for tenant rate limits.”

Good: “Agent B: build the admin screen for tenant rate limits. You write web/admin/src/settings/** and internal/admin/ratelimit_handler.go, nothing else. RateLimitPolicy in internal/ratelimit/policy.go is owned by the middleware node — read it, do not change it. If the screen needs a field that does not exist on it, stop and report rather than adding one.”

Assigned globs are worth checking rather than assuming, because two nodes that both look reasonable can still overlap on a shared package:

# Any path that appears in both node globs is an unassigned collision.
comm -12 \
  <(git ls-files 'internal/middleware/*' 'internal/ratelimit/*' | sort) \
  <(git ls-files 'web/admin/src/settings/*' 'internal/admin/*' | sort)

The check passes when it prints nothing. When it prints a path, you have found the file two agents will both edit. You resolve it by assigning it, not by hoping.

Whether you then run these nodes in parallel is a separate decision, and the case for keeping writes single-threaded lives in multi-agent context isolation. The graph exists either way. One agent working n1 through n4 in sequence still needs to know that RateLimitPolicy belongs to n2.

A Chat Channel Is Not a Coordination Structure

The obvious escape hatch is to let the agents talk to each other. CooperBench handed them exactly that — a messaging tool — and the number that matters did not move.

“none of the models effectively leverage communication tool to achieve higher cooperation success. The difference between ‘with comm’ and ’no comm’ settings is not statistically significant.”

Cognition reached the same conclusion from production experience, and named the mechanism: “Actions carry implicit decisions, and conflicting decisions carry bad results.” Their post-mortem on subagent collisions is that “the actions subagent 1 took and the actions subagent 2 took were based on conflicting assumptions not prescribed upfront” (Walden Yan: Don’t Build Multi-Agents⁸). Prescribed upfront is the operative phrase. A chat channel is where assumptions get announced, not where they get prescribed.

Watch what that looks like on the rate-limiting epic. n2 messages that it will add a Burst field to RateLimitPolicy. n3 says great, and builds a form input for it. n2 then decides burst is really a per-tenant column and drops the struct field. Nothing in that exchange was a lie, both agents behaved reasonably, and the screen ships bound to a field that no longer exists. The transcript records agreement; the repository records a break.

The practical version is a set of transcript signals and the move each one calls for:

Price the Graph Before You Commit to It

Structure is not free, and the paper that measured its upside also printed its bill. In the same IBM experiments, the runtime-structured configuration cost 2,716 ± 424 tokens on its baseline run against 904 ± 17 for the monolithic one (Asthana et al.: Runtime-Structured Task Decomposition³). That 904 is the same number as the monolithic retry cost quoted earlier, and not by coincidence: when the whole job is one unit, retrying it means running all of it again. You buy cheap retries with an expensive first attempt. That trade only pays at a failure rate high enough to cash it in — and the authors say so themselves:

“Both use cases are controlled scenarios at temperature 0 with low natural failure rates (0–2%), so retry cost is measured under simulated failure.”

The three configurations, priced by retry cost on the same root cause analysis workload:

The tempting way to justify the upfront cost is the old cost-of-delay curve, and it does not survive contact with data. Menzies et al. examined 171 software projects from 2006 to 2014 looking for exactly that effect:

“We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction.”

So argue from the agent failure base rates instead — the 38.33% and the 40.4% from the first section. Those are the numbers that justify this work, not folklore about the cost of fixing things later.

Run these six checks before you build the graph:

1. Measure your own failure rate first. Run the epic once as a single task and count the attempts it took. A workflow that lands on the first try does not need a graph.
2. Count the depth of the longest dependency chain, not the number of nodes. Depth is what sets the rerun blast radius when a middle node fails.
3. Confirm each node is independently verifiable. If you cannot check n2 without n3 existing, you have drawn a seam that is not a seam.
4. Check the expected diff per node against the reviewable ceiling. A node whose diff blows past ~200 LOC is two nodes wearing a trench coat — see the sizing flowchart.
5. Refuse to cut where the pieces need constant back-and-forth. Anthropic’s guidance names the failure directly: “Planning, implementation, and testing of the same feature share too much context,” and “Components requiring constant back-and-forth belong in the same agent” (Anthropic: Building Multi-Agent Systems¹⁰).
6. Stop when the spec grows longer than the diff. Birgitta Böckeler watched a spec-driven tool turn a small bug into four user stories with sixteen acceptance criteria — a sledgehammer for a nut (Birgitta Böckeler: Understanding Spec-Driven Development¹¹).

Priced this way, the rate-limiting epic earns its graph: three layers, a chain of depth three, four independently verifiable nodes, and a middleware node whose tenant-identification decision you have already watched an agent get wrong. Change the epic to “add a nullable column and document it” and the same arithmetic says run it monolithic and skip all of this.

Name Who Owns the Task Graph

Every source I read that describes this artifact describes it as hand-authored, and none of them names the hand. That is the actual gap — not a missing tool, an unassigned job.

Microsoft’s Daniel Epstein names the failure mode from practice, in an argument rather than a study — the post reports no measurements at all:

“No backlog: There is no structured list of what needs to be built, in what order, with what dependencies. Work gets discovered during implementation, not planned before it.”

The measurement side agrees by omission. The IBM paper that made structured decomposition pay lists this among its own limitations: “Decomposition policies are developer-authored and may not generalize to automatically derived graphs” (Asthana et al.: Runtime-Structured Task Decomposition³). The structure that produced a 73.2% retry-cost reduction over the static baseline came out of a person’s head. Nothing in the result suggests a model would have drawn it — and Gao’s 34.2% step-level recall suggests it would have drawn it badly.

Kent Beck’s framing is the one to hand your leadership, because it says the skill is appreciating rather than depreciating:

“Augmented coding deprecates formerly leveraged skills such as language expertise. Augmented coding amplifies vision, strategy, task breakdown, and feedback loops.”

Anthropic’s own 2026 trends report puts it on the list of where engineering value moves: “In 2026, the value of an engineer’s contributions shifts to system architecture design, agent coordination, quality evaluation, and strategic problem decomposition” (Anthropic: 2026 Agentic Coding Trends Report¹⁴). That is a vendor describing a market it sells into, so weigh it as a position rather than as evidence. It still lines up with the two independent studies above.

Stack the four together and the last column never gets filled in:

Put a name against the graph the way you put one against the on-call rotation. The engineer accountable for the design review of a feature owns that feature’s graph, and owns it before any agent starts. The graph is the design review, expressed in a form the runtime can enforce.

Convert One Epic, End to End

Author’s judgment. The ordering of the seven checks below is my synthesis of the six sections above, not a procedure any single source publishes. Each gate traces back to a sourced claim; the sequence is mine.

The epic arrives as one sentence, and its shape is the problem. “Add tenant-scoped rate limiting to the public API” sits in the same category as GitHub’s example of specification failure: “A vague prompt like ‘add photo sharing to my app’ forces the model to guess at potentially thousands of unstated requirements” (Den Delimarsky: Spec-Driven Development with AI¹⁵). Run it through the gates in order and stop at the first one you cannot answer.

Is every constraint you care about expressed as something other than a sentence in the prompt? If no → you are relying on instruction-following, which is where the 38.33% lands. Convert each constraint into an owned file, a frozen contract, or a check.

Does the split live in structure with a validated handoff at each edge? If no → a fixed pipeline reruns everything downstream of a failure and can cost more than not splitting at all. Add the gate before you add the nodes.

Does every node have a file glob it exclusively writes? If no → run the disjointness check and assign the overlap. Unassigned files are where agents overwrite changes they believe will merge cleanly.

Does every node name the contract it owns and the contracts it may only read? If no → you have solved the spatial problem and left the semantic one open. RateLimitPolicy needs exactly one owner.

Are you expecting the agents to negotiate any of this at runtime? If yes → move it into the node definitions. A messaging channel produced no significant improvement in cooperation success.

Does your observed failure rate justify the upfront cost? If no → run it monolithic. Structure is a purchase, and cheap retries are the only thing it buys.

Whose name is on this graph? If nobody’s → assign it before the first agent starts, or the graph gets discovered during implementation instead of planned before it.

The finished artifact for this epic fits in a table, and every column is a gate above:

That table is the whole argument in one place. Four bounded, verifiable nodes, each with a glob nobody else writes, a contract with exactly one owner, and a done condition a machine can evaluate — drawn by a named human before a single agent opened a file.

I package these gates as agent-engineering-toolkit: decompose-epic¹⁶ — a skill that walks the seven questions, plus a standalone script that checks the finished graph against your repository: overlapping globs, contracts with two owners, dependency cycles, and any “done” that is still prose. The first thing I pointed it at was the repo this site is built from, and it failed the graph I had just written by hand — two nodes claimed the same script. That is the failure this whole post is about, and I did not catch it by reading.