Lesson 1 said it generates from what's in front of it. This is the follow-up question: what is in front of it, how did each piece get there, and which of it did you only imagine you supplied.
The failure this lesson is about doesn't look like a failure. You set a constraint at the top of a working session. Forty messages later you get back something that breaks it, and nothing in between looked wrong — no error, no warning, no moment where the answer got obviously worse. That's not carelessness on anyone's part. It's a question about what actually reached the response you're reading, and the answer is knowable.
Claude can reason over exactly one thing: the information made available to the response it is about to give. Some of that you put there by typing it. Some of it arrived by other machinery — memory, project knowledge, a search through your past chats, a file you attached, a connected service, the live web.
The whole skill in this lesson is being able to answer four questions before an answer matters to you:
1 · What's in this conversation? Everything you and Claude have written in this chat, including the parts you'd forgotten.
2 · What did I attach? Files, pastes, links you actually put in — not files you referred to.
3 · What might have been brought in? Project knowledge, memory, a chat search, a connector, a web search.
4 · What did I only assume? The category where every surprise lives. Something you said in a different chat. A document still sitting on your desktop. A decision your team took in a meeting. Context so obvious to you that it never occurred to you to say it.
Most of what people call unreliability is question four.
You don't need to memorise this. You need to be able to look at any given answer and say which row it came from.
| Route | How it gets there |
|---|---|
| This conversation | You typed it, or Claude wrote it, in this chat. Available — though how prominent it still is, forty messages later, is the subject of the second half of this lesson. |
| A file you attached | You attached or pasted it, here. Check it's the version you think it is; nothing about the answer will tell you it wasn't. |
| Project knowledge | Documents added to a Project's knowledge base, drawn on by chats inside that project.docs A file you uploaded to a chat that happens to be in a project is not the same thing as a file in the project's knowledge panel. |
| Instructions | Persistent text applied to every chat within its scope — everywhere, or one project. Worth rereading occasionally, because they're invisible while they work. |
| Memory | Entries built up from your conversations and referenced automatically, without you
asking. Each project has its own separate memory space, and non-project chats share
one.docs
Lives under Settings → Memory. |
| Chat search | Claude searching your previous conversations when prompted to. It shows as a tool call in the reply, so you can see it happened. Inside a project, it searches that project only. |
| Connectors | A connected service — a drive, a calendar, a ticket system — searched on request. The connection existing is not the same as it having been used for this answer. |
| Web search | The live web, on request. The one route where you can usually click through and see the thing for yourself. |
| Nothing | A file on your desktop you described but didn't attach. Something you told it in a different chat that nothing pulled in. Anything in your head. None of these are available, and describing a document is not attaching it — your description becomes the material, and it will be treated as such. |
The previous revision said: "anything outside the context window does not exist." Clean, memorable, and false — it was already false when it was written. Memory injects entries you never restated. Projects retrieve from a knowledge base you uploaded months ago. Chat search reaches conversations from last year. Several mechanisms cross that boundary routinely, which is exactly why this lesson is organised around routes in rather than around a container. If you have met the container version elsewhere — and you will — this is the correction.
This is the first of two misconceptions, and it's the one that feels like being let down. You did tell it. You can scroll up and find the message. So why is it doing the opposite?
Because having said something is not the same as that thing being prominent in the material this particular response is being built from. An instruction given at message four is competing with everything in messages five to forty, including a table you asked for, two tangents, a change of mind and a request to be less hedged. Nothing deleted it. It just stopped being the loudest thing in the room.
Now the supplied artifact, which is the guaranteed part of this lesson. Two documents:
Northwind Consulting — Q3 Board Memo — twelve sections of board paper for a consultancy that doesn't exist. Read it once, at board-paper speed. Don't study it. There's a plain-text copy for attaching to a chat.
Twenty turns on the Northwind memo — a working session in which somebody drafts a board recommendation from that memo. It was written for this lesson, turn by turn. It is not a captured session and shouldn't be read as evidence about any model's behaviour today — it's a specimen of a shape, and the shape is the point.
Read the memo. Then read the transcript straight through. Then read turn 19 against section 6 of the memo. The transcript carries its own debrief at the bottom; write your own sentence before you look at it.
What the specimen is built to show is that drift is not one bad turn. It's four ordinary ones:
| A reformat | Somebody asks for the options as a table with four named columns. None of the columns is the constraint. The constraint isn't in the requested shape, so it isn't in the table — and the table is now what everyone is working from. |
| A change of mind | The question genuinely improves. It also becomes a different question, posed without the constraints being carried across to it. |
| A change of source | A question the document can't answer gets answered from general knowledge instead. General knowledge contains nothing that enforces your document's constraints. |
| A tone instruction | "Shorter." "Drop the caveats." Reasonable requests that quietly remove the surface where a reminder would have surfaced. |
Every one of those is locally defensible. That's what makes "just read it back carefully at the end" a weak defence: you'd be checking a document against a constraint you also haven't thought about in eleven turns.
Two honest qualifications, because the strong version of this claim doesn't survive contact with reality. Long conversations can become less reliable or less focused. Not always, and not steadily — plenty of long sessions hold together fine, and the machinery for managing long conversations keeps improving. So don't learn a rule about length. Learn the symptoms:
What to do about it: start a fresh chat and restate the brief. It costs a minute. Paste in the constraint, the source material that actually bears on the question, and the current state of the task — not the whole transcript. The point is to put the constraint back somewhere it competes with almost nothing.
This is the reasonable inference from everything above, and it produces worse work.
If the problem is that things weren't available, the fix looks like making more things available. So people attach the whole folder, paste the full thread, upload all twelve sections to answer a question that turns on two of them. What that actually does is bury the two relevant sections among ten irrelevant ones, and — the part that matters more — leave you unable to check the answer, because you no longer know what it should have rested on.
Anthropic's own engineering guidance frames it as a budget rather than a container: context is "a finite resource with diminishing marginal returns," and the goal is "finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."Anthropic Engineering That's written for people building software, but the instinct transfers exactly: curate, don't dump.
Volume is not grounding. Attaching more material makes an answer harder to trace, not easier — and traceability is the thing you're actually buying when you supply a source. A precise answer built from two pages you chose is worth more than a comprehensive one built from forty you didn't read, because you can check the first one in about a minute.
Step 1 is analysis of the specimen and cannot fail. Steps 2 to 4 are live, and none of them has a required outcome — write down what you expect first, then record what actually happened, including "it handled it fine." An answer that comes out better than this lesson implies is information, not a broken exercise.
1 · Find where it went. Read the memo, then the transcript. Read the final recommendation at turn 19 against section 6. Write one sentence naming where the constraint stopped being honoured and why. Then read the debrief at the bottom of the transcript and see whether you named the same turns.
2 · The fresh-chat contrast. New chat. Attach the plain-text memo, state the constraint from section 6 in your own words, and ask the turn-19 question directly: "Draft the executive's recommendation for the October board session. Half a page, three actions, no preamble." Compare it with turn 19. Note the differences, whatever they are — and note that this is one run, not a result.
3 · The narrow-question test. Two fresh chats, same question in both: "Which Q4 renewals are assessed as at risk, and what is the stated reason for each?" In the first, attach the whole memo. In the second, paste only sections 7 and 8. Compare on precision, on how much you had to read to check it, and on how long checking took.
4 · Account for it. For the answer you liked best out of steps 2 and 3, write out the four questions from the top of this lesson and fill them in. What was in the conversation, what you attached, what might have been brought in, and what you assumed. If box four has anything in it, that's your next prompt.
Four boxes. Tap as you go — it saves in this browser only.
From memory, without scrolling up: name the four questions you ask to account for what's available, and say which one the surprises live in. Then name the cheap repair for a session that has stopped holding the brief.
One: what's in this conversation. Two: what did I attach. Three: what might have been brought in — project knowledge, memory, chat search, a connector, web search. Four: what did I only assume, and that is where the surprises live. The repair: a fresh chat with the brief restated and only the material that bears on the question — not the whole transcript.
Said once, forty messages ago, is not available now.
This conversation · what you attached · what was brought
in · what you only assumed.
The fourth box is where the surprises are.
Anthropic Engineering, Effective context engineering for AI agents — written for people building software, and worth your time anyway. anthropic.com/engineering/effective-context-engineering-for-ai-agents
Read the first two sections — Context engineering vs. prompt engineering and The anatomy of effective context — and stop when it starts talking about tools and agentic search, which is out of scope for this course. Those two sections are the strongest available statement of the second half of this lesson: context as a finite budget with diminishing returns, and the goal as the smallest high-signal set rather than the largest available pile. It also defines compaction, which is the mechanism behind the sidenote above.