← All posts
Performance

Cutting prompt size by 87% without losing accuracy

Mahari Kalau11 min readJul 2026
Cutting prompt size by 87% without losing accuracy

Stuffing more context into a prompt is the cheapest thing an engineer can do and the most expensive thing a system can carry. We measured what happens when you compose instead.

The baseline: how much of a prompt is wasted

We instrumented a set of production agents at four companies for six weeks, capturing every context package sent to a model alongside the eventual answer. Then we asked: which items in the package actually contributed?

MetricNaive retrievalComposed context
Avg. context tokens9,6601,240
Items in package183
Items referenced in answer2.42.6
Answer accuracy (graded)71%93%
P50 latency2.9s1.1s

The headline number is the 87% token reduction. The more interesting number is the accuracy going up.

Why less context improves answers

Two mechanisms, both well documented and both underweighted in practice:

Distraction

Irrelevant but semantically adjacent content pulls the model toward plausible-sounding wrong answers. A stale churn definition sitting three chunks away from the current one is worse than no definition at all, because the model has no way to rank them.

Position degradation

Attention over long contexts is uneven. Content in the middle of a large prompt is measurably less influential than content at either end. Stuffing eighteen items guarantees that most of them land in the weak zone.

Adding a relevant document to a prompt helps. Adding nine irrelevant ones to reach it does not.

How composition works

Instead of ranking documents by similarity and taking the top N, we resolve the query against a structured knowledge graph:

  1. Intent classification — what kind of question is this? A metric lookup, a policy question, an entity definition, an open-ended analysis?
  2. Entity extraction — which concepts does it reference? Churn, cohort, Q3, enterprise tier.
  3. Graph traversal — pull the canonical definition for each entity, plus direct dependencies (churn depends on retention, which depends on active-account rules).
  4. Scope filter — drop anything outside the caller's permissions.
  5. Assembly — emit the minimal package with provenance attached.
# Query: "why did enterprise churn rise in Q3?" intent: metric_explanation entities: churn, enterprise_tier, Q3_2026 traversal: churn → retention_formula → active_account_rule scope: revenue_ops (3 of 3 items permitted) emitted: 1,240 tokens latency: 42ms

What the 42ms is spent on

Composition adds a step, and people reasonably ask what it costs. Roughly: 8ms for intent and entity extraction, 19ms for graph traversal, 6ms for scope resolution, 9ms for assembly and serialisation. Against a model call measured in seconds, it disappears.

Caching note: intent classification results are cached by normalised query shape, and graph traversals are cached per entity set with invalidation on knowledge updates. In steady state most requests skip the first two steps entirely.

Where composition does not help

If the question is genuinely open-ended — "summarise everything we learned from the March incident" — there is no small canonical answer set, and retrieval over documents remains the right approach. Composition is for questions with structure. Fortunately, most enterprise questions have more structure than they first appear to.

Mahari Kalau

Mahari Kalau

Founder & CEO, OneClickBrain

Writes about context engineering, agent architecture, and the unglamorous parts of enterprise AI.

Keep reading

📄
Featured

Why RAG alone can't fix enterprise hallucinations

12 min read · Aug 2026
🤖
Engineering

Serving context over MCP: what we got wrong first

10 min read · Jul 2026
🧩
Architecture

Metadata-first: reading a stack without touching a row

9 min read · Aug 2026