Why a parent task can't be done before its children

Why a parent task can't be done before its children has a short answer: the parent's definition of done includes the outcome of every required child, so marking it done while one is open records something false. The longer answer depends on separating two kinds of link. Required children are pieces of the parent's own work, and the parent cannot be correct without them. Related or optional work, such as a cleanup an agent spotted along the way, sits next to the parent and does not block it. Getting that distinction right is most of the battle with AI agents, which split work eagerly and close it optimistically. A third rule completes the picture: finishing a child makes the parent eligible to finish, but does not finish it. Someone still has to check that the pieces add up. For planning the graph itself, see task dependency graphs for AI agents.

Required children and related work

A required child is a slice of the parent's scope moved into its own task. "Deliver the app" requires "checkout truncates fractional cents" and "CSV export keeps nearest-cent rounding"; the app is not delivered if either is missing. The test is simple: can the parent's acceptance criteria be met while this child is open? If not, it is required.

Related work fails that test. "Rename the legacy money module" might be worth doing and might have been discovered while working on the parent, but the parent's acceptance criteria do not mention it. Link it so the knowledge is kept, and leave the parent unblocked.

The cost of getting this wrong runs both ways. Mark related work as required and the parent stalls behind tasks nobody prioritized, which trains people to close parents by hand and ignore the rule. Mark required work as related and the parent closes while a piece of its scope is missing, which surfaces later as a defect in something everyone believed was finished.

Write the link type and one line of reason when the child is created, not at closing time, when the pressure is to make the parent look finished.

Why the parent has to wait

Three things go wrong when a parent closes before its required children.

Reports overstate progress. Progress figures and milestone status count the parent as finished, and anyone reading them believes a capability exists that does not. Weighted progress makes this worse, because a parent usually carries the most weight.

Verification is skipped. The parent's checks are often integration checks: do checkout, export and delivery work together? Running them before the children are done either fails, which looks like noise, or passes against stubs, which looks like success.

Ownership disappears. Once the parent is closed, open children become orphans. Nobody owns the question of whether the feature as a whole works, and the children get closed one by one against their own narrow checks.

AI agents make all three more likely. An agent that finishes the last child it was given often reports the parent as done in the same breath, because from inside its session that was the goal. Treat such a report as a claim to verify, as described in how to know an AI agent finished a task, and keep the rule mechanical: open required child, parent not done.

Finishing a child changes eligibility, not status

When the last required child closes, the parent becomes eligible for completion. It does not become complete. Those are different events and should stay different.

Eligibility means the parent can now be checked: its own acceptance criteria and integration checks can run against real pieces instead of stubs. Completion means they did run, they passed, and someone or something trusted accepted the result.

Collapsing the two produces a familiar failure. Each child passed its own check, so the parent is marked done automatically, and nobody ever ran the check that tests the pieces together. In the blast radius probe, a scripted change made the checkout check pass while breaking the export, and both were prerequisites of the same delivery card. A parent that completed itself the moment its children were marked done would have shipped that.

Eligibility should not start work by itself either. A child closing is a good moment to tell someone the parent is ready for its final check, but launching an agent session on the parent should still need the same authorization as any other work.

Common mistakes in agent-generated breakdowns

Agents asked to split a task produce recognizable patterns. Review a breakdown for these before accepting it.

Everything required. The agent lists every idea as a child, including refactors and polish. Downgrade anything that is not in the parent's acceptance criteria to a related link.

The parent duplicated as the last child. A child called "finish and integrate" repeats the parent's scope. Remove it; integration is the parent's own check.

Children with no checks. Each required child needs its own way to show it is done, or the parent inherits unknowns.

Siblings that depend on each other. Two children that each require the other form a loop that blocks the parent forever; see dependency cycles in project plans.

Discovered work attached as required by default. Work found mid-task is often optional. Decide on purpose, as discussed in agent-discovered tasks.

None of these need special tooling to catch. A short read of the breakdown, with the parent's acceptance criteria next to it, catches most of them before any agent starts.

QUESTIONS

Can a parent task be closed if a subtask is still open?

Not if the open subtask is required, meaning the parent's acceptance criteria cannot be met without it. Closing anyway makes reports overstate progress and skips the integration check. If the open item is optional or related work, it should not be a blocking subtask at all; relink it and close the parent on its own criteria.

Should a parent task complete automatically when all subtasks are done?

No. When the last required subtask closes, the parent becomes eligible for its own final check, usually an integration check that tests the pieces together. Completing it automatically skips that check, which is exactly where problems between subtasks show up. Notify someone that the parent is ready for review instead.

What is the difference between a subtask and a related task?

A subtask, or required child, is part of the parent's own scope, and the parent is not done without it. A related task is linked for context, such as a cleanup discovered along the way, and does not block the parent. The deciding question is whether the parent's acceptance criteria mention the work.

RELATED GUIDES

• How to read project progress in BRAIN FLUID Build

RELATED HARNESS PAGES

• Task dependency graphs for AI agents Task dependency graphs for AI agents: declare prerequisites, let selection skip blocked work and keep dependencies in the context each agent gets.
• Managing tasks an AI agent discovers mid-work Managing tasks an AI agent discovers mid-work: record each as a new linked task, mark it required or optional and never widen the current task silently.
• How do I know whether an AI agent actually finished a task? Process exited, agent says done and verified are three different states. A checklist to tell which one your AI agent's task is really in.
• Weighted progress: why card counts mislead Weighted progress: why card counts mislead. Give tasks explicit weights against a fixed baseline, count only accepted work, and rebase when scope changes.