AI Agent Task Decomposition: Breaking Work Into Tasks an Agent Can Finish

AI agent task decomposition is the step between a goal and the cards an agent works from: cutting “customers can pay invoices online” into a handful of small tasks, each of which delivers one checkable outcome in one sitting. Slice by outcome rather than by activity or by layer, prefer thin vertical slices that work end to end, write down which cards depend on which, put them in Next Up in the order they must be done, and let the agent propose the split while a person approves it before anything is filed. Get the split right and each card is easy to write, easy to finish and easy to review.

This post is about the split, not the single card. Once you have the pieces, how to write a task for an AI agent covers what each card should say, and AI agent task examples has twenty finished ones to copy.

Why agents need the split more than people do

Give an experienced colleague a goal and they break it down in their head, check in when a piece turns out bigger than expected, and stop when something needs a decision. An agent handed the same goal usually starts at the top and keeps going. It makes every intermediate decision itself, touches every layer at once, and comes back with one large change that is hard to review and harder to undo in part. Small cards turn that into a series of reviewable steps, each with its own evidence, and give you a place to stop between them.

Slice by outcome, not by activity or layer

There are three common ways to cut a goal, and only one suits agents.

• By activity: research, design, build, test. Each card is an activity with no end state, and none of them produces anything a user can see. “Research payment providers” can go on for ever.
• By layer: database, API, screen. Each card is finished only in the sense that it compiles; nothing works until all three land, so nothing can be checked until the end.
• By outcome: each card leaves the product able to do one more thing, however small. “An invoice page shows a Pay button that opens a checkout for the right amount” is either true or not.

Outcome slices are usually vertical: they cut through every layer they need, thinly, so the result works end to end. The first slice is often embarrassingly small, with a hard-coded value or only one case handled. That is the point. It proves the path works, and every later slice widens it.

A worked example

Goal: customers can pay invoices online. Cut by layer, it is three cards that must all land before anyone can check anything. Cut by outcome, it looks like this:

FET-101  An unpaid invoice shows a Pay button; it opens a test
        checkout for the invoice total (card only, one currency)
FET-102  A successful payment marks the invoice Paid
BUG-103  A failed or cancelled payment leaves it Unpaid and says why
ENH-104  Checkout works for invoices in every currency we bill in
FET-105  The customer receives a receipt email after paying
ENH-106  Paid invoices show the payment date and method

Each card is one outcome with its own check. FET-101 can be reviewed on its own by clicking a button. BUG-103 is filed as a bug-shaped piece of work from the start, because handling failure is its own outcome and is easy to forget. And the order is visible: nothing after FET-102 makes sense until a payment can succeed.

How small is small enough

The working test is one sitting: one change, one area, one set of evidence you can review in about fifteen minutes. Keep splitting while any of these is true:

• The card has two outcomes joined by “and”.
• You can already predict a decision it will need halfway through. Make the decision first, or make it a card of its own.
• It cannot be checked without another card also being finished.
• You would not know where to start reviewing it.

Stop splitting when a card no longer delivers anything checkable on its own. “Add a column to the invoices table” is below that line: it is a step inside a slice, and belongs in that card’s plan, not on the board as a card of its own.

Recording dependencies

Some slices cannot start until another is done. Write that down where the agent will read it, or it will pick up whichever card looks most interesting.

On fenbs, related tasks are linked both ways: in a task’s editor, or over MCP with relatesTo on fenbs_create_item and fenbs_update_item (and unrelate to remove a link). A link says the cards belong together, and each shows the other. It does not say which comes first, so state the order in words in the Problem box of the later card: “Starts after FET-102 is Completed; needs the Paid status it adds.” An agent reading FET-105 with fenbs_get_item sees both the link and the sentence.

Keep chains short. If every card depends on the one before, the agent can only ever work on one thing and a single stuck card stops the lot. Where you can, reshape slices so two or three can proceed independently.

Ordering the slices in Next Up

The split lands in To Do. A person then moves the slices that are ready into Next Up, in the order they should be done, and the agent takes work only from the top of Next Up. That keeps the decision about what is next with a person, which kanban for AI agents explains as a lane policy.

• Put the slices a person can check soonest at the top. Early evidence tells you whether the rest of the split is right.
• Use the lane’s Shared order sort (Custom on a personal board) for the exact order. On fenbs, dropping a card onto another puts it directly above, and the order is shared, so every person and assistant on the board sees the same sequence.
• Use priority for urgency, not sequence. Priority runs 1 to 10, with 1 the most urgent; two slices of the same goal usually share a priority and differ only in order.
• Only move a slice to Next Up once whatever it depends on is done or under way. A card in Next Up should be one an agent could start now.

Let the agent propose, and a person approve

Agents are good at producing a first split: they read the code or the documents, list what has to change, and group it. They are less good at knowing which slice matters to a customer or which trade-off you would accept. So divide the work the same way: the agent proposes, a person edits and approves, and only then is anything filed.

Read FET-100 "Customers can pay invoices online" and the code under src/billing.
Propose a split into vertical slices: each one a single outcome a person could
check in a browser, small enough for one session.
For each slice give: kind (feature, enhancement or bug), a one-line outcome,
the check, and which other slices it depends on.
Write the proposal into the plan on FET-100. Do not create any tasks yet.

Writing the proposal into the parent card’s plan keeps it on the board where others can read it, and a plan is replaced whole each time it is rewritten, so the latest version of the split is always the one showing. If you are working in Claude Code, plan mode gives you the same pause before anything changes.

Read the proposal with three questions: does each slice deliver something checkable, is anything missing (failure cases, permissions, empty states), and is the order right? Edit it. Then tell the agent to file the approved slices with fenbs_create_item, each linked to the parent with relatesTo. If a slice looks like a task already on the board, fenbs files nothing and returns the likely matches with created: false, so the agent can comment on the existing card instead of adding a duplicate.

If you would rather file the slices yourself, fenbs’s Add many box, next to + New task, takes one task per line or a markdown list. A line starting bug:, feature: or enhancement: sets its kind, indented lines become that task’s note, and everything is previewed before anything is created.

Signs the split was wrong

• Slices keep coming back half-done. They were still too big, or hid a decision; split the remainder rather than retrying.
• The agent keeps filing new cards while working a slice. The split missed something, usually a layer or a failure case. Add it to the plan on the parent.
• Reviews take longer than the work. The slices are not checkable on their own; recut them around outcomes a person can see.
• Everything waits on one card. The dependency chain is too long; look for slices that can go in parallel.