---
title: 'Planning, decomposition & work admission'
description: 'Breaking work into runs, and giving every run a contract before it is admitted.'
canonical_url: 'https://darkfactory.dev/factory/planning-decomposition'
markdown_url: 'https://darkfactory.dev/factory/planning-decomposition.md'
collection: factory
date_published: '2026-07-16T00:00:00-04:00'
date_modified: '2026-08-09T00:00:00-04:00'
---

# Planning, decomposition & work admission


**Confidence: medium.** *Evidence: benchmark and case study.* *Last substantive change: 2026-08.*

A goal must become bounded runs before any agent starts. Each run needs declared inputs, authority, evidence, budget, and a stopping condition.

## The conclusion

**Decomposition should be revised at runtime based on evidence, not fixed up front, and every admitted run needs a contract.** That contract states a goal, scope, non-goals, budget, permissions, a stopping condition, the evidence it must produce, and an escalation path. When a plan is useful, prefer vertical slices that produce testable behavior over horizontal layers that postpone integration. Runtime branching beats static decomposition because fixed task graphs prove brittle the moment reality diverges from the plan.

## How the thinking got here

Static task graphs and elaborate agent personas gave way to managed queues, runtime branching, and explicit run contracts. The empirical result that moved the field was that static decomposition can increase retry cost, while runtime branching, deciding the next step from what the last step actually produced, is the active lever. A practitioner [retraction of Research-Plan-Implement](https://www.youtube.com/watch?v=YwZR6tc7qYg) adds a complementary warning: code-sized plans and horizontal phase plans can consume the same review effort as the implementation while still deferring end-to-end truth. It recommends separating factual research from the goal, reviewing a smaller design artifact, and expressing workflow in deterministic control flow rather than a monolithic prompt.

## Credible alternatives, and when each is right

| Approach | Right when |
|---|---|
| Single long-horizon agent | small, coherent tasks |
| Planner and executor split | plan and execution benefit from different context |
| Static DAG | stable, well-understood pipelines |
| Dynamic branching | outcomes are uncertain and evidence should steer |
| Market or auction allocation | many independent units of work |
| Human dispatcher | high-stakes prioritization |

## Where it fails and what we still don't know

Failures cluster around coordination: priority inversion, starvation, duplicate work, runaway loops, instruction-heavy plans that agents do not follow, and work admitted without a stopping condition. Evidence is moderate to strong for dynamic task management and weak for claims that elaborate role-playing organizations outperform simpler loops. Open questions include admission control, work-in-progress limits, cancellation, and optimal decomposition by task topology.

## What would change our mind

Controlled evidence that a fixed organizational structure reliably beats runtime branching on real, varied work would reopen the static-versus-dynamic question.

## Evidence and further reading

- [Runtime-Structured Task Decomposition](https://arxiv.org/abs/2605.15425)
- [Agentic Autonomy Levels](https://addyosmani.com/blog/agentic-autonomy-levels/)
- [Codex Orchestration (Symphony)](https://openai.com/index/open-source-codex-orchestration-symphony/)
- [Beyond Individual Intelligence (LIFE)](https://arxiv.org/abs/2605.14892)
- [Everything We Got Wrong About Research-Plan-Implement](https://www.youtube.com/watch?v=YwZR6tc7qYg)