Running dependent AI tasks in sequence

Running dependent AI tasks in sequence works when each task starts only after the one it depends on has a verified completion, and when only one assignment is active at a time. A verified completion means a check you configured ran independently and passed. It does not mean the previous agent exited, and it does not mean the agent said it was finished. The difference matters more in a chain than anywhere else, because every later task builds on the earlier result. If task two starts on top of a broken task one, you get two tasks of work to unpick, and the second agent may even 'fix' the first task's bug in a way that hides it. This page covers the rule for selecting the next task, why one assignment at a time is the right default and what to do when a task in the middle blocks. For modelling the dependencies themselves, see dependency graphs for agent tasks.

The gate between tasks is a check, not a report

Here is a concrete failure from a development test of a card workflow. A shared money helper was changed from round(value * 100) to int(value * 100). The checkout check passed, but the CSV export check failed. On that workflow route, a completion report that included the failed check was refused. A later report that simply asserted a pass, against the same still-broken code, was accepted and the task was marked done. In a chain, the next task would have started on top of that.

The fix is to make the gate something the runner does, not something the agent says. Before task two can start, the runner executes the checks you configured for task one and reads the result itself. A passing claim with a failing check is a failure. A missing check is a failure too, because 'no result' is not 'passed'. The broader argument is on self-reported versus independent checks.

Check freshness as well. If files changed after the check ran and before the result was accepted, the result describes code that no longer exists, and it should be run again.

Why one assignment at a time

Dependent tasks usually touch overlapping code. Running them in parallel means two agents editing related files, each working from a picture of the codebase that the other is changing. Even when the files do not overlap, failures become hard to attribute: if the build breaks, which agent broke it?

One active assignment at a time gives you three things. Every change is attributable to one task. Each check runs against a known state: the previous task's verified result plus this task's edits. And review stays manageable, because you read one coherent change per task instead of an interleaved mix.

The selection rule is simple to write down. The next task is the first one in the approved list whose dependencies all have verified completions, which is not blocked, held or waiting for a decision, and which has an approved scope. If no task qualifies, the run stops and says why. Parallelism is still useful for independent branches, but treat it as a deliberate choice with protection against overlapping edits, not the default for a chain.

When a task in the middle blocks

Sooner or later a task in the chain fails its checks, hits a question only you can answer or discovers a prerequisite. Its dependents are now blocked. The runner should not guess what you would want.

Decide the policy before the run and write it into the run's record. The safe default is to stop the whole run. A looser policy continues with tasks that do not depend on the blocked one and leaves the rest. What the runner should never do is unblock a dependent by itself, for example by marking the blocked task done, removing the dependency or editing the dependent task so it no longer needs the result.

Resumption should also be explicit. When the blocked task is fixed and verified, its dependents become eligible on the next read of the plan. That eligibility is not a start: a person, or a run authorized for that purpose, decides to take the next task. The same rule applies to parent and child tasks, covered in parent and child task completion: finishing a child makes the parent eligible but does not complete it.

Doing it by hand today

You do not need a coordinator to work this way. A manual chain for three tasks looks like this.

Step 1: Write the chain down. ENG-1 shared cents() helper, ENG-2 checkout uses the helper (depends on ENG-1), ENG-3 deliver the app (depends on ENG-2). Give each task its own check, for example pytest tests/test_money.py for ENG-1.

Step 2: Run ENG-1 in a fresh agent session with only its scope. When the agent says it is done, run the check yourself and read the output. Record the result and the commit it ran against.

Step 3: Only if the check passed, start ENG-2 in a new session. Give it ENG-1's recorded result as context rather than the previous chat transcript.

Step 4: If a check fails, stop the chain. Decide whether to retry ENG-1, rewrite it or change the plan.

This is slower than one long session that does everything, and that is the point: every step leaves evidence, and a failure stops at the task that caused it.

QUESTIONS

Should I run dependent AI coding tasks in parallel to save time?

Usually not. Dependent tasks overlap in code, so parallel agents edit files the other is changing and failures become hard to attribute. Run the chain one task at a time with a check between steps. Use parallel agents for genuinely independent branches, with separate files or worktrees and a clear owner for each.

What counts as a verified completion for an agent task?

A completion where checks you defined ran independently of the agent, passed, and ran against the current files. The agent saying it finished does not count, and neither does the process exiting. If a check is missing, failed or ran before later edits, treat the task as not yet complete.

What should happen to dependent tasks when one task fails?

They wait. The safest default is to stop the run and leave a clear record of which task failed and why. If you allow it in advance, a run can continue with tasks that do not depend on the failed one. Nothing should unblock dependents automatically by editing the plan or marking the failed task done.

RELATED GUIDES

• How to read project progress in BRAIN FLUID Build
• Gantt planning in BRAIN FLUID: the integrated view and its prototype

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.
• Self-reported vs independently run checks for AI agent work Self-reported vs independently run checks for AI agent work: why an agent's own "tests pass" is weaker than a check the system runs itself.
• Bounded autonomy: limits every unattended agent run needs Bounded autonomy: limits every unattended agent run needs, from an explicit task list to launch, retry, time, failure and spend limits.
• Why a parent task can't be done before its children Why a parent task can't be done before its children: required versus related work, and why finishing a child changes eligibility, not status.