Dependency cycles in AI project plans

Dependency cycles in AI project plans happen when a chain of must-finish-first links loops back on itself, so that task A waits for B, B waits for C and C waits for A. No task in the loop can ever become ready, and any selection rule that only picks work with finished prerequisites will skip all of them, usually without saying why. Agent-generated plans produce cycles more often than hand-written ones, because agents link tasks by topic rather than by true prerequisite, and because discovered work gets attached to whatever task was open at the time. The fix is to refuse a cycle when the link that closes it is saved, naming the loop so a person can break it, rather than finding it later as a mysteriously empty queue. This page covers how cycles appear, why they deadlock and how to break one. The surrounding planning workflow is in task dependency graphs for AI agents.

How cycles get into agent-generated plans

Four patterns account for most of them.

Mutual design dependencies. "Build the API" depends on "design the schema", and the agent also makes "design the schema" depend on "build the API" because the schema must match the endpoints. Both statements are true in conversation and impossible as prerequisites.

Tests and implementation. "Write tests for export" requires "implement export", and "implement export" requires "export tests pass". The second link describes acceptance, not a prerequisite task.

Discovered work attached upward. An agent working on a child finds a gap and links the new task as a prerequisite of the parent, while the new task itself needs the child's output. Parent, child and new task now form a loop. Agent-discovered tasks covers where such work should be attached.

Merged plans. Two sessions each produce a sensible plan, and combining them adds a link between them in both directions.

Long cycles are harder to see than short ones. A three-task loop is obvious in a list; a seven-task loop across two milestones usually is not. That is why cycle checks belong in the tool rather than in a reviewer's eyes.

Why a cycle deadlocks selection

A dependency-aware selector applies one rule: a task is ready when all its required prerequisites are done. In a cycle, every task has at least one prerequisite inside the cycle, so none of them can be done first. The rule is correct, the data is wrong, and the whole loop, plus everything downstream of it, never becomes ready.

The symptom is rarely an error. It is a queue that runs dry while the board still shows plenty of open work, or an agent that reports nothing eligible to do. People then work around it: they mark one task done by hand to unblock the rest, or tell the agent to ignore dependencies. Both destroy the information the graph was built to hold, and the first records a completion that never happened.

Some tools break cycles silently, for example by ignoring the newest link or ordering by creation date. That avoids the deadlock but makes the schedule depend on an arbitrary choice nobody reviewed.

Cycles also confuse the other uses of a graph. Impact queries can loop or stop early, critical-path calculations have no answer, and a timeline cannot place a task whose start depends on its own finish.

How a planner should refuse cycles

The right moment to catch a cycle is when the closing link is saved. The check is cheap: before adding "A depends on B", confirm that A is not already reachable from B by following prerequisite links. If it is, refuse the edit.

A good refusal does three things. It names the loop, listing every task on the path, so a person can see which link is false. It leaves the plan unchanged, rather than saving the link and marking the plan broken. And it applies to every route that writes links: the planning form, the timeline view, imports, scripts and agents. A check enforced by only one form is bypassed the first time an agent writes links another way.

Agents should get the same refusal as people, with the loop in the message, so they can propose a fix rather than retry. Give them a rule in the task instructions as well: a prerequisite is a task that must be finished first, not a task that is merely related.

Timeline views need the same guard, since a task whose start depends on its own finish cannot be placed. The integrated Gantt view in BRAIN FLUID refuses cycles when dependencies are saved, as one of its tested refusals of invalid changes [N12].

Breaking a cycle you already have

Once the loop is listed, look for the link that describes a relationship rather than a prerequisite. There usually is one.

Split a task. "Design the schema" and "build the API" become "agree the interface", with no prerequisites, and then schema and API both depend on it. The shared decision moves into its own task and the loop disappears.

Downgrade a link. If one link means "should be consistent with" rather than "must be finished before", turn it into a related link. It still carries the information without blocking anything.

Move acceptance out of the graph. "Implementation requires tests pass" is a completion check on the implementation, not a task dependency. Put it in the task's checks.

Merge tasks. If two tasks genuinely cannot finish without each other, they are one task. Merge them and give the result one set of checks.

After the fix, rerun selection and confirm the loop's tasks become ready in the order you expect. If the agent that created the plan is still working, tell it which link was removed and why, or it may add it back. The same reasoning applies to parent and child tasks that require each other.

QUESTIONS

What is a circular dependency in a project plan?

It is a loop of prerequisite links, such as A waiting for B, B waiting for C and C waiting for A. No task in the loop can start first, so none of them ever becomes ready. In a plan it usually means one link describes a relationship or a shared decision rather than a real prerequisite.

How do I find a dependency cycle in a task list?

Follow prerequisite links from each blocked task and record the path; if you reach a task already on the path, you have found a cycle. Tools do this with a depth-first search or a topological sort, which fails exactly when a cycle exists. A queue that is empty while open work remains is the usual first symptom.

Why do AI agents create circular task dependencies?

Agents often link tasks that are related by topic, treat acceptance conditions like tests passing as separate prerequisite tasks, and attach discovered work to whatever task was open. Each link looks reasonable on its own. Asking the agent to list only tasks that must finish first, and refusing cycles at save time, removes most of them.

RELATED GUIDES

• 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.
• 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.
• Gantt planning for AI-assisted development Gantt planning for AI-assisted development: when a timeline helps with dependencies and deadlines, when it misleads, and how to treat undated work.
• 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.