Topic: Learning notes
Context Placement: Where Should the Important Bits Go?
You supplied the context, but the answer missed it. Explore information placement, long documents, conversation summaries, and ways to test each change separately.
“Didn’t I already mention that?”
Imagine a conversation that starts with choosing a database, switches to browser storage, then wanders through features you’re not building yet. Finding the current decision might take some scrolling, even for you.
Following the Core Prompting Techniques note, this article gives Sabrina Goldfarb’s Context Placement lesson its own space. The question here is how to arrange the necessary material so a model can use it to answer the task at hand.
The requirements, prompts, and expected answers below are original examples. No comparative model tests were run. First, we’ll make the arrangement and checks explicit; an experiment can tell us whether they help.
Was the information missing, or did the answer miss it?
When a model skips a requirement, I’d first work out which situation I’m dealing with:
| Situation | What to inspect first | What to address |
|---|---|---|
| Necessary content wasn’t in the actual input | The full request sent by the application, including truncation or summaries | Restore required information and check the capacity budget |
| Content was sent, but the answer didn’t use it | Which passage the answer cites and which condition it misses | Compare placement and selection of relevant material |
| Conflicting rules are present | Which document is approved and which is obsolete | Mark the current decision and resolve ambiguity |
All three can feel like “the AI forgot,” but they need different fixes. Moving text earlier in the original document won’t help if the application never sends it. Conflicting rules need a decision about which one applies.
The Token Limits and Context Windows note covers capacity. Here, we’ll focus on material that can already fit in the input.
What Lost in the Middle found
The course cites Lost in the Middle, which moved relevant information within multi-document question answering and key-value retrieval tasks. The evaluated models often performed better when that information appeared near the beginning or end, with performance dropping in the middle of long inputs.
Before turning your entire prompt upside down, remember that these results concern particular models and tasks. They don’t mean the middle is always inaccessible, or give every current model a universal seating plan.
I’d treat this as something worth testing: does moving the same relevant passage change the answer? Keep the other conditions fixed and compare.
Try a small prompt-library specification
Suppose we want AI to answer questions about a small prompt library. We can separate reference documents from the task:
Reference documents:
REQ-01 | Confirmed form requirements
Users can enter a prompt title and content, then add a card.
REQ-02 | Confirmed storage requirements
Use localStorage for this iteration.
Saved cards must remain after refreshing the page.
Deleted cards must not reappear after refreshing.
REQ-03 | Scope for this iteration
No accounts, backend API, or cloud synchronization.
Task:
Answer these three questions using only the documents above.
Cite the document ID for each answer. If unsupported, write "not found."
1. What stores the cards in this iteration?
2. What should happen after deleting a card and refreshing?
3. Do we need accounts in this iteration?This prompt is short. It makes the task explicit but doesn’t reproduce the paper’s long-context experiments. The manually specified expectations are:
| Question | Expected answer | Evidence |
|---|---|---|
| Storage | localStorage | REQ-02 |
| Refresh after deletion | The deleted card does not reappear | REQ-02 |
| Accounts required? | Accounts are outside this iteration’s scope | REQ-03 |
Document IDs make the evidence easier to check. A model can still cite the wrong passage, so compare the claim with the original. Adding REQ-02 after an answer doesn’t automatically earn it a passing grade.
Now we can keep the document text and questions fixed while changing the order of the three document blocks. To evaluate long-document behavior, use representative long inputs too. This tiny example can’t establish that a long-context problem is solved.
Where do long documents and questions go?
The course recommends placing critical information first and important additions last. Anthropic’s long-context guidance places long documents before the query and instructions, and recommends extracting relevant quotes before answering.
These recommendations address different material and use cases. I’d first identify whether I’m moving a long document, a particular piece of evidence, or the response instructions, then test an arrangement. “Put everything important first” loses those distinctions.
Label document sources, versions, and status as well. If an old proposal is obsolete, say which decision replaced it. Appearing last tells us where a passage sits; it doesn’t tell us it was approved.
Give a long conversation a current-state summary
When drafts, rejected approaches, and new decisions pile up in one conversation, I’d extract a summary that can be checked. Continuing the same example:
Current task: implement local saving and deletion for the prompt library.
Confirmed decisions:
- The form has title and content fields. Source: REQ-01.
- Store data in localStorage. Source: REQ-02.
- Deleted cards must not return after a refresh. Source: REQ-02.
Out of scope: accounts, backend API, cloud sync. Source: REQ-03.
Open checks:
- Does existing code handle localStorage write failures? Documents don't say.
- No implementation or browser test results are available yet.
Next: read the existing storage logic, then implement and check these requirements.This keeps the decisions, sources, and unknowns together. Be especially careful not to compress “this should happen” into “this is already implemented.” Otherwise, the next round starts from a false assumption.
When starting a new conversation, carry over the summary and necessary original material. Check the summary against its sources because compression can drop conditions. Opening a fresh chat is easy; an incomplete handoff can come along for the ride.
Test moving and removing information separately
To find out which change helps, I’d split the comparisons:
| Comparison | Change | Keep fixed |
|---|---|---|
| Position A | REQ-01 → REQ-02 → REQ-03 | Full document text and the final task and questions |
| Position B | REQ-02 → REQ-01 → REQ-03 | Same content; move the relevant REQ-02 to the front |
| Position C | REQ-01 → REQ-03 → REQ-02 | Same content; move REQ-02 to the end |
| Reduction or summary | Run a separate comparison removing irrelevant material or using a summary | Use the same questions and check that necessary facts survive |
The first three compare placement. The last also changes content, so record it separately instead of attributing the whole result to “moving it to the front.”
For actual tests, save the complete request, model version, and settings, then repeat runs. Check the three answers, whether their sources support them, and whether the response adds features absent from the documents. Record cost and latency too.
There are no experiment scores here. The document orders and summary are designs to test. Repeated results would tell us whether they help this particular task.
References and scope
- Sabrina Goldfarb, Context Placement: course guidance on placement and long conversations. The site lists its text under CC BY-NC 4.0 and code samples and exercises under Apache 2.0.
- Liu et al., Lost in the Middle: How Language Models Use Long Contexts: research on relevant-information placement.
- Anthropic, Prompting best practices: provider guidance on arranging long documents and questions.
Sources checked on 2026-10-16. This is a concept summary with original requirements, not a verbatim course translation. No model-quality or implementation tests were run; manually specified answers do not describe observed model performance.