Task dependency graphs for AI agents

Task dependency graphs for AI agents are plans in which each task names the tasks that must finish before it can start, so that an agent, or whoever assigns work to agents, only picks up work whose prerequisites are done. Without one, an agent handed "build the export screen" will start before the data model it needs exists, invent a placeholder model and leave you to reconcile two designs. With one, three habits do most of the work: declare prerequisites when you write each task, let selection skip anything whose prerequisites are unmet, and keep the dependency information inside the context the agent receives. A fourth keeps the graph honest: update it as agents discover work. This page gives a workflow for all four that works with a spreadsheet, an issue tracker or a dedicated harness. Board states are a separate topic, covered in kanban for AI agents.

Step 1: Declare prerequisites when you write the task

Write the dependency at the same moment as the task, while the reason is in your head. A good declaration has three parts: the prerequisite task, the kind of link and one line on why.

Required prerequisites block the task: "ENG-2 checkout truncation requires ENG-1 shared cents() helper, because checkout must call the helper, not its own math." Related links do not block, they inform: "see ENG-3 export, which also uses the helper and expects rounding." Keep the two kinds separate. If everything is required, nothing is eligible; if nothing is, agents start too early. The parent and child completion rules follow from the same distinction.

Declare at the level agents work at. A dependency between two epics tells an agent nothing about which file to wait for. A dependency between two tasks of a session or two in size does.

When an agent drafts the plan, review the links as carefully as the tasks. Agent plans tend to chain everything in the order it was written, which creates false sequencing, and occasionally create loops; see dependency cycles in project plans.

Step 2: Let selection skip blocked work

Eligibility is a simple rule: a task is ready when every required prerequisite is done, and not before. Apply it at the moment work is selected, not when the plan was made, because prerequisites change state in between.

If you assign work by hand, make the rule visible. Filter your board or list to tasks with no open required prerequisites and pick only from that view. If you script assignments, compute eligibility from the recorded links on every run rather than caching a ready flag that someone forgets to clear.

Be strict about what done means here. A prerequisite that the agent reported finished but nobody verified is not a safe foundation. If a downstream task builds on an unverified helper and the helper turns out wrong, you have two tasks to redo. Waiting for verified completion before releasing dependents delays them a little and avoids that rework. For running tasks one after another under this rule, see sequential AI agent tasks.

When nothing is eligible, treat that as a signal. Either work is stuck in review, or the graph has an error, such as a cycle or a prerequisite that should have been a related link.

Step 3: Keep dependencies in the task's context

An agent cannot respect a dependency it never sees. When you start a session on a task, include the prerequisite tasks' outcomes, not just their titles: the helper's name and contract, the decision that fixed the data format, the file where the shared code lives.

Include related links too, framed as constraints. "ENG-3 export also calls cents() and expects nearest-cent rounding; do not change the helper's behavior" is the sentence that would have stopped the regression in the blast radius probe before it happened.

Keep this bounded. Pasting every linked task in full fills the context with history the agent does not need. A short block per dependency (identity, status and the one or two facts that constrain this task) is usually enough, and bounded task context explains why selecting by relationship tends to beat including everything.

Write the context so it survives a handoff. The next session, or a different agent, should be able to read the task and its dependency block and know what it may and may not touch without rereading the whole plan.

Step 4: Update the graph as work is discovered

Plans change mid-task. An agent working on checkout finds that the tax module also needs truncation, or that a migration has to land first. Those discoveries belong in the graph, not in a chat transcript.

Add discovered work as a new task and choose its link type on purpose. If the current task cannot finish without it, it is a required prerequisite, and the current task is now blocked. If it is merely worth doing, link it as related and let it wait its turn. Do not let the agent start discovered work in the same session by default; new work needs the same scope review as any other task. Agent-discovered tasks covers that handoff in detail.

When a prerequisite completes, recompute eligibility for its dependents rather than starting them automatically. Completing a prerequisite changes what is ready; it should not by itself complete a parent or launch a session.

Review the graph now and then. Remove links whose reason no longer holds, and check that long-blocked tasks are blocked by something real rather than by a stale link.

QUESTIONS

What is a task dependency graph?

It is a set of tasks plus directed links saying which tasks must finish before others can start. Required links block a task until the prerequisite is done; related links only inform. Tools use the graph to decide what is ready, to order work and to show what a delay or a change will affect.

How should an AI agent choose its next task?

From the set of tasks whose required prerequisites are all done and verified, ranked by whatever priority you set. Compute that set when the choice is made, not earlier, and do not let the agent pick work outside it. If the set is empty, look for stuck reviews or errors in the graph before relaxing the rule.

Should task dependencies be required or optional by default?

Neither by default; decide each one. Ask whether the task can be finished correctly without the other one done. If not, it is required. If the other task only helps or adds context, make it a related link. Plans where everything is required stall, and plans where nothing is let agents build on foundations that do not exist yet.

RELATED GUIDES

• How to create a project card in BRAIN FLUID Desk
• Gantt planning in BRAIN FLUID: the integrated view and its prototype

RELATED HARNESS PAGES

• 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.
• Dependency cycles in AI project plans Dependency cycles in AI project plans: how agent plans create loops, why they deadlock task selection and how a planner should refuse them.
• Bounded task context Bounded task context: give an agent the slice of a project one task needs, chosen by relationship, capped in size, with omissions stated.
• 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.
• Running dependent AI tasks in sequence Running dependent AI tasks in sequence: start the next task only after a verified completion, one assignment at a time, with an explicit policy for blocks.
• Breaking a large refactor into agent-sized tasks Breaking a large refactor into agent-sized tasks: expand, migrate and contract in ordered steps that each keep the build green and have a check.