Mission Decomposition

Problem

Some jobs — writing thirteen concept files, or building a whole documentation site — are too big for any one agent session to finish in one go. Without a plan that breaks them into smaller pieces, agents either bite off more than their context window can hold or wander without direction and duplicate each other’s work.

Solution

Decompose large tasks into missions, each containing objectives that fit a single session (§9). The execution hierarchy is:

Campaign → Mission → Objective
(strategic)  (tactical)  (session-sized)

Mission design rules:

The decomposition process:

1. Start with the campaign goal (e.g., “build a self-referential aDNA documentation vault”)
2. Identify natural work boundaries (e.g., concepts, patterns, tutorials are different missions)
3. Within each mission, list specific deliverables as objectives
4. Order objectives by dependency (foundational concepts before advanced ones)
5. Estimate the context budget and declare the model tier — see Budgeting and Routing a Mission below. As a first cut: more than ~15K tokens of domain context in one objective usually means the objective is too broad

Handoff continuity: Each mission file contains enough context for a fresh agent to continue. The intent, objectives, context dependencies, and handoff notes create a self-contained briefing.

Budgeting and Routing a Mission

Decomposing the work leaves two questions open: how much context each objective will cost, and which model should run it. Both are answered on the mission file itself, before the work starts — so they are recorded decisions rather than things reconstructed afterwards from what happened.

The budget: two fields

Every mission declares token_budget_estimated. Every session that works on it logs token_budget_actual. Both are measured in kT — thousands of tokens of context loaded.

The estimate comes from a formula, not a feeling:

session_cost ≈ transition_tax + Σ per_objective_work

transition_tax is what a fresh agent spends before it does anything useful: reading the governance files, the campaign, the mission. In this vault it measures around 23K tokens. per_objective_work runs roughly 5K–80K depending on the kind of objective — planning is cheap, verification is expensive.

The total then decides the shape of the work:

The last row is the one that earns the table. A mission that needs more than 200K tokens is not a mission that needs a bigger window — it is two missions that have not been separated yet.

Why the actual is recorded too

An estimate nobody checks is a formality. Each mission’s After-Action Review reports estimate against actual, and drift beyond 2× in either direction triggers a retrospective — not a penalty, a question: was the estimate wrong, or did the scope move while nobody was looking?

That second case is the common one, and it has a shape worth naming: a budget ratified before the mission’s acceptance criteria are settled is a budget costed against work nobody has chosen yet. The fix is ordering — settle the criteria, then cost them.

The tier: which model runs it

Alongside the budget, a mission declares executor_tier — the class of model the work is routed to. The classes are defined by properties of the decision, not by model names:

Which model each class binds to is a separate table, re-pinned as model generations change. The classes are the doctrine; the model names are not, and writing the names into the pattern would date it on contact.

What makes it safe to run a mission on a cheaper model is not the model — it is the brief. A mission is only routable downward if its brief already carries six things explicitly: the objective, the acceptance criteria, the guardrails (what must not be touched, pushed, or decided), the verification surface that proves completion, the named conditions under which the executor halts and escalates instead of improvising, and the budget. Judgment is spent at design time so that it does not have to be spent at execution time.

The limit, in the same breath: executor_tier is a plan, and plans are sometimes not honoured. This vault has shipped a mission whose declared tier and actual tier diverged for four consecutive sessions, and nobody noticed until the After-Action Review. The record now names both, because a declared tier nobody honours is worse than no field at all. Both fields are visible in this vault’s own mission files — including the mission that added this section, which declared its tier and its budget band before a word of it existed.

When to Use

• Any task expected to take more than one session
• Work that involves multiple related deliverables
• When coordination between sessions (or agents) is needed
• Campaign planning — every campaign is a set of missions

Example: This Vault

Operation Rosetta decomposes into 15 missions across 5 phases. Phase 1 alone has 5 missions:

Each mission file (e.g., how/campaigns/campaign_rosetta/missions/mission_m04_pattern_library.md) lists specific files as objectives, declares context dependencies, and ends with handoff notes and an AAR. A fresh agent reading only the mission file can claim the next objective and begin work.

The decomposition also demonstrates convergence: the campaign scope (~100+ files) narrows to a mission scope (~8 files) narrows to a session objective (1 file at a time).

Anti-Pattern

Monolithic missions: A mission with 20 objectives spanning 5 sessions. By session 3, the agent has lost context on the mission’s intent. Split into smaller missions with clear boundaries.

Objectives without deliverables: “Research token optimization” is not an objective — it has no verifiable output. “Write concept_context_optimization.md” is an objective — the deliverable is the file.

Missing dependency ordering: Writing advanced concepts before foundational ones, then discovering forward references can’t be resolved. Map dependencies before starting.

Skipping the AAR: Completing a mission without the 5-line After-Action Review. The AAR captures what worked, what didn’t, and what the next mission should know. Without it, the same mistakes repeat.

Related

• Convergence Model — the structural principle that makes decomposition necessary and effective
• Token Selection — the context budget discipline that sizes objectives to sessions
• AGENTS.md Routing — how agents navigate to their mission’s working files