# How do you manage task dependencies between AI agents without holding the order in your head? > Write the prerequisite on the work itself and derive startability from it every time. When a prerequisite finishes, everything behind it is released without a person handing out the next card. ## We handed out two cards at once and one of them invented the column names One job changed the schema. The other added an API on top of it. Both were untouched, so we handed them to two sessions at the same time. Half an hour later the API session had picked its own column names and finished. The schema session had used different ones. The diffs collided and we threw one away. The prompt we gave the API session never said that the schema comes first. The only place that was written down was our heads. This is not complicated. Some work cannot start until other work is finished. Schema, API, screen. There is an order. The order just is not stored anywhere, except in someone's memory and in the wording of whatever prompt they typed that morning. As long as a person is the one who remembers that B comes after A, that person is the one who hands out B. Faster models mean more handing out, not less. When a prerequisite finishes at two in the morning, the card behind it sleeps until morning. ## For a long time the order lived inside the prompt In the order we tried them. Every one of these worked up to a point. First we put everything in one session. Schema first, then the API once it passes, then the screen. That works, reliably. If the whole thing fits in one session we still do exactly this. The moment we split it across two sessions, the order appears in neither prompt. Then numbered TODO lists. A human reads 1, 2, 3 as an order. An AI that does 3 first is not stopped by anything. The numbers turned out to be a preference, not a constraint. We also wrote "blocked by #12" in GitHub Issues. It persists, it has a number you can say out loud, and another AI can read it. The problem comes after you close #12. Nothing notices that #13 was just released. Until someone goes and looks at the comment thread, #13 sits there. Board columns (Todo, Doing, Blocked) were next. A column can hold state, so we could see that something was stuck. What it cannot hold is what the thing is stuck on. With seven cards in Blocked, finding which one got unblocked today means opening all seven. In the end we dispatched by hand. A session reports done, we hand it the next thing. This was the most accurate option by far. Accurate, and stopped whenever we were asleep or in a meeting. ## Where we ended up as the dispatcher again Finding somewhere to write the order down was never the hard part. A prompt, a list order, a comment on an issue, the name of a column, our own memory. It lands somewhere. The only one another AI cannot read is the copy in our heads. They all got stuck in the same place. Nothing releases the work behind a prerequisite at the moment it is satisfied. Every release starts with a person going to look. More parallel sessions only meant more of that looking. ## We let the AI do the splitting, then got stuck after the split For anything big we talk it through with ChatGPT and then say: put the smallest next tasks in. The AI splits faster than we do. We usually get five to ten cards out of it. That count is typical for us, not a measurement. The trouble starts after the split. Of ten cards, two or three can be touched right now and the rest are waiting on something. Only we know which two those are, and only in the minutes right after the split. By the next day we do not know anymore. Between our own product and client work we move between three or four projects in a single day. Rebuilding the "what is next here" picture per project, from memory, was simply not happening. Granularity bit us too. A card like "fix the auth flow" does not finish in one session. Put a card like that in front of others and everything behind it stalls for a long time. Split too finely and all you have is a pile of prerequisites, which we stopped reading ourselves. Our current rule of thumb is: one card should finish in one session. Also a rule of thumb, not a measured number. ## How we designed it in Dazbench We wanted three things. The prerequisite written on the job itself. A bad prerequisite rejected by the tool, not discovered later. And a prerequisite that finishes releasing the work behind it without going through a person. So the prerequisite is stored in exactly one place, and whether a card can start is never stored at all. It is worked out from the prerequisites every time. A stored answer drifts, and nobody notices it drifted. 1. On the later piece of work, add a line: this one comes after dz12. It can only point at cards in the same project, and the card number is all you need. Up to 20 per card. 2. Orders that cannot work are rejected on save: a card pointing at itself, a number that does not exist, and loops (A waits on B while B waits on A). Cards with no project (Inbox) cannot carry prerequisites at all. 3. A prerequisite counts as satisfied only when its status is done. Archived also counts as satisfied, because a card you filed away blocking everything behind it invisibly is the worse failure. 4. When we start a session we say: take whatever can be started. The AI only gets back the cards whose prerequisites are all finished and that nobody has picked up. Work already under way, work a person stopped, work still waiting on a prerequisite, and work whose prerequisite no longer exists come back in separate groups, so it cannot take one of those by mistake. 5. The cards in that first group are independent of each other, so the whole group can go out to several sessions at once. Nobody has to check whether two cards can safely run together. 6. A card a person stopped does not become startable again when its prerequisites clear. It stays stopped. An AI does not get to override a human decision just because the dependency resolved. 7. On screen the same thing shows up as a route view in three tiers: in progress, can run in parallel, waiting on prerequisites. A waiting card carries the numbers it is waiting on, printed on it. If we tell a session to gather everything that can run in parallel, that is all it gets. That is the point where we stopped being the dispatcher. ## What actually changed Work no longer sleeps from two in the morning until someone wakes up. If a prerequisite finished overnight, a session asks for what can be started and takes the next card itself. Handing the same card to two sessions got rarer. Everything that comes back as startable is independent, so the group can go out together without colliding. Hand out one card from outside that group and we can still cause exactly the original accident. The work of remembering what comes next mostly went away. That memory now lives on the cards, so moving between projects does not mean rebuilding the order in our heads. Not measured. It is how it feels. > The unsolved parts, plainly. Dependencies are only as good as the ones we wrote down. A prerequisite we forgot is not reported by anything, and nothing will reject it: only impossible orders are rejected, like a card pointing at itself, an unknown number, or a loop. Dependencies cannot cross projects. Inbox cards cannot carry them, so ordered work has to move into a project first. And startable does not mean important. Deciding which of them matters most is still a human job. If a card is too big to finish in one session, adding a dependency only makes the waiting longer. ## FAQ ### Should you let an AI decide the dependencies? For the splitting, yes. Breaking a large piece of work into the smallest next tasks and attaching prerequisites is faster when the AI does it. We still read the prerequisites afterwards. A forgotten one is not something the tool can catch; it only rejects impossible orders such as a card depending on itself, an unknown number, or a loop. ### Doesn't adding dependencies stop you running things in parallel? It went the other way for us. Cards whose prerequisites are all finished are guaranteed to be independent of each other, so that whole group can go out to several sessions at once. Without dependencies we were the ones working out, every time, whether two cards were safe to run together. ### How large should one card be? Our rule of thumb is a card that finishes in one session. Put a card that cannot finish in one session in front of others and the work behind it stalls for a long time. Split too finely and there are so many prerequisites that the order becomes unreadable. Both are our own experience, not measured numbers. ## Related - Turn a requirements doc into work an AI can actually execute: https://dazbench.app/tips#spec-to-cards - Check only the work that's stalled: replies, payments, reviews: https://dazbench.app/tips#whats-stuck - Let the AI choose today's work from deadlines and decision load: https://dazbench.app/tips#pick-todays-work - Status: https://dazbench.app/manual#words/status - What you can hand over: https://dazbench.app/manual#ai/can-do - How do you stop telling Claude Code what to work on next?: https://dazbench.app/docs/stop-telling-claude-code-whats-next - Why does running several Claude Code sessions in parallel get unmanageable?: https://dazbench.app/docs/why-parallel-claude-code-gets-unmanageable Updated: 2026-09-12 --- The latest version of this file is always at https://dazbench.app/docs/ai-agent-task-dependencies-without-a-human-in-the-loop.md. The version for humans to read is at https://dazbench.app/docs/ai-agent-task-dependencies-without-a-human-in-the-loop.