Atomic Task Graphs: Planning Agent Work as a Dependency Graph

Most attempts to make LLM agents more reliable start with a bigger model. The Atomic Task Graph (ATG) framework, proposed by researchers at Tsinghua University and South China University of Technology, starts somewhere else: it changes how the agent structures its work. According to the paper, 7B and 8B open-source models wrapped in ATG beat GPT-4 running a standard ReAct loop on two well-known agent benchmarks, with no fine-tuning, reinforcement learning or weight updates at all. Below: why linear reasoning chains break down, how ATG replaces them with a dependency graph, and which ideas you can borrow for your own agents.

Why linear agent loops fail on long tasks

Consider a request such as "produce a 2024 sales report with charts." A typical ReAct-style agent treats this as one long sequence of steps, each depending on the one before it.

Step 1
↓
Find database
↓
Query data
↓
Analyze numbers
↓
Create graphs
↓
Write report

The chain is fine as long as every step succeeds. The trouble starts when one of them does not. If the database query fails, every later step is now built on missing or wrong data.

Database query
↓
Everything after it becomes wrong

At that point the agent can either restart from the beginning or push on with what it has. Many do the latter, which is a major source of hallucination: the model invents plausible data to fill the gap, and every later decision inherits the error.

The context keeps growing

The second problem is how these agents keep state. After each action, the thought, the tool call and the observation are all appended to one ever-growing transcript.

User
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
↓
Observation
↓
Thought
↓
Action

Eventually the model reasons over pages of history. The context gets noisy, and early mistakes stay in view, so they keep shaping later decisions. Like a game of telephone, each round slightly distorts the plan until it drifts from reality.

The core idea: a graph instead of a chain

ATG replaces the single sequence with a graph of tasks. Each node is one unit of work, and each edge records a dependency between two units.

Report
            /      \
      Analysis    Charts
       /     \
 Database   Statistics

The structure makes independence visible: unrelated work no longer waits, and a failure in one branch does not invalidate its siblings.

How ATG builds and runs the graph

The framework works in five stages.

1. Recursive decomposition into atomic tasks

Everything starts from the user's request.

Create sales report

ATG splits that goal into sub-tasks.

Create sales report
↓
Load data
↓
Analyze sales
↓
Create charts
↓
Write summary

It then keeps splitting any sub-task that is still too broad, such as the analysis step.

Analyze sales
↓
Revenue
↓
Profit
↓
Growth
↓
Regional trends

Decomposition stops when every leaf maps to a single tool invocation, for example:

SQL query
Python calculation
Matplotlib chart
Markdown writer

Those leaves are the atomic tasks: units small enough that splitting them further would not make sense. The stopping rule matters: a vague node leaves the model too much to improvise, while one SQL query has a narrow, checkable outcome.

2. Explicit inputs and outputs for every node

Each node is given an interface, much like a function signature. Rather than an instruction such as "do the analysis," the planner describes what the node consumes and what it produces.

def analyze_sales(data):
    return summary

The snippet is illustrative, not framework code, but it shows the contract. Because the graph depends only on that contract, a node can be retried or swapped for another tool without its neighbors noticing, the same property that makes modular code maintainable.

3. Parallel execution of independent branches

A sequential agent runs tasks one after another even when some of them are unrelated.

Task A
↓
Task B
↓
Task C

If B and C only need A's result and not each other's, ATG can express that directly.

Task A
       /     \
 Task B     Task C
       \     /
       Task D

B and C can then run at the same time, with D waiting for both. The paper reports noticeably shorter execution paths across all the benchmarks it evaluated, which follows naturally from collapsing independent steps into parallel ones.

4. A dry run before touching real tools

Before executing anything, ATG simulates the whole plan internally, essentially asking the model whether the plan would work if it were carried out as written. The simulation looks for:

• steps that are missing
• the wrong tool assigned to a node
• incorrect dependencies between nodes
• interface mismatches, where one node's output does not fit the next node's input
• execution paths that cannot actually be completed
• violations of the task's constraints

It is the agent equivalent of running tests before deploying, and it is cheap because no external tool is called. The check is only as good as the model running it, though: the model that wrote the plan can share its blind spots, so treat it as a filter, not a guarantee.

5. Targeted repair of the broken subgraph

The most distinctive stage is how ATG handles failure at run time. Take a simple graph:

Database
↓
Analysis
↓
Charts
↓
Report

Suppose the analysis node fails. A conventional agent often reacts by discarding its progress and starting again.

Database
↓
Analysis
↓
Charts
↓
Report
↓
Start over

ATG instead keeps the same graph and freezes every node that already produced a valid result. The diagram below looks identical to the original on purpose: the structure does not change, only the analysis node is marked for rework while the database, chart and report nodes stay as they are.

Database
↓
Analysis
↓
Charts
↓
Report

Only the failed subgraph is regenerated, and once it succeeds the graph continues with the new result.

Database
↓
New Analysis
↓
Charts
↓
Report

This is incremental compilation applied to planning. Note that if the repaired analysis produces different numbers, downstream nodes that consume it must still rerun; what is spared is upstream work and unrelated branches.

Why smaller contexts mean fewer hallucinations

In a ReAct loop every step sees the full history. In ATG each node receives only the inputs its interface declares, so there is less noise and less room for earlier errors to leak in.

The paper quantifies this on ALFWorld:

• with ReAct, 42.86% of trajectories contained hallucinated actions
• with ATG, that fell to 12.14%

That is a relative reduction of roughly 72%, achieved without changing the underlying model.

What the benchmarks show

The evaluation used three open models:

• Mistral 7B
• Gemma 7B
• Llama 3 8B

and three agent benchmarks:

• ALFWorld
• WebShop
• ScienceWorld

The headline comparison pairs Llama 3 8B with ATG against GPT-4 with ReAct. On ALFWorld, the GPT-4 baseline scored:

GPT-4 + ReAct
41.24

while the small model with ATG scored:

Llama 3 8B + ATG
63.65

On WebShop, the GPT-4 baseline reached:

GPT-4 + ReAct
64.34

and Llama 3 8B with ATG reached:

Llama 3 8B + ATG
68.36

These are the paper's reported numbers. The GPT-4 figures are for a ReAct baseline, so the comparison shows how much structure can compensate for model size, not that an 8B model is generally stronger than GPT-4.

Why the idea resonates with software engineers

The industry's default strategy has been to scale models, clusters and budgets. ATG asks how to organize the work better instead, which is a software engineering question more than a machine learning one. It echoes Git, dependency graphs, build systems, task schedulers, compiler optimization and distributed systems. Most software stopped being strictly sequential long ago; agents are catching up.

A concrete example: building a website

Ask an agent to build a website, and a linear agent tends to produce a plan like this:

Think
↓
Write HTML
↓
Write CSS
↓
Write JavaScript
↓
Debug
↓
Deploy

An ATG-style planner might instead produce a tree of independent pieces:

Website
│
├── HTML
├── CSS
├── Images
├── API
└── Tests

Each branch can be developed separately. If the CSS breaks, only the CSS node is regenerated. It sounds obvious, yet most agents today do not work this way. Related defensive patterns are covered in an architecture against hallucination compounding in agent graphs.

When a task graph is not worth it

Planning, simulation and node bookkeeping add overhead. For tasks of two or three tool calls, a plain ReAct loop is simpler. The graph pays off when tasks are long, partly independent and expensive to restart, and only if the planner decomposes sensibly: a bad graph executed efficiently is still a bad plan.

Key takeaways

• Linear loops let one failed step corrupt everything after it, and growing transcripts amplify early mistakes.
• Atomic nodes with declared inputs and outputs make plans parallel, checkable and repairable.
• A dry run catches structural errors before real tools are called; targeted repair avoids full restarts.
• Narrow per-node context is the easiest idea to reuse, and it drives the reported drop in hallucinations.
• Better workflow structure is a lever alongside model size, and often a cheaper one.