Part V · Act on itChapter 16

The diagnostic: score yourself, get one action

The question Where does my team stand on context management today, and what is the single next thing to do?

4 min read Action Step 16 of 20 2/4 in this part
Research contents
  1. Understand the problem
    1. 1Why more context can hurt
    2. 2Anatomy of the context
  2. The methods
    1. 3The ten methods
    2. 4Choosing your methods
    3. 5Retrieval
    4. 6Compaction, offload, memory
    5. 7Sub-agents and isolation
    6. 8The tool surface
  3. Measure it
    1. 9Evaluating a change
    2. 10Metrics and economics
  4. Decide and avoid
    1. 11Hard calls
    2. 12Failure modes
    3. 13Antipatterns
    4. 14Case studies
  5. Act on it
    1. 15The optimisation plan
    2. 16The diagnostic
    3. 17Habits and tips
    4. 18Tooling landscape
  6. Reference
    1. ATemplates
    2. BLessons

Reference

On this page

In 30 seconds

  • Thirty-five items across seven areas, each scored 0, 1 or 2. Unknown scores zero.
  • Your level is the minimum across areas, not the average. Context fails at its weakest point.
  • The lowest area maps to exactly one next action.

You will be able to

  • Score your setup in about 30 minutes
  • Read your level and your one next action
  • Recognise the most common failing shape: one strong area, the rest at zero

How the scoring works#

Thirty-five items across seven areas. Score each one:

  • 0: not done, or not known
  • 1: partly done, or done inconsistently
  • 2: done and verified

"Not known" scores zero. If you cannot state your cache hit rate, you do not have a good one; you have an unmeasured one, and the failures it enables are live.

Two rules make the result honest.

  1. Gating items are marked ⚑. If a gating item scores 0, its whole area is capped at level 1, whatever the other items score. This stops an elaborate compaction schema from hiding a context nobody has ever measured.
  2. Your overall level is the lowest area level, not the average. Context fails at its weakest point. A perfect retrieval stack does not help if 30K tokens of dead tool definitions are crowding it out.
0 not done or unknown1 partly or inconsistently2 done and verified⚑ gating item
Area 1 · Measurement Gates everything downstream
  1. 1.1 ⚑ I know my prefix tax in tokens, measured within the last quarter
  2. 1.2 ⚑ I know my defined-to-called tool ratio
  3. 1.3 I know my tool-result share of session tokens
  4. 1.4 I know my cache hit rate
  5. 1.5 I can produce a segment-by-segment breakdown of a recent session
Area 2 · Prefix hygiene
  1. 2.1 ⚑ Zero-call MCP servers were identified from a representative 20-session sample; any deletion was task-coverage verified and remains rollbackable
  2. 2.2 Active tool count is 20 or fewer
  3. 2.3 Tool definitions are 15K tokens or fewer, or deferred
  4. 2.4 The instruction file is 150 lines or fewer and passes the inference test
  5. 2.5 The prefix contains no timestamps, session IDs or per-turn variables
Area 3 · Prevention
  1. 3.1 ⚑ Ignore files exclude node_modules/, dist/, lockfiles and generated code
  2. 3.2 My three loudest commands are wrapped or filtered
  3. 3.3 Test output is asymmetric: one line on pass, full trace on fail
  4. 3.4 Long output is truncated head-and-tail, never in the middle
  5. 3.5 Full output goes to a file and the path is returned
Area 4 · Retrieval
  1. 4.1 ⚑ I have classified recent failures as starvation or dilution
  2. 4.2 Symbol-level retrieval is available and used by default
  3. 4.3 Grep context is at least 8 lines, or reads expand to the enclosing symbol
  4. 4.4 No codebase overview or design document is pre-loaded (pointer seed under 2K only)
  5. 4.5 Files are re-read before being re-edited
Area 5 · State and boundaries
  1. 5.1 ⚑ Long tasks keep a plan file with a ruled-out section
  2. 5.2 Large tool output is offloaded with self-describing stubs
  3. 5.3 Compaction uses an explicit schema, not "summarise the above"
  4. 5.4 Compaction fires at sub-goal boundaries, not thresholds or timers
  5. 5.5 The plan file is re-read as the first action after any boundary
Area 6 · Session lifecycle
  1. 6.1 ⚑ One session is one coherent task
  2. 6.2 Sessions are capped at one compaction, then reset
  3. 6.3 I reset rather than argue when a wrong fact is in context
  4. 6.4 I reset on the third repeated action
  5. 6.5 Long sessions end with a written handoff containing file:line pointers
Area 7 · Evaluation
  1. 7.1 ⚑ Context changes are adopted one at a time, not in bundles
  2. 7.2 I have a task set I can re-run
  3. 7.3 I run k ≥ 2 and compute Pass²
  4. 7.4 Cost is reported cache-adjusted, not as raw tokens
  5. 7.5 I have deleted at least one context component that measurement showed was neutral

Your result

Score the items above to see your level and your one next action.

Levels#

Work out a level per area, then take the minimum.

Area score Level What it looks like
0–2 L0 Unmanaged Context is whatever accumulates. Failures are blamed on the model.
3–4 L1 Aware The problem is recognised; responses are ad hoc (/compact when it complains).
5–6 L2 Hygienic The obvious waste is gone. Deletion has happened. No measurement loop.
7–8 L3 Instrumented Numbers exist and drive decisions. Changes are attributable.
9–10 L4 Engineered Measured, sequenced, with a stop rule and a maintenance cadence. Removal is routine.

The scoring is calibrated so that unaudited teams land at L0–L1 on most areas, often with one area higher — usually retrieval, because it is the interesting one to work on. That single high score is diagnostic: effort went where the writing is, not where the tokens are.

Your one next action#

Find your lowest-scoring area. Break ties toward the earlier area; the order is deliberate.

Lowest area Your next action Where
1 Measurement Run the Phase 0 baseline. Nothing else is worth doing first. Phase 0
2 Prefix hygiene Review zero-call MCP servers from a representative sample; verify task coverage and keep rollback before deleting. Phase 1
3 Prevention Wrap your three loudest commands: one afternoon, 60–90% less output P. Phase 2
4 Retrieval Classify your last 10 failures as starvation or dilution before changing anything. Postmortem template
5 State Replace your compaction prompt with the explicit schema: a 15-minute edit worth up to 6.5 SWE-bench points S. Compaction schema
6 Lifecycle Adopt one mechanical rule: never compact twice; reset instead. Session lifecycle
7 Evaluation Build a 30-task replay set you can re-run. Minimum viable experiment

A worked audit C#

A team scores itself:

Area scores for one team (out of 10)

Measurement 2, prefix hygiene 4, prevention 3, retrieval 8, state 5, lifecycle 4, evaluation 1.02468101 Measurement (gate at 0)22 Prefix hygiene (capped)43 Prevention34 Retrieval85 State56 Lifecycle47 Evaluation (gate at 0)1
Figure 1. Overall level L0, the minimum of areas 1 and 7. The team's strongest area, retrieval at 8, cannot be trusted because evaluation is at 1 C.
View data
AreaArea score
1 Measurement (gate at 0)2
2 Prefix hygiene (capped)4
3 Prevention3
4 Retrieval8
5 State5
6 Lifecycle4
7 Evaluation (gate at 0)1
Area Score Level Note
1 Measurement 2 L0 Both gating items at 0: nothing measured
2 Prefix hygiene 4 L1 Capped: four servers attached, never audited
3 Prevention 3 L1 Ignore file exists; no command wrapping
4 Retrieval 8 L3 Symbol-level tool installed, tuned, used well
5 State 5 L2 Plan files used inconsistently; default compaction prompt
6 Lifecycle 4 L1 Long heroic sessions, several compactions
7 Evaluation 1 L0 Capped: changes adopted in bundles

The reading. This team invested real effort in retrieval, the interesting, well-written-about layer, while never measuring, never auditing tools, and adopting changes in bundles. Their retrieval work may be excellent, and they cannot tell, because evaluation scores 1.

Their one next action: area 1, the Phase 0 baseline, not the retrieval improvement they were planning. The likely finding: four unaudited MCP servers consume more context than the carefully tuned retrieval stack ever saves.

This shape, one strong area and everything else near zero, is the most common failure pattern in the diagnostic. It is the signature of optimising someone else's bottleneck.

When to re-audit#

Situation Cadence
Actively optimising After each phase
Steady state Quarterly
After a harness upgrade Immediately: re-measure the prefix tax; scaffold changes are silent
After a model change Re-tune the parameters (utilisation cap, compaction threshold, output cap). The structure transfers; the numbers do not
When someone says "it worked yesterday" Immediately: check area 7. That is the Pass² signal

The one-question version#

If you will not run 35 items, run this one:

Key takeaways

  1. Gating items cap an area, so polish cannot hide a missing foundation.
  2. One action, not a programme. Re-score after it.
  3. The one-question version covers most readers: what share of your context is tools you never call?