Context Has a Temperature

In Context is not memory we argued that intelligent systems must resolve what matters—not retrieve everything they ever stored. The next question is practical: how much, and which slice, should be active for this moment?

We have started using context temperature as a shorthand:

• Hot — what this task needs right now (intent, active constraints, current object, recent decisions still in force).
• Warm — supporting material that informs but should not dominate (architecture summary, glossary, adjacent ADRs, index pointers).
• Cold — history that must exist for traceability but must not flood a live run (superseded specs, abandoned threads, old experiments).

Temperature is not a vendor feature. It is a design habit: treat context like energy—put heat where the work is, keep the rest reachable but out of the way.

Why temperature matters

Models have larger windows than ever. Teams have more docs than ever. The failure mode is not “we forgot to save something.” It is loading the wrong temperature for the phase:

When cold context goes hot, agents look busy and understand less—the same distraction pattern we saw while building Nimbus 2.0. When hot context is missing, they guess. Efficiency is matching temperature to job, not maximizing tokens.

How to use it efficiently

1. Start from the index, not the tree.
A context index (what to read first, in what order) is a temperature control panel. Status fields like current, stale, and superseded are temperature labels in disguise—see Living memory for your project and Maintained context — the toolkit shows how.

2. One hot object per run.
Tie the session to one primary object: active intent, feature brief, spec slice, or Work Packet. Warm links hang off that object; cold material stays one hop away via links, not inlined. This pairs with What if every conversation became an object?—the packet is often the heat source.

3. Heat the phase, not the project.
Planning runs should not carry implementation minutiae hot. Implementation runs should not re-litigate CEO scope unless the spec is wrong. Use slash-command or workflow gates (plan before build, review before ship) as temperature boundaries—a pattern tools like gstack encode as commands; the Cursor Agentic Toolkit encodes it as staged artifacts in git.

4. Summarize on the way out.
When a phase ends, write down what should stay hot for the next person or model: a short “state of intent,” updated index status, decision note. That is how warm context stays accurate without reheating the whole archive—aligned with Let the agent maintain itself when agents update the playbook after shipping.

5. Prune deliberately.
Cold is not “delete.” It is archived, linked, and labeled so retrieval systems and humans do not mistake it for ground truth. Periodic gardening is part of efficiency; stale hot context is worse than no context.

A simple rule of thumb

Before you add another file to the prompt, ask:

1. Is this hot for the task I am in? If no → link, don’t load.
2. Is this still authoritative? If no → cold, with pointer to what replaced it.
3. Would a human skim past this in a meeting? If yes → it should not dominate the window.

Memory stores information. Context creates meaning. Temperature decides what gets to participate in meaning now.

Open question

Should temperature be explicit metadata on artifacts (hot/warm/cold per task type), or should a Context Resolver infer it from intent and phase—similar to what we are exploring after Context is not memory?

We are biased toward both: humans label what they know; the system resolves the mix at runtime so agents are not left to “feel” relevance on their own.

The insight: efficient context is not more context—it is the right heat for the right moment, with everything else one trusted link away.