Task Atomization: Isolating AI Tasks into Independent, Clean-Context Units

01 | Core Problem: Context Is a Single Scarce Resource

LLM context windows are globally shared and limited, creating three contradictions: breadth vs depth, long tasks vs attention decay, and parallel vs serial execution.

Contradiction 1 – Breadth vs Depth : A complete feature may require 50K‑80K tokens of input (spec, plan, task list, code files, conventions) plus additional tokens for reasoning, code generation, and error handling, leaving little space for execution.

Contradiction 2 – Long Task vs Attention Decay : When a task reaches ~30K tokens, the model’s attention to the earliest 10K tokens (e.g., "must use TypeScript", "no any") drops significantly, increasing the risk of violating early constraints.

Contradiction 3 – Parallel vs Serial : A single session that runs all tasks serially accumulates errors and state, while parallel sessions struggle to keep a consistent view of project state.

02 | Core Mechanism: Atomization + Isolation + Parallelism

The solution combines three tightly coupled mechanisms.

Mechanism 1 – Atomized Tasks

Independently Loadable : Required context fits within 30%‑50% of the window.

Independently Executable : No reliance on intermediate states of other tasks.

Independently Verifiable : Completion can be judged binary (done/not‑done).

Non‑atomic example: "Implement user authentication module" – requires the whole user system, a decision between JWT vs Session, and vague acceptance criteria.

Atomic example: "Implement generateToken in src/auth/jwt.service.ts, taking userId:string and returning a signed JWT using JWT_SECRET with 24h expiry; pass all four unit tests in jwt.service.test.ts." All inputs, outputs, dependencies, and acceptance criteria are explicit.

Mechanism 2 – Context Isolation

Each atomic task runs in its own context instance. Traditional approaches keep a single session that accumulates noise; the isolation approach loads shared state from the file system and clears the context (e.g., using /clear). Key technologies include Claude Code Sub‑Agent, Cursor Background Agents, GSD’s /clear command, and multi‑worktree setups.

Mechanism 3 – Sub‑Agent Parallelism

Independent atomic tasks can be executed in parallel waves. Wave 1 creates base model files, Wave 2 builds dependent services, Wave 3 continues onward. This mirrors a distributed system where the main agent is a scheduler, sub‑agents are workers, the file system is shared storage, and the task dependency graph is a DAG.

03 | Three Core Standards for Atomization

Standard 1 – Context Footprint < 50% : All required context (spec, plan, code, reasoning space) must occupy less than half of the model’s window, leaving ~30% for chain‑of‑thought reasoning and ~20% for output generation.

Standard 2 – Explicit Dependency Closure : An atomic task must be able to list exactly which files it depends on. If a developer who has only read that list can complete the task, it passes; otherwise further splitting is needed.

Standard 3 – Binary Completion Criteria : Acceptance must be unambiguous—e.g., all unit tests pass, a specific API schema is returned, or the code compiles without lint errors. Vague criteria like "looks good" are unacceptable.

04 | Why Atomization + Isolation Beats Long Sessions

100% Clean Context per Task : In a long session, the fifth task inherits the clutter of the previous four; atomization gives the fifth task a pristine context.

Local Rollback : Failure in a long session often forces a full restart; with atomization only the failing task rolls back while others remain intact.

True Parallelism : Long sessions are inherently serial; atomized tasks can run in parallel waves, theoretically achieving up to 10× speed for ten independent tasks.

Lightweight Main Context : The orchestrator only schedules and verifies outputs, keeping its own context usage at 30%‑40% and remaining efficient over time.

05 | Harness Frameworks' Atomization Practices

Different Harness frameworks implement atomization to varying degrees.

GSD : Enforced atomic tasks, 200K‑token per‑task limit; per‑task sub‑agent with mandatory /clear; wave execution.

OMC : 19 specialized agents (architect, reviewer, …); agent‑level responsibility isolation; team‑level parallelism.

ECC : 48 agents + 182 skills; cross‑tool agent isolation; multi‑agent collaboration.

Trelli : One file per task under a tasks/ directory; task‑level file isolation; medium parallel capability.

Spec‑Kit : Tasks defined in tasks.md; weak isolation (same session); weak parallelism.

OpenSpec : Same as Spec‑Kit.

06 | Atomization Anti‑Patterns

Pseudo‑Atomic Tasks : Declaring a task like "implement user management" that actually spans dozens of files and APIs; such tasks exceed the window and must be split into ~30‑minute units.

No Context Isolation : Running atomized tasks sequentially in the same session without clearing context nullifies any benefit.

Parallel Without Shared State : Parallel worktrees that do not share a single source of truth cause merge conflicts and duplicated effort; all agents must read from the same git main branch and spec.

Ignoring Task Dependencies : Marking all tasks as parallel leads to a dependent task starting before its prerequisite finishes, causing failures; explicit dependency declarations are required.

07 | Extended Thought: Homology with Microservice Architecture

Task atomization mirrors microservices: clear service boundaries ↔ clear task boundaries, independent deployment ↔ independent execution, API communication ↔ file‑system communication, private databases ↔ private contexts, and orchestrators (K8s) ↔ main agent scheduling sub‑agents.

Both approaches decompose complex systems into independently operable units; microservices address human collaboration and system complexity, while task atomization tackles LLM context limits.

From a parallel‑computing perspective, atomization upgrades AI programming from a single‑core CPU (sequential session) to a multi‑core CPU (multiple sub‑agents), enabling linear scalability as long as tasks are fine‑grained and hardware supports enough parallel agents.

Common Pitfalls

Improper Task Granularity : Too coarse (e.g., "build entire auth system") causes context overflow; too fine (e.g., "rename a variable") leads to fragmentation. Ideal granularity: one function, component, or API endpoint.

Splitting Without Isolation : Atomized tasks executed in a single session lose all benefits.

Parallel Execution Without Shared Truth Source : Independent agents diverge, causing constant merge conflicts.

Missing Explicit Dependency Declarations : Scheduler cannot order tasks, leading to wave failures.

Vague Acceptance Criteria : Ambiguous definitions of "done" cause disagreement between AI and humans.

Summary

Context is a single scarce resource : breadth vs depth, long task vs attention decay, parallel vs serial are irreconcilable contradictions.

Atomization triple : atomic tasks + context isolation + sub‑agent parallelism.

Three core standards : context footprint < 50%, explicit dependency closure, binary completion criteria.

Anti‑patterns to avoid : pseudo‑atomic tasks, non‑isolated context, parallel without shared state, ignored dependencies.

Microservice homology : both solve the same problem of breaking complex systems into independently operable units.