You now know what tokens are and why long sessions decay. This lesson turns that knowledge into habit. Most beginners treat context like a dumpster: if it *might* be relevant, toss it in — the whole repo, the full chat history, three contradictory briefs, yesterday's logs. Professionals treat context like a budget: every token is spent on purpose, on the smallest set of material that lets the model do *this* task well.

The five operating rules

1. Give the agent the smallest useful file set. Name the files, not the folder. "Read pricing.js and SPEC.md" beats "look at the repo." If the task touches three files, attach three files. 2. Use one task per session when possible. "Fix mobile overflow on the comparison page" is a session. "Fix overflow, redesign onboarding, and reconsider pricing" is three sessions wearing a trench coat. 3. Keep decisions in durable files. Anything you want to survive the session — customer rules, brand constraints, architecture choices — belongs in CONTEXT.md, SPEC.md, or a handoff, not buried at message 47. 4. Do not repeatedly paste the entire history. Re-pasting a 60-message chat "so you remember" re-fills the backpack with the noise you just identified as the problem. Paste the handoff summary instead. 5. Ask for a summary before a reset. End every working session with: "Summarize completed work, decisions made, current state, and the single next task as a handoff." Save it, then open the clean session from Lesson 9.2.

Why better context beats a stronger model

When a result is bad, the tempting move is to switch to a bigger, more expensive model. Sometimes that helps. Far more often, the failure is a context failure of the kind you met in Class 02: the model guessed because it was never given the customer's constraint, the settled decision, or the right file — or because the right material was buried under ten times as much noise.

A focused budget does three things no model upgrade can do on its own: it removes stale instructions that actively mislead, it puts the decision the model needs at the top of the backpack instead of the bottom, and it shrinks the reasoning the model must do, which cuts both errors and cost. Try the cheaper fix first: tighten the file set, clear the contradiction, reset the session. Only then, if the task genuinely needs deeper reasoning, reach for the stronger model. You will revisit this trade-off with real numbers in Class 12.

Sonariq: what a context budget looks like at scale

Sonariq — the multi-agent company-research project running through this classroom — is what these rules look like beyond a single session. Ten agents researching ten companies will produce ten incompatible versions of "research" unless every agent starts from the same operating reality.

Its context budget has four parts:

Shared standards: what counts as evidenceFocused task file: one company, one briefAgent outputStructured JSON handoffNext agent or clean session

• Shared standards. Every agent reads the same research rules: what counts as a claim, what needs a source link, what "done" means. This is CONTEXT.md grown up.
• Bounded research prompts. Each agent gets one company and one brief — smallest useful file set, one task per session.
• Structured handoffs. Results come back as JSON with fixed fields (claims, sources, open questions), so the next step inherits conclusions without inheriting chat noise.
• Focused agents. No agent carries the full history of all ten companies. Each session stays small, sharp, and cheap.

Your project is probably one person and one agent, not ten. The principle is identical: shared files for stable knowledge, small briefs for current work, structured handoffs between sessions.

Exercise: write your project's "read these first" list

Create a short file at the top of your project — docs/READ-THESE-FIRST.md or the opening section of CONTEXT.md — that tells any new session (or human) exactly where to spend its budget:

# Read these first

## Always read (the budget core)
- `CONTEXT.md` — who this is for, what we decided, what is out of scope
- `SPEC.md` — what we are building right now
- `docs/handoffs/latest.md` — where the last session stopped

## Read only for this task
- [e.g. `src/pricing.js` — needed for the overflow fix]
- [e.g. `styles/compare.css` — needed for the overflow fix]

## Do not read unless asked
- [e.g. `archive/` — old explorations, superseded]
- [e.g. full server logs — summarize the error, don't paste the log]
- [e.g. any chat older than the latest handoff]

## Session rules
- One task per session. Ask for a handoff summary before stopping.

Done looks like: a committed file under 30 lines that a fresh agent can follow without asking "where do I start?"

Quick check: open a new session, point it at the list, and ask it to restate the goal and next task in two sentences. If it can, your budget works. If it asks for the old chat, something durable is still trapped in scrollback — promote it into a file.

Common mistake: listing everything as "always read." If ten files are all mandatory, you have no budget — you have a dumpster with headings. Three core files plus two task files is plenty for most sessions.

Check your understanding

1. What are the five context-budget rules, in your own words? 2. Why can tightening context improve a result more than switching to a stronger model? 3. In the Sonariq flow, what problem do shared standards and JSON handoffs each solve? 4. What is the difference between "always read" and "read only for this task"? 5. When should you ask for a summary, and what should you do with it?