Blog · July 28, 2026

How to structure a task graph an agent can actually work from

Most teams give an agent a task the same way they'd give one to a new hire: a title, maybe a paragraph of context, and a Slack message that says "go." That works once. It stops working the moment the task has a prerequisite, or a second agent picks up the adjacent piece, or the agent finishes and you have no way to tell whether "finished" means what you think it means.

This is the practical half of agent task management — not what the category is, but how you actually lay out work so an agent can walk in cold and do the right thing next. Four habits cover almost all of it: priority that means something, dependencies as real edges instead of a sentence in the description, a reason attached to "blocked," and a bar for "done" that isn't just a status flip.

Priority is a tiebreaker, not a mood

A number from 0-4 on every task sounds like busywork until two things are true at once: an agent has more than one ready task in front of it, and nobody is standing over its shoulder to say which one matters. At that point priority is the only signal deciding what gets picked up next, so it has to mean the same thing every time you set it — not "this feels urgent today" but "this blocks more downstream work than that one does."

The failure mode isn't setting priority wrong once. It's setting it once and never touching it again. A P1 from six weeks ago that got quietly superseded by newer, more pressing P1s is worse than no priority at all, because it still outranks everything at P2 on a tie. Revisit priority when the picture changes, the same way you'd re-triage a real backlog — not on a schedule, but when something makes the old ranking stop being true.

Dependencies are edges, not sentences

"This needs the auth work done first" in a task description is a note to a human. An agent reads task descriptions selectively — it's optimizing for the fastest path to "ready," and free text describing a prerequisite is easy to miss or misjudge as already satisfied. A real dependency edge isn't optional to notice: the task simply isn't ready until the thing it depends on is done, full stop, enforced by the system rather than by the agent's reading comprehension.

This matters more as the graph grows. Five tasks with prose dependencies are usually fine because a careful agent (or a careful human) can hold all five in their head. Fifty tasks with prose dependencies means someone eventually starts a task whose prerequisite silently changed, and the mistake doesn't surface until the two pieces of work collide. Model the dependency once, as an edge, and every future agent that queries "what's ready" gets the right answer without having to reconstruct your reasoning from a sentence.

"Blocked" needs a reason, or it's a dead end

A task sitting in a blocked state with no explanation is a worse outcome than a task that was never tracked at all. An agent that hits it has two options: guess, or stop. Guessing risks doing the wrong next thing; stopping means the task sits there until a human happens to notice and investigate — which, on an unattended cadence, might be a while.

The fix is boring and worth doing anyway: when a task can't move forward, the reason it can't goes in the same place the status does. Waiting on a specific dependency task, waiting on a specific decision, waiting on a credential nobody's issued yet — whichever it is, name it where the next reader (agent or human) will see it without a second query. The cost of writing one sentence is nothing next to the cost of a task silently stalling for a week because nobody could tell why it stopped.

"Done" has to survive being checked, not just declared

Self-reported completion is the single easiest thing for a task system to get wrong, because it's the path of least resistance — the agent finishes the work, calls the "mark done" tool, and moves on. Nothing forces the claim to be true. The gap between "I did the thing" and "the thing is actually done, correctly, in a way the next task downstream can rely on" is exactly where an unattended agent's mistakes hide, because there's no one watching the terminal to catch an overconfident status update in real time.

Two structural fixes close most of it. First, acceptance criteria that get set before the work starts and checked off as evidence of completion, not asserted as part of the same motion that closes the task — otherwise a single call can hand itself a passing grade and clear it in the same breath, which is worth guarding against explicitly, not just trusting won't happen. Second, evidence: a link to the commit, the PR, the artifact — something that ties the "done" claim to a concrete thing a human or a later agent can go inspect, instead of a status field that only ever says what the agent doing the work wanted it to say.

What this buys you

None of these four habits require an elaborate system. They require a task store that has priority as a real, revisitable field; dependencies as edges the "what's ready" query actually respects; a blocked-reason next to the blocked status; and a completion path that checks something instead of trusting a status flip. Put those four in place and the same task graph that one agent can barely keep straight in a single session becomes something a fresh agent, with zero memory of the runs before it, can walk into and correctly pick up the next right thing — which is the entire point of writing any of it down in the first place.

The shortest version: rank it so ties break the same way twice, wire the real prerequisite instead of describing it, say why when something stops, and make "done" something that survives being checked. Get those four right and the graph does the coordinating instead of you.

Ledgenter builds all four in as the default shape of a task — priority, dependency edges that gate readiness, a blocked_reason field, and acceptance criteria plus evidence gates on the completion path — so you're modeling the work once, not rebuilding the scaffolding around it every time.