Context is the interface.

7 min read · pairs with Context Lab

You have spent your time editing the one part of the prompt you can see. Most of what the model reads shows up at runtime, and somebody else decided what it says.

What you already know

You have done a content audit. You know the hard problem in a content system isn't writing — it's that old pages never die. A help article from 2019 is still live, still indexed, still ranking, and a customer finds it and believes it, because it's on your domain in your voice with your logo at the top.

Nothing failed there. Search worked. The page loaded. The copy was well written when it was written. The failure was that nobody owned the question of what should stop being findable.

That is the whole of this module. A language model with retrieval is that same system, with two changes: it doesn't show you a URL, and it doesn't show you a date. It just tells you the answer.

What's actually in the window

Your system prompt is one block of text in a much larger payload. Alongside it, on every single call, some combination of: retrieved documents, the transcript so far, text the user pasted in, a summary of who they are, results from tools the model called a moment ago.

In the example this module ships with — a support assistant, three short documents — the system prompt is about a quarter of what the model reads. In a production assistant with real retrieval it is routinely a few percent. You are editing the small part.

Which makes the real design surface the part you probably haven't been shown: what gets retrieved, from where, how much of it, in what order, and what never gets retired. That surface exists in every AI product. It usually has no designer on it.

Three ways it goes wrong

Each of these produces a fluent, on-brand, confident answer. That is the thing worth sitting with — none of them looks like an error.

• Nothing was retrieved. The model answers from its own weights. Sometimes that's right. Sometimes it's a plausible average of the whole internet, delivered in your brand voice.
• The wrong thing was retrieved. The 2019 policy is still in the index. It comes back, it's coherent, it's specific, and it's wrong. This is the dangerous one, because the system is working exactly as built.
• Someone else's text was retrieved. A pasted email, a scraped page, a forwarded ticket. If it contains something shaped like an instruction, the model may follow it.

Why that last one happens

It's tempting to read prompt injection as a bug someone will patch. It isn't. It falls out of the shape of the thing.

The model has one channel. Everything — your instructions, the retrieved doc, the user's question, the forwarded email — arrives as text in one window. “This part is data, that part is a command” is a convention you assert in words, not a boundary the system enforces. A sufficiently instruction-shaped sentence in a document you didn't write can read, to the model, exactly like a sentence you did.

You can make it less likely — label sources, tell the model that content between markers is quoted material and never an instruction, keep untrusted text out of the same turn where you can. None of that is a guarantee, and designing as though it were is the mistake.

A small example

Two answers, same question, same prompt, same model. The only difference is which documents were in the window — and that difference is invisible in the output.

Prior turns are context too

One more thing that lives in the window: the conversation itself. Everything the model said three turns ago is still there, being read again, on equal footing with your instructions. A wrong claim it made early doesn't get corrected by later turns — it gets re-read as established fact.

You've seen the symptom in Multi-turn flows if the model drifted and never came back. This is the mechanism.

What you can actually do

• Ask to see the assembled prompt. Not the system prompt — the whole payload, for a real query. If nobody on the team can show it to you, that is itself the finding.
• Audit the index like a content library. What is in there, how old is it, who owns retiring it? Writing the new doc is the easy half.
• Ask for attribution, not confidence. If an answer can't be traced to a source, treat it as unsourced — regardless of how assured it sounds.
• Design the provenance into the interface. A date, a source name, a link. The model won't volunteer any of it, and the user has no other way to tell a current answer from an archived one.

What to take into the playground

• Run the seeded sets unchanged first. Four context sets, one question. Read the four answers before you read the verdicts.
• Open “what the model reads” on each card and watch the system-prompt percentage fall as sources go in. That number is the module in one figure.
• Look hardest at the injected set. Notice that it's often the friendliest, most reassuring answer on the page — which is exactly why it would survive a review.
• Then bring your own: paste in two versions of a real policy from your own product, one current and one you thought was dead. Give each a tell. Find out which one the model prefers.