← Atlas Class

Context Partitioning

Isolated context or workspace per unit of work. Forced by the finite context window: without it, parallel work corrupts its own context or its own checkout.

Context partitioning is the practice of assigning each unit of work its own isolated context window or workspace, a structural necessity imposed by the finite size of the LLM context window.

Mechanics

Every LLM inference call operates within a fixed token budget. When a system routes multiple units of work through a single shared context, those units compete for space: earlier content gets evicted, attention dilutes across unrelated material, and state from one task bleeds into another. Context partitioning avoids this by giving each unit its own bounded container. The unit sees only what it needs; the container is discarded or archived when the unit completes.

The primitive is forced, not optional. A system that does not partition explicitly still partitions implicitly -- the context window simply fills until older content falls out. Explicit partitioning makes the boundary a first-class design decision rather than an accidental side-effect of token pressure.

Relation to Fork

Context partitioning is the class; fork is an instance of it. A fork creates a new execution context derived from a parent, carrying a controlled subset of the parent's state into an isolated window. Other members of the class include fresh-session spawning and scoped subagent delegation, where the child agent receives a constructed brief rather than a copy of the parent's full history. All share the same structural property: one unit of work, one bounded context.

Why it Matters

Partitioning has two practical consequences:

  • Correctness: tasks that require clean attention -- code review, adversarial probing, independent scoring -- produce more reliable output when the model has not already read the answer in prior turns.
  • Resource predictability: token usage per task becomes bounded and auditable rather than unbounded and cumulative.

Without explicit partitioning, long-running agent sessions accumulate context debt: the window fills with stale scaffolding, completed subtask state, and error traces, leaving progressively less room for the actual work.

Epistemic Status

This article is changelog-derived and has not been verified against a running runtime. The relationships described -- fork as instance-of context-partitioning, the forced-by constraint from the finite window -- are drawn from structural inference across the source graph, not from instrumented observation. Claims should be treated as a working model pending runtime confirmation.

Members 2 across 2 versions
Evidence & receipt
  • fileAGENTIC-ESCALATION-ARC.md
◇ ed25519 receipt
idprimitive-class_c347c7cac1efdc17f7245df1
alged25519
pubkey9b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd
sig8b1628e47b46f714636e868d93229d6c6064f833efd2b3e1ba1a2c55aa799621162e8180a3ad60dad3040ea553e944acffb5e63394b7f405de05bd881e79c701

Signed with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.