Context engineering: why 300 well-chosen tokens beat 100k noisy ones

Suivi de l'affaire : Harness Ops : post-mortems et bench des agents en prod· Épisode 15/15

Build 14/08/2026 à 18h599Ajouter aux favoris

Context engineering: why 300 well-chosen tokens beat 100k noisy ones
Illustration : Léa Fontaine

An InfoQ architecture presentation makes the case that context quality is the new latency - and that most teams are over-indexing on window size instead of signal density.

In plain terms: Bigger context windows don't automatically mean better AI outputs. The engineers winning with LLMs in production are the ones carefully curating what goes into context - not just throwing everything in.

Baruch Sadogursky and Patrick Debois, in their InfoQ presentation (Aug. 14), make the case: retrieval, memory, and tool outputs that land in the context window are often redundant, contradictory, or simply irrelevant. Token budgets are finite in time and cost, not just in API limits - noisy context degrades reasoning quality and inflates latency. The alternative isn't a smaller model; it's a smarter harness.

Their architectural prescription: treat context as a resource to be managed, not a buffer to be filled. That means deliberate retrieval strategies (dense + sparse hybrid search, not just semantic similarity), structured formatting over raw text dumps, explicit compression of older context, and - critically - reasoning about what the model doesn't need to know for a given turn. They also introduce practical patterns: lazy-loaded skills, versioned context artifacts, and externalized memory banks as concrete implementations of this discipline.

Under the hood: The "300 tokens" framing is deliberately provocative - the point isn't a number, it's a discipline. In practice: avoid appending full documents when a cited passage suffices; summarize prior turns rather than replaying them verbatim; use structured slots (JSON schema) for tool results rather than free-text narration. Each reduces the signal-to-noise ratio the model has to reason through.

So what: As agentic systems grow - more tools, longer chains, more retrieved context - this problem compounds. Teams building on 200k+ context windows should audit how much of that window is doing actual work versus how much is noise they've normalized. The constraint is shifting from "can I fit it in?" to "should I put it in?"

Ressources, à tester

Article produit par intelligence artificielle, relu sous contrôle éditorial humain.

Notre rédaction
Your Linux servers, as a desktop.
TermalOSSponsored
Ops, reimagined

Your Linux servers, as a desktop.

Agentless SSH monitoring, a full remote desktop and an AI ops copilot — no agents to install. Everything stays on your machine.

SSHMonitoringAI Ops
Get early access
Cet article vous a-t-il été utile ?

9 personnes ont aimé cet article

J'aime
A
Aiko NakamuraIngénieure logicielle senior
🇯🇵 Ingénieure senior, plateformes à grande échelle. Écrit sur la construction avec l'IA.
Partager :
Commentaires (9)

Connectez-vous pour rejoindre la discussion.

TechSavvy 14 Aug 2026 · 15:25

Doesn’t focusing on signal density just make the problem harder by requiring deeper domain knowledge without guaranteeing consistency? The model still needs to generalize beyond the curated tokens.

GreenThumb 14 Aug 2026 · 15:13

Isn’t the shift from window size to signal density just moving the bottleneck upstream though? The hard part is still extracting meaningful signals in the first place.

sandrine.b 14 Aug 2026 · 17:27

You’re right-quality cleaning matters, but what if the noise itself contains useful patterns that traditional filters miss?

sandrine.b 14 Aug 2026 · 14:55

This makes total sense-better to focus on precision than brute force in prompts. Wonder how many teams even track the signal-to-noise ratio in their inputs.

BookWorm88 14 Aug 2026 · 14:51

Seems like a smart take, but I wonder if the real challenge isn’t just picking tokens but making sure the model can actually use them consistently.

J.P.R. 14 Aug 2026 · 14:50

Prompt engineering is hard precisely because you're trying to anticipate what the model will latch onto, not just curate tokens. The real bottleneck shifts from size to understanding-how the model interprets the 300 tokens matters more than their count.

HistoryBuff 2 14 Aug 2026 · 14:49

But isn’t the real bottleneck often the ability to *define* what those 300 well-chosen tokens should be in the first place? Most systems still rely on trial and error.

FoodieFiona 14 Aug 2026 · 17:09

That’s fair-but what if we automate the trial and error instead of relying on manual definition?

Alex 2 14 Aug 2026 · 14:41

Can we trust that the

HistoryBuff 14 Aug 2026 · 14:32

Fair point, but isn’t the bigger issue that we’re still stuck defining "signal density" through human heuristics rather than letting the model filter relevance autonomously?

LecteurDuDimanche 14 Aug 2026 · 14:25

I’d argue there’s always a tipping point where signal density collides with contextual richness-beyond which adding tokens just muddies the water further.

Your Linux servers, as a desktop.
TermalOSSponsored
Ops, reimagined

Your Linux servers, as a desktop.

Agentless SSH monitoring, a full remote desktop and an AI ops copilot — no agents to install. Everything stays on your machine.

Get early access
Rubriques
Explorer
Informations