Agent task trees explained: how to keep multiple AI agents on one plan

An agent task tree is a project plan whose nodes are tasks an AI agent can claim, work, and complete. The plan of record lives in a structure the agents read and update themselves, not in a chat log that scrolls away.

Moving the plan out of the conversation and into a tree is what makes more than one agent on one outcome survivable. Here is the reasoning, the mechanics and the limits.

Why a chat log is not a plan

Chat is a good place to think and a bad place to keep track. Three of its properties break down as soon as a second agent joins.

It is append-only. Today's state sits somewhere in the middle of the thread, surrounded by intentions that no longer apply. To answer "what is left?" you have to read all of it.

It has no ownership boundary. Two agents sharing a thread can both edit the same thing, and nothing tells a third agent that either of them is busy.

It forgets. Long threads get summarised or truncated. A decision taken at message 400 is gone by message 900, so the same argument comes back.

None of this is a model problem. It is a storage problem. The plan is living in a medium built for talking.

What an agent task tree actually is

A task tree is a project broken into tasks, and every task can have sub-tasks, to any depth. The root is the project. Its direct children are the main branches of work, and their children are the steps. Two or three levels is usually right. Ten levels means the work wants to be its own project.

What matters is not the nesting. It is that agents read and write the tree. An agent does not get a paragraph of instructions. It gets a node, the path to that node, and the branch beneath it. Work is named by number and title ("Task 2.6, Blogger: three posts"), not by "the blog thing we discussed".

Two things follow.

The tree is legible to a machine without translation. The structure already encodes the intent, so nothing has to be parsed out of prose.

The tree is legible to a person at a glance. Anyone can open it and see what is done, what is claimed and what is stuck.

Four things a tree carries that chat cannot

1. A branch: the ownership boundary. A node is a fence, not just a label. When an agent holds a task, that task and everything under it are theirs to change. Nothing outside it is. This is what stops two agents editing the same work.

2. A claim: who is busy, and with what. Before starting, an agent claims the task and writes one sentence on how it will tackle it. That sentence goes to whoever is watching the board. Claims are exclusive and held one at a time, so "who is doing this?" always has an answer.

3. A standing brief. Claiming a task returns more than the task. The agent gets the project's standing brief, its place in the tree, the branch with its ids, the durable project memory and the active sprint. The brief gets rewritten as the team learns, never appended to, so an agent starting today reads a briefing rather than a diary.

4. Memory and decisions that outlive a session. Two records sit alongside the tree. One is durable project memory: context and guardrails, each marked proposed or approved. The other is decisions: one line on what was settled, plus the reasoning and what was rejected. Decisions are cheap insurance against a new agent reopening a closed question.

The claim, work, report loop

Three moves. This is the part that changes behaviour.

Claim. The agent claims the branch and says how it will tackle it. It gets back the brief, the branch and the current state of the project.

Work. It works inside the claimed branch. If it needs sub-tasks, it adds them where everyone can see them.

Report. It completes each finished piece as it goes, one at a time, with a sentence on what changed. If it gets stuck it releases the branch and says why. Releasing is a normal outcome. A lock nobody can explain is worse.

The cadence matters more than it looks. Completing tasks as they finish keeps the tree honest. Batching all the completions at the end makes the board fiction for the whole middle of the job.

Why progress should be derived, not reported

This is the design choice most worth copying.

Progress comes from the tree and is never set by hand. A parent shows the proportion of its descendants that are done. You complete a parent by completing its children, not by ticking the parent.

That closes one specific failure. Self-reported status is optimistic, and agents are no exception. An agent that has "mostly finished" six things has finished none of them. Derived progress removes the judgement call: the number on the parent is arithmetic over the leaves, and the leaves are the tasks that had to be done.

It also makes the tree self-auditing. If a parent reads 60% and you do not believe it, open it and count the open leaves. There is nothing to argue about.

How much should the tree enforce?

A boundary only helps if it holds. Teams want different amounts of holding, so the useful model has three settings.

Off. Nothing is checked. Fine for one trusted agent on a scratch project.

Guided. Nothing is refused, but a call made out of sequence comes back with the correction attached. This is the sensible default.

Strict. A write outside the branch you have claimed is refused. This is what you want when several agents share one tree and you cannot review every action.

Enforcement is a dial, not a personality. Turn it up as the number of agents rises and your tolerance for surprise falls.

When a task tree is the wrong tool

A tree earns its cost when the work is multi-step, multi-agent, or too long for one context window. Otherwise it is overhead.

One agent doing one thing in one sitting is faster in a chat. Work that is genuinely linear has a better shape: a checklist. And a tree will not rescue a vague objective. If you cannot say what "done" means for a leaf, you will get a lot of leaves that never close.

FAQ

Is an agent task tree just a project management tool?
No, though it borrows the shape. Three differences matter: agents are first-class users, a branch can be exclusively claimed, and progress is derived from the leaves instead of typed in by a person.

How is this different from a longer prompt?
A prompt is a snapshot of intent taken at one moment. A tree is state. It survives the context window, every agent that touches it updates it, and a person can read it without translation.

What stops two agents colliding?
The claim. One at a time per agent, exclusive per branch. Under strict enforcement, nothing outside the claimed branch is writable: the system refuses the write instead of trusting a convention.

Do I need this for one agent?
Usually not for one sitting. You need it once the work will not fit in a context window, or once a second agent has to pick up where the first stopped.

Method note

Every product behaviour described here comes from LatticeRun's own working guide: derived progress, exclusive claims, the standing brief, the three enforcement levels, the claim/work/report loop. No performance, pricing or adoption figures are claimed, because none are verified. The general argument about chat is structural, and you can check it against your own transcripts.