Part II · The methodsChapter 4

Choosing your methods: a 55-minute procedure

The question Given my own agent and workload, which method should I adopt first, and in what order after that?

5 min read Core Step 4 of 20 2/6 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

  • Measure four numbers first. Every wrong context decision catalogued in this research started with a guess.
  • Route by your binding constraint and fix exactly one thing, then re-measure.
  • Three ordering rules are not optional: offload before compaction, state before resets, cache before everything.

You will be able to

  • Produce the four routing numbers for your setup in 30 minutes
  • Pick your first method from the routing table
  • Adjust the stack for the task type in front of you
  • Answer the recurring 2 a.m. calls from the decision table

Why a procedure, not advice#

Most guides end with "consider your needs". That is an adjective, not a method. This chapter is a procedure with time budgets. It takes about 55 minutes, once, and it routes readers with different bottlenecks to different methods.

The procedure

Measure for 30 minutes, route for 5, classify for 5, compose for 10, decide with the table for 5, then review quarterly. STEP 1 · 30 MIN Measure four numbers STEP 2 · 5 MIN Route by binding constraint STEP 3 · 5 MIN Classify the task type STEP 4 · 10 MIN Compose the stack quarterly re-measure
Figure 1. Measurement takes most of the time and is not optional. The rest of the procedure is fast because it is table lookups.

Step 1: Measure (30 minutes)#

Run the minimum measurement: the four routing numbers are about 30 minutes of its hour.

Symbol What it is How to get it
P Prefix tax in tokens Fresh session, send ., read the input count
T Tool-definition tokens, and the defined-to-called ratio Dump and count the schemas; count calls in your last 20 sessions
O Tool results as a share of session tokens — a different measure from chapter 3's top-three-commands share Bucket three long sessions by segment
C Cache hit rate Harness or provider usage report

Step 2: Route by your binding constraint (5 minutes)#

Your binding constraint is the one limitation currently capping results. Find it in the table, start with the method in bold, and keep the next one ready. When several rows match, the flow below gives the order.

If… Your binding constraint is Start with Then
C is under 60% Cache thrash M-1 prefix stability M-8 (compaction is often the culprit)
T is over 15K, or more than 3 tools defined per tool used Tool bloat M-2 tool minimisation M-1
O is over 35% of the session Tool-output flooding M-5 output shaping M-6
Sessions often exceed the window History growth M-8 and M-6 M-7, M-10
Read-utilisation under 5% Retrieval precision M-4 structural retrieval M-3
Failures are starvation (decisive file never read) Retrieval recall M-4 first, then M-3 —
Quality falls with session length Session hygiene M-10 session lifecycle M-7
The agent re-derives things after compaction State loss M-7 the living plan M-8, M-6
Survey work saturates the main context Topology M-9 sub-agents M-6
None of the above Context may not be binding Fix whatever else is binding, then re-measure —

The routing decision, as a flow

Check cache hit rate first, then tool bloat, then tool output, then retrieval, then session and state problems. Cache hit rate under 60%? M-1 Prefix stability Tools over 15K or ratio over 3:1? M-2 Tool minimisation Tool output over 35%? M-5 Output shaping Failures: file never read? M-4, then M-3 Quality falls over time? M-10, then M-7 None of these? Four more constraints sit in the routing table above. yes yes yes yes yes nonononono
Figure 2. Check the cache first because a broken cache can make every other optimisation self-defeating. Check tools second when the baseline shows tool-surface waste; it is then a cheap, reversible candidate.

Step 3: Classify the task type (5 minutes)#

Different work has a different context shape. The same method can be right for one and wrong for another.

Task type Context shape Methods that dominate Avoid
Small bug fix (under 30 minutes) Narrow, shallow M-3, M-4 M-8, M-9: overhead exceeds benefit
Large feature (hours) Broad, deep, long M-7, M-10, M-8, M-6 Unstructured long sessions
Codebase-wide refactor Broad, shallow, repetitive M-4, M-9, M-5 M-3 alone: it misses the long tail
Debugging or investigation Narrow, deep, iterative M-6, M-5, M-8 M-9: judgment cannot be delegated
Code review or audit Broad, read-only M-9, M-4 M-7: there is no evolving state
Greenfield build Small repository, deep specification M-7, M-10 M-4: nothing to index yet
Dependency or migration work Broad, mechanical, huge output M-5, M-9 Whole-file reads

Step 4: Compose the stack (10 minutes)#

Methods layer. A reasonable default for serious coding work, ordered by when each acts:

default stack
Prevention   M-5  output shaping ................ before context exists
Prefix       M-2  tool minimisation ............. per session, static
             M-1  prefix stability .............. a constraint on all the others
Selection    M-4  structural retrieval .......... what unit
             M-3  just-in-time .................. when
State        M-7  living plan document .......... survives every boundary
             M-6  reversible offload ............ before any compression
Compression  M-8  semantic-boundary compaction .. only after M-6
Topology     M-9  sub-agent isolation ........... only for composable work
Lifecycle    M-10 session discipline ............ the outer loop

Three ordering rules are not optional.

  1. Offload before compaction (M-6 before M-8). Otherwise compression is irreversible.
  2. Externalised state before resets (M-7 before M-10). A reset without a plan file is data loss.
  3. The cache constrains everything (M-1). Check the cache impact of any method before adopting it.

The mechanism behind each rule is chapter 3's map.

Step 5: The decision table (5 minutes)#

For the recurring calls, so you do not have to re-derive them at 2 a.m.

Situation Do Not Because
Context at 70%, task half done Reset with a handoff Compact and continue Compaction is lossy and breaks the cache; a reset costs about 500 tokens
The agent called the same tool 3 times Reset or redirect firmly Rephrase the request Distraction is a property of the context, not a misunderstanding
You need one function from a 2,000-line file Read the symbol Read the file Over 90% waste D, plus new distractors
A 12K test log just arrived Offload it and keep a digest Leave it in 12K tokens kept for 40 turns is 480K token-turns (tokens × turns held)
You find a hallucinated fact in context Reset to before it Correct it inline A correction appends; the wrong fact stays
A sub-task just finished Compact now Wait for the threshold Boundaries are the only safe compaction points
Adding an MCP server "just in case" Don't Add it Every unused tool is permanent prefix cost and confusion
40 files need surveying Delegate Read them in the main thread Surveys compose; this is the ideal delegation
4 interlocking components need building Build them in one thread Delegate in parallel Implicit decisions conflict P
The instruction file reached 300 lines Apply the inference test Add a "be concise" rule Dilution is the problem; more text makes it worse
A requirement changed at turn 25 Restate the full requirement Append the change Partial specs clash; a full restatement lets recency resolve it

Step 6: Set the review cadence#

Context management regresses. Tool surfaces grow back within a quarter without a recurring audit P; instruction files and output filters go stale and regrow too, so budget that your prefix tax is back at its original level within two quarters D. Put a 30-minute quarterly re-measurement in the calendar and rerun Step 1.

Key takeaways

  1. The procedure is measure, route, classify, compose, then review quarterly.
  2. Fix one constraint at a time so every effect stays attributable.
  3. Different task types need different stacks; debugging and delegation do not mix.
  4. Context management regresses. A 30-minute quarterly re-measure keeps it honest.

Terms used in this chapter

  • Prefix tax — The tokens present in segments 1–4 on each call before any work. Measure them by sending a one-token message in a fresh session; billing depends on cache hits.
  • Binding constraint — The one limitation that currently caps your agent's results. Fixing anything else changes little until it moves.
  • Read-utilisation — The share of retrieved tokens that appear in the final change or explanation. Low values mean retrieval is wasteful.