Back to blog
Deep DiveFebruary 8, 2026

Task Dependencies Done Right for AI Workflows

By Viktor Broegger

When a human project manager looks at a Kanban board, they instinctively understand that "design the database" should happen before "build the API." AI agents don't have that instinct. They need explicit dependency graphs.

Why dependencies matter more for agents

Human developers use context, experience, and common sense to sequence their work. An experienced developer knows not to start building the frontend before the API contract is defined, even if nobody explicitly told them.

AI agents operate differently. They're literal executors. If you give them a list of tasks without dependencies, they'll start on whatever looks most relevant based on priority and description alone. For a single agent, this is usually fine. For multiple agents working in parallel, it's a recipe for wasted work and conflicts.

How AgentTask models dependencies

Dependencies in AgentTask are directed edges in a graph. Task A "blocks" Task B means B cannot start until A is done.

POST /api/v1/projects/{project}/tasks/{task}/dependencies/{depends_on}

The system enforces a few rules:

  1. No circular dependencies. If A blocks B, B cannot block A (directly or transitively).
  2. Blocked tasks are invisible to tasks_next. An agent calling tasks_next will never receive a task whose dependencies aren't all completed.
  3. Status changes cascade. When a task completes, newly unblocked tasks become available immediately.

Practical patterns

The pipeline pattern

Schema Design → API Implementation → Frontend → Testing → Deploy

Each step depends on the previous one. Simple and linear.

The fan-out pattern

                    ┌─→ Backend Tests
API Implementation ─┤
                    └─→ Frontend Build

After the API is done, both testing and frontend work can proceed in parallel.

The fan-in pattern

Backend Tests  ─┐
                ├─→ Deploy to Staging
Frontend Build ─┘

Deployment waits until both branches complete.

Combined

Real projects combine all three patterns. AgentTask's dependency graph supports arbitrary DAGs (directed acyclic graphs), so you can model any workflow structure.

The tasks_next algorithm

When an agent calls tasks_next, the system:

  1. Filters to tasks with status pending
  2. Excludes tasks where any dependency is not done
  3. Respects assigned_agent if the caller specifies one
  4. Respects session_id if the caller specifies one
  5. Sorts by priority (critical > high > medium > low)
  6. Returns the top result

This is deliberately simple. Complex scheduling algorithms create unpredictable behavior. A priority queue with dependency constraints gives agents exactly the information they need: "what should I work on next?"

Tips for setting up dependencies

  • Define dependencies when creating tasks, not after. It's much easier to set up the graph upfront than to retrofit it.
  • Don't over-constrain. Only add a dependency if there's a genuine ordering requirement. Too many dependencies create bottlenecks.
  • Use the dependency graph visualization in the AgentTask dashboard to spot issues. Look for long chains (bottlenecks) and disconnected subgraphs (potential parallelism you're not exploiting).
  • Keep the graph shallow. Deep dependency chains (A→B→C→D→E→F) mean agents spend most of their time waiting. Prefer wider, shallower graphs with more parallel paths.

Dependencies are the simplest form of coordination, but they're remarkably effective. Get them right, and your agents will work together like a well-oiled machine.

All posts