Principle of Parsimony in Context Engineering

What the Definition Means in Practice

The definition above packs several ideas into one sentence. Here is what each part means when you sit down to assemble a context.

"Every element." An element is anything that occupies tokens in the context window: a prompt, an instruction rule, a specification, a code fragment, a document excerpt, dialog history. Before adding any of these, ask: does this help the model do the current task?

Example: You are fixing a bug in authentication. The reporting module's database schema does not help. Leave it out.

"Every level of detail." Even when an element belongs in context, check its granularity.

Example: The authentication requirements are in a single file, but the current task only touches FR-AUTH-013. Include that section, not the entire file.

"Unambiguous task interpretation." The model should understand exactly one reading of the task. If the instruction can be read two ways, the model will pick one — and it may not be the one you intended.

Example: "Improve the code" can mean refactor for readability, optimize for performance, add error handling, or all three — the model decides for you. "MUST validate input before processing" has one reading: add validation, before processing, no exceptions. Better yet, the second form can be verified by a test: does the function reject invalid input? Strive for instructions that a deterministic tool can check.

"Enforceability of constraints." Rules in context should be specific enough that you can check whether the model followed them. Not every constraint can be checked deterministically — "follow SOLID principles" is valuable but requires judgment. The goal is to make constraints as verifiable as possible: lean on deterministic tools where you can, accept best-effort judgment where you must.

Example: "Write good code" gives no checkable criterion. "MUST use TypeScript strict mode" can be verified by a compiler flag.

"Result quality." If removing an element does not improve the output, it should not be in the context.

Example: In a multi-turn conversation you discussed three features. Now you are working on feature three. The full dialog history about features one and two is still in the context window. Remove it (start a new session) — the quality of work on feature three will not change, but the model now has more budget for the code and specs that actually matter.

Parsimony Is Not Obscurity

A common objection: "If I compress everything, nobody will understand the instructions." This concerns human readability, and it confuses parsimony with cryptic brevity.

Context is written for LLMs, but humans must be able to read, review, and maintain it. Text written with parsimony — imperative mood, no filler words, compressed structure — is easily read by a competent person who knows the domain terminology. Parsimony removes noise, not meaning. Compare:

Before: "You might want to consider validating the user input before processing it, as this could potentially help prevent issues down the line."

After: "MUST validate input before processing."

The second version is shorter, clearer, and leaves no room for interpretation. A domain expert reads it faster. An LLM follows it more reliably. The tokens saved are now available for a code example that shows how to validate.

The rule of thumb: if removing a word does not change meaning or enforceability — remove it.

The Cost of Over-Compression

The opposite risk is real: compress too aggressively, remove context the model actually needed, and it hallucinates. The fix costs more than the tokens you saved.

"MUST validate input before processing" is clear, but which validation? Format? Range? Business rules? If the model guesses wrong, you spend a round-trip correcting. One input/output example — 50 extra tokens — can eliminate that ambiguity entirely. Those 50 tokens are not waste; they are the "sufficient" in "minimum sufficient."

Parsimony is not minimalism. The goal is not the smallest possible context. The goal is the smallest context that still produces a correct result. When in doubt, include the example. Debugging a hallucination is always more expensive than a few extra tokens of context.

Token Conservation in Practice

Parsimony applies to ALL contexts where tokens are consumed: code, documentation, prompts, agent instructions, inter-agent messages. Three specific mechanisms make this practical.

Directive Vocabulary

Replace hedging with directives: MUST, SHOULD, MAY, DO NOT. "You might want to consider using environment variables" becomes "MUST use environment variables." Directive vocabulary compresses intent and strengthens compliance — the model treats MUST differently from a suggestion.

Context Rot Survival

In long conversations, agents compress or lose earlier instructions. Signal-to-noise ratio degrades with every turn. Parsimonious instructions survive this compression better than verbose ones: shorter rules have a higher probability of being retained and followed after context summarization. This is not a theoretical concern — it is the primary failure mode in multi-turn agent workflows.

Inter-Agent Transfer

When one agent delegates to another, context crosses a boundary. The non-parsimonious default: copy the parent's full context into the child's prompt. The parsimonious approach is references, not copies — point to the authoritative source instead of duplicating it. Transfer the task definition and references; the child agent's deterministic tooling then assembles its own minimum viable context from those references — scoped to the subtask, not polluted by the parent's broader concerns. Each agent's token budget stays dedicated to its own work.

Context Assembly per Request

Parsimony has a direct operational consequence: context must be assembled for the current task, not preloaded "just in case." Irrelevant context dilutes signal and wastes budget.

The assembly follows a three-step pipeline:

1. Scope — evaluate the user request, determine which parts of the system are affected
2. Collect — a deterministic tool receives the scope and gathers the minimum viable context: applicable specs, relevant code, configuration
3. Inject — only the assembled context enters the prompt. Everything else stays out

The deterministic parts of this pipeline — spec collection, config reading, context packaging — are idempotent: same scope plus same codebase produces same context. The LLM-dependent parts — prompt analysis, scoping — are best-effort reproducible. The goal is to maximize the deterministic surface and minimize the LLM-dependent surface.

This is the opposite of the common pattern where a system prompt is loaded with every possible instruction, rule, and example upfront. Preemptive loading is a parsimony violation: it spends tokens on context that may be entirely irrelevant to the current task.

The most common source of preemptive loading is invisible: a bloated MEMORY.md, a monolithic .cursor/rules file at 500 lines, a CLAUDE.md that tries to cover every possible scenario. These files consume tokens before the user types a single prompt — and the engineer often does not realize the budget is already spent.

Tool-First, LLM-for-Gaps

Deterministic tools — linters, compilers, schema validators, audit scripts — cost zero tokens at runtime. Building a deterministic check is often a better long-term investment than repeatedly invoking an agent for the same verification. With LLM-assisted development, the cost of creating such a tool has dropped dramatically — a custom linter rule or audit script is now minutes of work, not days. The tool pays for itself after the first reuse.

Parsimony motivates this from the economic side: every check offloaded to a tool is a check that does not consume token budget. Correctness motivates it from the engineering side: deterministic tools produce repeatable, verifiable, auditable results.

In practice, tools and LLMs alternate in a pipeline:

1. Tool detects candidates — an audit script finds potential violations, a linter flags patterns, a grep finds orphans
2. LLM triages candidates — false positive vs. real violation vs. script bug. Judgment applied to prepared candidates with assembled context
3. Tool validates result — after the LLM fix, the tool re-checks. Pass/fail is factual, not opinion

The LLM remains irreplaceable for scoping (what is affected?), generation (translate requirement to code), and feedback analysis (what was missing? what was overlooked?). Everything else — deterministic tool first, LLM only when the tool cannot resolve.

Parsimony Applied to Artifacts

The principle is not abstract — it maps to concrete artifact types:

Parsimony and Other Principles

Several established principles come close. KISS advocates simplicity but says nothing about distributing a fixed resource budget. YAGNI warns against adding what you don't need, but targets features in code, not tokens in a context window. DRY eliminates duplication, but a non-duplicated instruction can still be wastefully verbose. The Principle of Least Privilege shares the same structure — minimum necessary access — but optimizes for security, not output quality. Signal-to-noise ratio captures the mechanism (context rot is literally falling SNR), but it is a metric, not a design rule. Occam's Razor is the philosophical ancestor of all of these, yet it concerns explanations, not engineering systems where every token has a measurable cost.

None of them address the specific problem: how to distribute a finite token budget between instructions and artifacts to maximize the quality of what an LLM produces.

Parsimony does not replace these principles — it complements them. In a well-designed development workflow, parsimony works alongside at least three other concerns:

• DRY (Don't Repeat Yourself) ensures every fact has one authoritative source. Parsimony ensures that only the relevant facts enter the context. Together they prevent both duplication and bloat.
• Traceability ensures every change links to a requirement. Parsimony ensures those links are expressed in minimal form — an ID reference, not a paragraph of rationale.
• Deterministic Enforcement ensures checks are automated. Parsimony motivates moving checks from token-consuming LLM calls to zero-cost deterministic tools.

The distinction is clearest between parsimony and DRY. Parsimony answers the question "what to put in context?" — it operates within a single context window. DRY answers the question "where to store a fact?" — it operates across the entire system: code, configs, documentation, deployment.

Consider a concrete example. An error-handling rule is defined in an architecture spec. If the same rule is copied into every agent instruction file across seven services, each copy is minimal and useful — parsimony is not violated in any single context. But the rule now lives in eight places. When it changes in the spec, seven copies remain stale. An agent reads the outdated instruction and generates code by the old rule. DRY catches this; parsimony does not — because parsimony cannot see across context boundaries.

DRY without parsimony still leaves verbose, non-duplicated instructions. Parsimony without DRY leaves facts that look correct in each context but quietly go stale across the system. The combination eliminates both failure modes.

Why I Needed a Name

When I talk to colleagues and developers about treating context as a scarce resource, I run into the same problem every time: there is no single term for what I mean.

The closest candidate is "token efficiency." Two things convinced me it does not fit.

First, "token efficiency" reads as "save tokens," an optimization goal focused on cost. Parsimony is not about saving tokens. It is about distributing them. A parsimonious context may use the entire window, but every token is there by conscious decision, not by default.

Second, "token efficiency" is a metric: it measures how well tokens were spent after the fact. I needed a prescriptive design rule that guides decisions before tokens are spent. A principle that tells you to allocate budget where it has the most impact on the current task, compress everything else to the minimum that preserves unambiguous interpretation, and treat every token not as a cost to minimize but as a resource to allocate.

Consider the difference in practice. "Our token efficiency improved by 30%" describes a measurement. "This context violates parsimony, the architecture spec is loaded in full when only one component is affected" describes a design decision that can be reviewed, debated, and enforced. The first is a dashboard number. The second is an engineering conversation. Metrics describe outcomes. Principles prescribe behavior.

Other terms fare no better. "Prompt optimization" is too broad, it could mean anything from rephrasing a question to building an entire RAG pipeline. "Context management" describes a process, not a principle. "Be clear and concise" is good advice, but it is a recommendation, not an engineering constraint you can reason about or test against.

The problems that parsimony addresses are well-documented: context rot from verbose prompts, hallucinations from vague ones, token costs scaling with irrelevant context. Existing prompt engineering practices offer partial solutions. But these remain separate recommendations without a unifying principle that connects token economy, formulation clarity, and conscious budget distribution into a single testable criterion.

Open Questions

This article defines the principle and shows how it applies in practice. Two areas remain open:

Metrics. Parsimony is a design rule, not a metric. But without measurement, "this context violates parsimony" remains a judgment call. Possible directions: ratio of instruction tokens to total context, task success rate vs. context size (diminishing returns curve), survival rate of rules after N turns of context compression. These are hypotheses, not validated instruments.

Tool-specific implementation. How parsimony maps to concrete tools — Claude Code, Cursor, Windsurf, custom agent frameworks — is a practical guide that this article does not attempt. Each tool has its own context assembly mechanism, and the principle applies differently depending on what the engineer can control.

Conclusion

I named this principle for my own projects and will continue using it. If you have felt the same gap in terminology, it is yours to use.

Feature image by Johanne Marie Rogn, via Pinterest.