How to break work into units an agent can finish

Task decomposition used to be an optional planning step. In an AI-native team it is the main control you have on delivery quality, because it decides whether the failure mode is visible or hidden.

Why size decides everything

An agent working on a unit that fits will finish it, run the checks, and hand you something you can evaluate. An agent working on a unit that does not fit will do the first two thirds well, lose track of the task, and then produce a summary that describes the work as complete. Anthropic's own documentation is direct about the mechanism: performance degrades as the context window fills, and a model may start forgetting earlier instructions or making more mistakes when the window is getting full [1].

The reason this matters for delivery rather than for prompting is that the failure is silent. Nothing errors. The build keeps passing if the tests it wrote cover the part it finished. A human then reviews a large diff, finds the parts that are present to be reasonable, and misses that a requirement from the middle of the ticket has been dropped without any notice.

The right-sized unit

We use two tests, both practical rather than theoretical.

One reviewer, one sitting. A person should be able to keep the whole change in mind at once and say what it does and what it risks. If they have to scroll back to remember what the first file did, the unit is too big for the review to be real, whatever the review process says happened.

One check, one answer. There should be a check that decides whether the change works. Not twelve loosely related tests: one clear signal, plus whatever supporting tests it needs. If you cannot describe that check in a sentence, you are looking at more than one unit of work sharing one ticket number.

Both tests are about the humans and the pipeline, not about the model. Models will readily attempt far more than this. The constraint is that a delivery process needs failures to be attributable, and attribution requires small units.

The failure at the large end

The large-unit failure is the expensive one because it is invisible until late. The pattern goes: a broad ticket, an agent session that runs for a long time, a large diff, an approving review because the visible parts are competent, and then a gap discovered two weeks later by a customer or an auditor.

There is a second version that costs more. When a single unit spans several areas of the system, a failure anywhere in it invalidates the whole change, so the rollback is all or nothing. A team ends up choosing between reverting three days of work to fix one bad decision, or adding fixes on top of something they no longer trust. Neither is a good option and both were created at planning time.

If a change genuinely cannot be split, that is usually information about the system rather than about the ticket. Coupling that forces every change to be wide is the thing to fix, and it is worth naming as work in its own right rather than accepting it without comment forever.

The failure at the small end

The opposite error is real but cheaper. When units are too small, each one passes, each one is trivially reviewable, and the coordination cost moves onto humans. Ten changes that are individually correct can still produce a feature that is incoherent, because nobody kept the whole design in view.

The signal here is a rise in follow-up changes that only exist to reconcile earlier ones: renaming for consistency, moving a function that ended up in the wrong module, aligning two interfaces that were designed in separate sessions. That is the coordination cost showing up as work. If you see it, merge some units back together and write down the overall design of the feature before you start.

Splitting along boundaries that already exist

The common mistake is splitting along the ticket's sentences: one unit per bullet point. That produces changes that all touch the same files and cannot be released independently, which is the worst of both cases.

Better boundaries, with the most useful first:

By deployable part. Split so each unit can go to production and be observed on its own, even if it is behind a flag and does nothing yet. This is the boundary that makes progressive delivery possible.

By data direction. Writing the new field, backfilling it, reading it, and removing the old one are four units, and they should be four. This ordering is also what makes the change reversible at each step, which matters most when a migration is involved.

By interface. Define the contract in one unit, implement behind it in another, migrate callers in a third. The contract unit is small and is the one worth a careful human read.

By risk. Isolate the part that touches money, credentials or personal data into its own unit so it can get the review and the gates that the rest does not need. Mixing a payment path into a large change that only affects appearance is how a high-risk edit gets a low-risk review.

Ordering the work so the agent does not lose track

Once the units exist, the order matters. Two rules give most of the benefit.

Put the contract first. When the interface, schema or type definitions are merged before the implementation, everything generated afterwards has something concrete to conform to, and mismatches appear as type errors instead of as surprises when the code runs. This is also why typed languages and strict configuration are worth more in an AI-native team than they did before.

Merge the check before the code where you can. A failing test that describes the desired behaviour, written and reviewed first, turns the implementation step into something the agent can work against, again and again until it passes, with nobody watching. It also proves the test can fail, which is the property most missing from generated test suites, as covered in test strategy when the AI writes the tests too.

Keeping the whole design consistent while the parts change

Splitting work creates a new obligation: someone has to keep track of the whole feature. In our experience that is one named person per feature, and their job is not to write the code, it is to keep the order correct and notice when unit four has broken the assumption behind unit two without anyone noticing.

Write the sequence down where the agent can read it, in the repository rather than in a ticketing tool. A short plan file naming the units, their order and the boundary they were split on gives every session the same information, which is most of what stops six sessions producing six different designs. That habit is covered from the point of view of documentation in documentation an agent and a new hire can use.

Parallel sessions need boundaries too

One consequence of cheap code writing is that several agent sessions can run at once, and the decomposition decides whether that is useful or chaotic.

Two units that touch the same files will produce conflicting changes, and resolving a conflict between two generated diffs is unpleasant work: neither side has an author who remembers the intent, so the reviewer is reconciling two sets of reasoning they were not part of. The way to avoid it is to split by file ownership as well as by behaviour, so parallel units touch disjoint areas. Where that is impossible, run them one after another and accept the extra elapsed time, because it is smaller than the cost of a bad merge.

The related habit is to keep each parallel session's scope written down where the others can be checked against it. Isolated work benefits from isolated context, right up to the moment two sessions make incompatible assumptions about the same interface, and the only cheap protection is that the interface was fixed before either started.

What to change first

Take the last feature that went badly and look only at its decomposition. Ask whether any single unit was too large for one person to understand as a whole, whether any unit mixed a high-risk path with routine work, and whether the units could have been released independently. In most postmortems we run, the answer to at least one of those is no, and it explains more of the outcome than any decision made later.

The units also have to arrive with a standard, which is what done means when an agent writes the code, and they have to pass something that does not depend on goodwill, which is the gates. The main guide puts the sequence together.