Context Window Experiments: Measuring What Actually Breaks

Inspired by Deap Ubhi's "The More You Know Ep. 1: Context - The Invisible Bottleneck Breaking Your Agents"

Overview A few weeks ago I came across a piece on context as the invisible bottleneck breaking AI agents. The author described a founder whose agent worked perfectly in demos, then started hallucinating and contradicting itself in production by turn 47 — not because the model changed, but because the context window filled up.

The framing stuck with me: "The whiteboard was full, the eraser was moving on its own, and nobody noticed."

I build RAG systems on Amazon Bedrock and the question was urgent enough to stop theorizing and start measuring. I built a test harness — 5 controlled experiments, one variable changed at a time, ~100 API calls, about $4 total on Bedrock. Each experiment isolates one failure mode. Here is what the data says.

Findings **Finding 1: **"Lost in the middle" didn't show up where I expected I hid 10 department budget figures in a document and added up to 8 noise chunks between each fact. The task: find and sum all 10 budgets.

The model scored 100% accuracy at every noise level, all the way to 19K tokens. It found every fact and calculated the correct total on every trial.

I pushed harder. Five fact groups, up to 50 noise chunks, 12.8K tokens. Overall recall dropped — but not in the middle. Only the last fact category, positioned at the tail end of the context, degraded. The first four categories held at 100% regardless of noise volume. The last one dropped to 62% at 50 noise chunks.

The failure is a tail drop, not a middle drop. Facts buried at the end of a long, noisy context get dropped. Facts in the actual middle survived fine at this scale. Position at the tail matters more than position in the middle.

If you use RAG, put your most relevant chunks first, not last.

Finding 2: Instruction following is solid at scale — but not free I tested whether "respond with EXACTLY 3 bullet points" holds as context grows from 1K to 80K tokens.

Format compliance held at 100% at every context size. Exactly 3 bullets at 1K tokens. Exactly 3 bullets at 80K tokens. No deviation.

Latency told a different story: 2 seconds at 1K tokens, 6.8 seconds at 80K tokens — a 3.4x increase for an 80x context increase. The model is reliable at scale, but you pay for every token in that window on every call. At 100 concurrent users running 60K token inputs, the cost compounds fast. Upgrading to a larger context window doesn't solve this — it makes it more expensive.

Finding 3: Context poisoning is exactly as dangerous as described — and then some I set up a scenario with two conflicting policy documents: a 2023 one setting a $25K enterprise refund limit, and a 2025 one explicitly superseding it with a $50K limit. I tested 6 combinations of which document appeared, in what order, with what noise in between.

When only the stale document was retrieved: 0% correct answers. Every single time. No hedging. No uncertainty signal. The response was indistinguishable from a correct one.

When both documents were present, the model mentioned both values — but couldn't reliably identify which was current. It has no concept of document recency. A date stamp in the text is just more text.

The danger is not that the model gets confused. The danger is that it gets confident in the wrong answer, and every downstream reader trusts it.

The fix is not a smarter model. The fix is metadata-based filtering before documents reach the model — filter by date, version, or document status at retrieval time, not inside the prompt.

Finding 4: Retrieval quality and answer quality are perfectly correlated Same model, same prompt, same question about SSO configuration — only the retrieved context changed.

Retrieval strategy LLM score Keyword score Gold (exact docs needed) 0.90 1.00 Gold + 8 noise chunks 0.90 1.00 Partial (one correct chunk + irrelevant docs) 0.70 0.83 Naive keyword match 0.00 0.17 The model couldn't compensate for bad retrieval at all. Keyword-match returned SSO troubleshooting documents when the user asked how to configure SSO — the word "SSO" appeared in every retrieved chunk, but the documents answered a different question. The result was zero correct answers.

This is not a graceful degradation. It is a cliff. The retrieval pipeline is the product.

Three things break production RAG:

1. Stale data in your index - the model uses it confidently and incorrectly, with no error signal
2. Weak retrieval strategy - semantic vs. keyword match was the difference between 0.90 and 0.00
3. Relevant chunks positioned last - they get dropped under heavy noise