How to break a big task into subtasks with AI

"Redesign onboarding" is not a task an AI agent — or most people — can just start on. It's a goal wearing a task's clothes. The fix isn't a better prompt; it's turning one oversized item into several concrete ones an agent can actually claim, work, and finish one at a time.

Why big tasks stall

A task that's really five tasks tends to sit at the top of a queue doing nothing, because nothing about it says what to do next. Humans procrastinate on it; agents either freeze on the ambiguity or — worse — guess, do something plausible-sounding, and report back a result that technically touches the title but misses the point. Decomposition fixes both failure modes the same way: by replacing one vague thing with several unambiguous ones.

How decompose_task works

decompose_task breaks a task into several subtasks in a single call, each one a real task in its own right — assignable, schedulable, and workable independently. Point an agent at the oversized task and ask it to decompose first; you get back a set of concrete children instead of one paragraph nobody's going to act on.

From subtasks to a plan

Subtasks alone don't tell you the order or the shape of the work. render_plan lays a task's sub-steps out three ways at once: a markdown checklist you can read at a glance, structured JSON for tooling, and an interactive widget for MCP hosts that render it — call it right after decompose_task or propose_plan to turn a pile of subtasks into something that reads like an actual plan.

Checking off steps as they happen

set_step_status checks a sub-step off or reopens it, returning the refreshed plan — the natural action when you tell an agent a step is done, or you toggle it yourself in the widget. One detail matters here: an agent marking its own non-agent_ok step still routes through the approval gate rather than closing it directly. Decomposition doesn't create a shortcut around approval; it just makes each unit of work small enough to approve quickly.

Propose the plan before you commit

For anything substantial, the better sequence isn't decompose-then-go — it's decompose, then propose_plan, and wait. The task moves to plan_proposed and sits out of the ready queue until you approve_plan (work begins) or reject_plan (back to not started, with your feedback folded in). You're reviewing the approach before any effort is spent on it, which is a cheaper place to catch a wrong assumption than after the work's already done.

A worked example

"Redesign onboarding" becomes, after decompose_task: audit the current flow, draft three options, get feedback, build the winner, write the docs. render_plan turns those five into a checklist with an order. propose_plan lets you sign off on that order — maybe you move "get feedback" earlier — before anything's built. Then each subtask gets claimed, worked, and checked off (or routed to approval) on its own, instead of one enormous task sitting untouched for a month.