07 — Context — The AI Knows Only What You Tell It

"Background info the model just has" was how I dismissed context, and every fresh session proved the assumption wrong. Writing it down forced the central idea into view: context is everything when working with AI [1]. Not metaphorically. Literally. The model has no memory of my project, no knowledge of my past decisions, no awareness of my preferences — unless I provide them in the current session. Every fresh session is an amnesiac junior who reads only what I hand them, then forgets it all when the session closes.

The framing that clicked: context is a budget, not a backdrop. I used to dump everything into every prompt on the theory that more is better. In practice the model has a finite attention window, and irrelevant context crowds out the relevant. The discipline isn't "tell it everything." It's "tell it the right things, and keep the rest out."

Why context engineering is a first-class skill

The roadmap treats context as its own topic, separate from prompting, and I want to respect that distinction. Prompting is how I phrase a single request. Context engineering is the broader discipline of deciding what the model sees at all — across a session, across a project, across multiple agents [2]. It earned its own name because it turns out to be the single largest lever on output quality after model choice itself.

Three things I had to internalize:

• Sessions are short-lived. What the model learned in last night's session is gone this morning. Stable context has to be re-supplied every time, which is why a context document is worth its weight.
• Attention is finite. The model doesn't weight everything equally. As context grows, early or buried details get less attention. A focused session with twenty relevant lines beats a sprawling one with two thousand.
• Irrelevant context is active harm. Pasting the whole codebase "just in case" doesn't help — it introduces noise the model has to wade through, and it can mislead. A stale comment from six months ago can send the model down a wrong path today.

Keep sessions focused, and start fresh for unrelated tasks

The roadmap's first practical rule: _keep sessions focused, start fresh for unrelated tasks_ [1]. The temptation is to keep one long-running session for everything — it remembers, right? — but that's the trap. A session that worked on auth, then styling, then a migration, then a bug fix carries all four threads in its history. By the time I ask it to fix a fifth thing, the relevant context is buried under four unrelated topics, and the model's attention is split.

The discipline: one session, one thread of work. When the task changes — auth is done, now I'm on the dashboard — start a new session, paste the context doc, and begin clean. The cost is thirty seconds of setup. The payoff is that the model's full attention is on the current task, with only relevant history in view.

Use subagents to keep context clean

The roadmap's second rule is the one that took me longest to use: _use subagents when possible to keep context clean and costs low_ [1]. A subagent is a separate AI session, spun up for a bounded sub-task, that reports its result back to the main session. Its key property is that its context doesn't pollute the main session — the main session sees only the result, not the hundred files the subagent read to produce it.

The payoff shows up on tasks that require a lot of reading but produce a small answer:

• "Find every place we call the old auth API and list the files." The subagent reads forty files; the main session sees a ten-line list.
• "Summarize what this dependency does and whether we still need it." The subagent digests the docs; the main session sees a paragraph.
• "Write the migration script." The subagent experiments in a scratch space; the main session sees the working script.

Without subagents, all that reading enters the main session's history and stays there, diluting everything after. With them, the main session stays focused on the actual work, and each sub-task's exploration is isolated and cheap [3].

The rule I keep: if a sub-task requires a lot of reading to produce a small answer, delegate it to a subagent. If it requires ongoing back-and-forth on the main work, keep it in the main session.

Context engineering as a team discipline

One thing the reading made clear: context engineering isn't just a personal workflow tweak — at team scale it becomes a shared practice [2][3]. The project's stable context (stack, conventions, structure, decisions) is the same for every engineer and every AI session. Writing it down once, in a place the whole team maintains, means every session — mine, a teammate's, a new hire's — starts from the same caught-up state instead of re-deriving the project's conventions from scratch [3]. The context doc becomes a team artifact, version-controlled, edited as decisions change.

How I use this

Three habits. First, a context doc — short, stable, version-controlled — pasted into every fresh session so the model starts caught up. Second, one session per thread of work; when the task changes I start a new session rather than carrying unrelated history forward. Third, subagents for any sub-task that needs a lot of reading to produce a small answer, so the bulk of exploration stays out of the main session's history. The way of thinking I keep: context is a budget, and I spend it deliberately on the things that matter for this task, this session.

References

[1] roadmap.sh, "Context," 2026. [Online]. Available: https://roadmap.sh/vibe-coding/context

[2] Anthropic, "Effective context engineering for AI agents," 2026. [Online]. Available: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[3] Packmind, "Context Engineering Best Practices for AI-Powered Dev Teams," 2026. [Online]. Available: https://packmind.com/context-engineering-ai-coding/context-engineering-best-practices/