3.8 · Lesson 8 of 8
Evaluate progressive discovery vs. monolithic context strategy
What You Need to Know
Progressive discovery and monolithic context are competing strategies for what enters the model's working set. Monolithic context packs a bounded, usually small and stable corpus into the prompt (often with caching). Progressive discovery pulls only what the next step needs — search, open, extract, summarize — trading completeness of the dump for attention, cost, and feasibility on large corpora.
Architects choose based on corpus size, stability, and task breadth. Multi-GB repos and unbounded histories almost always need progressive discovery. Tiny, stable packs that fit with headroom can stay monolithic. Either way, protect transactional facts from being summarized away, and measure tokens and task success when you decide.
Decision rules
- Large, unknown, or changing corpora → progressive discovery.
- Small, stable packs that fit with headroom → monolithic (preferably cached) can win.
- Always keep a structured facts block for IDs and hard constraints.
- Never pretend a multi-GB dump is a viable every-turn strategy.
- Re-evaluate when the corpus grows past the budget that justified monolithic.
When monolithic still wins
A small, stable pack — style guide, schema card, short policy set — that fits with headroom for the user turn and tools can be simpler as monolithic context, especially with prompt caching on the stable prefix. The failure mode is pretending a multi-GB monorepo is the same kind of pack.
Progressive loop essentials
- Search or list candidates
- Open only what the next step needs
- Extract structured facts (paths, IDs, constraints)
- Summarize narrative; never summarize away the facts block
- Cap live raw text; measure tokens and task success
Exam stems that describe corpora that cannot fit key on progressive discovery. Dumping, disabling tools, or collapsing everything into one embedding are distractors.
Exam application
Multi-GB or unbounded corpora → progressive discovery with a facts pin. Tiny stable packs may stay monolithic if they fit. Distractors: every-turn full dumps, tool-less parametric memory, or one embedding for the whole world.
Exam traps
Defaulting to monolithic context for large corpora
Completeness fantasy burns tokens and attention. Progressive discovery is the standard for oversized, unknown sets.
Defaulting to progressive discovery for tiny stable packs
A small, stable policy pack that always fits may be simpler as a monolithic (or cached) block.
Progressive discovery without a facts pin
IDs and constraints get lost in rolling summaries. Keep a structured facts block that does not summarize away.
Confusing one embedding of everything with understanding
A single corpus vector is not a substitute for retrieving and reading the right files.
Practice scenario
An architecture team wants Claude to help navigate a multi-GB monorepo that cannot fit in a single context window. A proposal is to paste "as much of the repo as possible" into every turn. What strategy should the architect recommend instead?
Build exercise
Choose a context strategy for a monorepo assistant
35 minutes
What you'll learn
- Score corpus size and stability
- Design a progressive discovery loop with facts pinning
- Budget monolithic packs honestly
- Compare strategies on fixed tasks
Step 1
Decide using corpus size, stability, and task breadth
If the full relevant set fits with margin and is stable, monolithic (or cached) context can be fine. If the set is large, changing, or only partly relevant, choose progressive discovery.
Why: The exam keys on matching strategy to corpus characteristics.
You should see: A written choice with size estimate, stability note, and selected strategy.
Step 2
Design the progressive loop
Plan search → open → extract → summarize → next query. Cap how much raw text stays live. Persist a structured facts block for IDs and decisions.
Why: Progressive discovery without retention rules loses critical details.
You should see: A loop diagram and a facts schema (issue IDs, file paths, constraints).
Step 3
Use monolithic only with a hard size budget
If you choose monolithic, enforce a token budget and cache the stable prefix. Fail the design review if the pack cannot fit with headroom for the user turn and tools.
Why: Monolithic without a budget silently truncates the wrong things.
You should see: Measured token count of the pack plus cache configuration for the stable portion.
Step 4
Compare both strategies on a fixed task set
Run the same navigation or Q&A tasks under progressive vs a size-capped monolithic baseline. Track success, tokens, and latency.
Why: Architects justify the choice with evidence, not slogans.
You should see: A comparison table and a recommendation tied to the measured corpus.
Sources
- Context windows — docs.anthropic.com
- Prompt caching — docs.anthropic.com
- Extended thinking — docs.anthropic.com