An intermediate, workshop-style RLM course on prompt contracts, recursive decomposition, chunking strategy, and workflow design.
Learning Outcomes
Write clearer prompt contracts for recursive workflows
Choose chunking and inspection strategies for real tasks
Design an applied RLM workflow for codebases and long documents
Modules
Prompt Contracts and Decomposition
Turn a vague recursive idea into a usable operating contract.
1.1 Writing a Prompt Contract
Objective
Turn "look around and answer" into a usable operating contract for recursive work.
Why This Lesson Exists
Most early RLM prompts fail for a boring reason: they sound thoughtful, but they do not tell the model what kind of work loop it is entering.
That usually produces one of three bad outcomes:
the model answers too early
the model wanders through context without producing reusable notes
the model keeps inspecting forever because it has no stop condition
An RLM prompt contract exists to make the runtime legible. After reading the prompt, you should be able to predict what the model is allowed to do next.
A Concrete Scenario
Imagine you want help with this task:
Explain why invoice totals drift between the checkout UI, the billing service, and the customer ledger in a 90-file payments codebase.
That is not a "write a clever answer" task. It is an inspect, narrow, compare, and synthesize task. The prompt has to say so.
What A Good Prompt Contract Usually Contains
the question being answered
where the long context lives
what inspection actions are allowed
what artifacts the model may save between passes
how the final answer should be formatted
what should cause the loop to stop
Weak Version
Look through the codebase and figure out why invoice totals are inconsistent. Be careful and thorough.
This sounds reasonable, but it does not define:
whether the model should scan or immediately explain
whether notes are allowed
what a "thorough" answer looks like
when enough evidence has been gathered
Better Version
Query: Explain why invoice totals drift between checkout, billing, and ledger.
Long context is stored externally and can be inspected in pieces.
You may:
- inspect relevant files or sections
- save short notes about functions, data flow, and contradictions
- narrow to smaller regions before synthesizing
Do not answer until you have identified the specific code paths or document sections that support the conclusion.
When finished, output:
FINAL_ANSWER:
1. suspected root cause
2. evidence with file or section references
3. open questions
4. recommended next inspection step if confidence is low
The improved version is still short. It is better because it defines the work shape.
Heuristics
State the external context explicitly.
Tell the model what kinds of intermediate notes are useful.
Give the model permission to inspect before it explains.
Define a final answer format that reflects the real job.
Add a stop condition that prevents endless "one more pass" behavior.
Common Mistakes
asking for a polished essay when you actually need an evidence-backed diagnosis
saying "use tools if needed" without saying which tools or why
saying "be thorough" instead of defining the inspection and output contract
treating the contract like marketing copy instead of an execution policy
Exercise
Take one task you actually care about and rewrite the prompt so it names:
the external context location
the allowed inspection actions
the intermediate artifact shape
the final answer format
the stop condition
Deliverable
By the end of this lesson, you should have a prompt contract that another engineer could read and roughly predict how the recursive loop will behave.
1.2 Designing Recursive Passes
Objective
Move from "the model can recurse" to "the model has a disciplined sequence of passes."
The Core Idea
A recursive system gets useful when different passes do different jobs.
If every pass has the same prompt, the same scope, and the same output shape, you usually do not have a workflow. You have a loop.
Example Workload
Suppose the task is:
Explain how session invalidation actually works across a multi-service auth stack, and identify where stale sessions can survive logout.
That job usually wants more than one pass.
One Sensible Pass Plan
first-pass scan: map the relevant services, files, and data stores
focus pass: inspect the most likely logout and token-revocation paths
contradiction pass: compare intended behavior with the actual persistence and cache paths
synthesis pass: explain the likely failure mode and the evidence trail
verification pass: check the conclusion against the original context before finalizing
Each pass has a different responsibility. That is the point.
If you cannot fill this out clearly, the pass is probably too vague.
Anti-Patterns
a scan pass that already tries to explain the full answer
a synthesis pass that has no saved notes to synthesize
a loop that keeps spawning narrower passes without any termination rule
saving polished prose instead of reusable evidence or structure
Design Heuristics
Make early passes cheap and broad.
Make later passes narrow and evidence-heavy.
Save artifacts that help the next pass, not artifacts that merely sound intelligent.
Use verification as its own pass when the cost of being wrong matters.
Exercise
Choose one workload from your own projects and design three passes using the pass card above.
Keep each pass narrow enough that you could tell whether it succeeded or failed.
Reflection
A good recursive workflow feels closer to a small operating procedure than to a stream of thought. The model should know what phase it is in and what a useful handoff looks like.
1.3 Prompt Iteration Lab
Lab Goal
Run the same workload through progressively better prompt contracts and observe how behavior changes.
Pick A Real Task
Use something that genuinely benefits from inspection, such as:
tracing a bug across several files
reviewing a long technical memo with appendices
comparing design decisions across a large RFC set
Do not choose a tiny one-shot task. The point is to see the effect of better recursive structure.
Run Three Versions
a loose version with a vague request
a contract with explicit actions and final-answer rules
a contract that also defines a simple multi-pass plan
What To Log
For each run, note:
whether the model inspected before answering
whether it produced reusable notes
whether the answer format stayed stable
whether the loop felt focused or meandering
whether you trusted the final answer more
Suggested Scorecard
Give each run a 1-5 score on:
inspection discipline
output stability
evidence quality
overall usefulness
You are not trying to prove that "prompting solves everything." You are trying to see which contract decisions actually change runtime behavior.
Useful Revision Moves
replace vague verbs like "analyze" with allowed actions like inspect, save, compare, and verify
specify what should be stored between passes
name the failure mode you want to avoid, such as premature answers
make the final answer shape reflect the real deliverable
The lesson is not that there is one perfect prompt. The lesson is that better recursive behavior usually comes from clearer action boundaries, better artifacts, and sharper stop rules.
Submission
Write one short note on what changed most between version 1 and version 3. If the answer is "almost nothing," explain why. That usually reveals either a task mismatch or a prompt contract that still lacks real structure.
Chunking, Retrieval, and Selection
Decide what the model should inspect, retrieve, or summarize, and when.
2.1 RLM vs RAG vs Long-Context in Practice
Objective
Choose architectures by workload shape instead of by novelty.
The Practical Question
When people ask whether a system "should use RLM," they are often asking the wrong question.
The better question is:
Where does the difficulty actually live?
If the difficulty is mostly retrieval, use retrieval. If the difficulty is mostly bounded reasoning over a small input, use a simple prompt. If the difficulty is deliberate inspection across a large context with saved intermediate state, an RLM starts to make sense.
Three Working Profiles
Plain Prompting
Best fit when:
the task fits comfortably in one pass
there is one main answer to produce
the model does not need to maintain state across inspection steps
RAG
Best fit when:
the main problem is finding the right source snippets
retrieved evidence can be stuffed into a normal answer prompt
you do not need a long-lived inspection process
RLM
Best fit when:
the model must inspect multiple parts of the context deliberately
intermediate notes matter
the task benefits from decomposition into passes
the final answer depends on connecting evidence gathered over time
Triage Examples
Consider these workloads:
summarize an 8-page strategy memo for an executive
answer support questions across thousands of product documents with good titles and metadata
trace how a production incident unfolded across a large repo, incident review, and runbook set
compare several distant sections of a long policy manual and identify contradictions
A common mapping would be:
plain prompt
RAG
RLM
RLM or RAG-plus-analysis depending on how much deliberate cross-inspection is needed
Warning Signs
choosing RLM only because the context is large
choosing RAG when the real problem is not retrieval but multi-step investigation
choosing plain prompting when the task clearly needs saved intermediate state
Decision Questions
Ask yourself:
Is retrieval the hard part, or is interpretation across many inspected regions the hard part?
Do I need intermediate artifacts that survive across passes?
Would I want to inspect before answering, or is the answer basically immediate once the right evidence is present?
Exercise
Write a five-sentence architecture memo for three tasks you care about:
name the workload
choose plain prompt, RAG, or RLM
explain where the real difficulty lives
name the main artifact or output
name one reason the other two options are worse fits
2.2 Chunking and Inspection Strategies
Objective
Make chunking a deliberate design choice instead of an afterthought.
Why Chunking Matters
Chunking is not just about token limits. It is about preserving the units of meaning that the next pass will need.
Bad chunking quietly destroys the very structure that makes a workload understandable. Good chunking gives the recursive loop something sane to inspect.
Start With Human Structure
Good first candidates are:
section boundaries in papers and reports
file and module boundaries in codebases
scene or segment boundaries in transcripts
appendix, table, or exhibit boundaries when exact details matter
If humans already trust a structure, start there before inventing arbitrary windows.
Think In Two Stages
Stage 1: coarse inspection
Use a cheap pass to identify promising regions.
Stage 2: focused inspection
Read a smaller set of chunks in depth and save notes that justify why they matter.
This is often better than pretending every chunk deserves equal attention.
What To Save Between Passes
chunk ids or file names worth revisiting
short evidence notes with references
contradictions or open questions
regions that looked relevant but need verification
Saved artifacts should help the next pass choose where to look, not just summarize what was read.
Failure Modes
splitting directly through meaningful boundaries
chunking so coarsely that every inspection pass becomes expensive
chunking so finely that the model loses surrounding context
summarizing too early and throwing away exact evidence
A Useful Design Loop
choose the first chunk unit
decide how a scan pass will rank or shortlist chunks
define what artifact the scan pass should save
decide how focused passes will revisit the shortlist
verify that important evidence can still be recovered exactly
Exercise
Take one real source pack you work with and answer:
what should the first chunk unit be
what will the scan pass save
what would trigger a deeper pass
what evidence must remain exact instead of summarized
Playground Preview
The code exercise below is intentionally small. It does not build a real retriever. It makes one idea concrete: first-pass selection should be explicit and inspectable, not magical.
Code Playground
Implement rank_chunks(chunks, query, top_k=3).
Rules:
tokenize to lowercase alphanumeric words
score each chunk by the number of distinct query tokens it contains
higher score ranks first
break ties by lower original index
return at most top_k indices
exclude chunks with zero score
This is a toy first-pass selector, not a production retriever.
2.3 Architecture Checkpoint Quiz
Checkpoint
This checkpoint is meant to sharpen judgment, not test memorization.
Treat each question like a miniature architecture review. The goal is to notice what kind of problem is actually in front of you.
What A Strong Answer Usually Reflects
where the main difficulty lives
whether retrieval alone is enough
whether saved intermediate artifacts matter
whether chunking preserves the right structure
After The Quiz
Write a short note with:
one task where RLM is clearly justified
one task where RAG is the simpler answer
one task where a plain prompt is enough
one task where your first architecture choice changed after thinking harder
Quiz
A task fits in context, needs one grounded answer, and does not require multi-step inspection. Which pattern is usually the simplest default?
Correct: Plain long-context prompting or a simple prompt path.
You have thousands of product documents with decent titles and metadata, and the main challenge is fetching the right evidence for support answers. Which pattern is usually the best starting point?
Correct: RAG, because retrieval is the main problem and the final answer can likely be produced in one normal pass once the right evidence is present.
When does an RLM start to earn its complexity?
Correct: When the model must inspect multiple parts of a large context deliberately and maintain intermediate state.
What is usually the best first chunking strategy for long technical documents or codebases?
Correct: Structure-aware chunks aligned to headings, sections, or file boundaries when available.
When a scan pass finds promising regions, which saved artifact is usually the most useful for the next pass?
Correct: A short evidence note with chunk or file references and why each region matters.
A recursive loop keeps wandering, answers early in some runs, and over-inspects in others. What is the most likely first thing to fix?
Correct: Clarify the action contract, saved artifacts, and stop condition before changing anything else.
Applied Workflow Blueprints
Translate the pattern into concrete workflows you would actually use.
3.1 Large Codebase Analyst Pattern
Pattern
Large codebases are one of the most natural fits for an RLM-style workflow because understanding usually depends on deliberate inspection, note-taking, narrowing, and revisiting.
A Realistic Scenario
Suppose the question is:
Why do mobile users sometimes remain authenticated after logout, while web users do not?
That question is rarely answered by one file. You may need to inspect:
the logout entry point
token issuance and refresh logic
cache invalidation or session-store behavior
client-specific branches
background jobs or async cleanup paths
A Strong First Pass
The first pass should not try to solve the bug. It should map the terrain.
Useful first-pass outputs:
relevant services or directories
likely entry points
file names worth a second look
open questions about state changes or side effects
What To Store As Notes
Store artifacts that can survive the next pass:
file path
why it matters
symbols or functions to revisit
observed state transition
contradiction or uncertainty
Example Note Shape
File: auth/session_store.py
Why it matters: handles token invalidation writes
Important symbol: revoke_refresh_token()
Observed behavior: writes to store but no cache bust
Open question: does mobile read from cache first?
A Strong Second Pass
A second pass should be narrower. It might compare the suspected invalidation path against the read path used by mobile clients.
Good second-pass questions:
where is session state read after logout
which paths are synchronous vs deferred
what differs between web and mobile flows
which assumptions from pass one need verification
Output That Is Actually Useful
A good final answer is usually not "here is my vibe about the repo."
It is closer to:
likely root cause
supporting files or symbols
the confidence level
open questions
the next file or trace to inspect if confidence is incomplete
Exercise
Choose a codebase you know and sketch:
what the first scan should inspect
what note schema you would save
what would trigger a deeper second pass
what a trustworthy final answer would need to cite
3.2 Long-Document Review Pattern
Pattern
Long-document review is a good RLM use case when the answer depends on connecting distant sections, comparing claims, or reconstructing timelines across a source pack.
A Realistic Scenario
Imagine you need to answer:
Does this 180-page incident review actually support the operational recommendations in the executive summary?
That is not just a retrieval task. You may need to compare the summary, timeline, technical appendix, witness notes, and remediation plan.
Useful Moves
scan headings and section roles before reading closely
identify the parts most likely to contain direct evidence
extract evidence before writing a polished synthesis
keep a running list of contradictions and unanswered questions
High-Value Intermediate Artifacts
Evidence ledger
Save short evidence snippets with section references.
Claim map
List important claims and where the document appears to support or weaken them.
Contradiction log
Record places where two sections seem to disagree or where the summary outruns the evidence.
Example Evidence Note
Claim: cache invalidation happened within 2 minutes
Evidence: Section 4.2 says invalidation job ran at 09:13
Counter-evidence: Appendix B shows stale cache hits until 09:21
Status: unresolved
Final Answer Shapes That Work
an evidence-backed summary with exact citations
a contradiction report
a timeline reconstruction
a recommendation memo with confidence notes
Common Failure Modes
summarizing before evidence extraction
losing section references in intermediate notes
collapsing uncertainty into false confidence
treating every document region as equally important
Reflection
Describe one long-document workflow you care about and answer:
what evidence must be preserved exactly
what can be safely summarized
what kind of contradictions you expect
what final answer format would actually help the reader
3.3 Workflow Blueprint Studio
Studio Goal
Turn the ideas from this course into a workflow blueprint you would actually want to run.
The Standard
A good blueprint is concrete enough that another builder could implement a first version without guessing your intent.
If the blueprint only says "use recursion intelligently," it is still a concept, not a workflow.
Blueprint Template
Write the blueprint in these sections:
workload and user question
context shape
first inspection pass
deeper follow-up passes
saved intermediate artifacts
stop conditions
final answer contract
evaluation plan
A Minimal Blueprint Skeleton
Workload:
User question:
Context shape:
First pass:
Follow-up passes:
Saved artifacts:
Stop conditions:
Final answer:
Evaluation:
What Makes A Blueprint Strong
the first pass is cheap and purposeful
later passes are narrower, not just repeated
saved artifacts are reusable
stop conditions prevent endless wandering
the final answer shape matches the real job
evaluation is concrete enough to reveal failure modes
Capstone Exercise
Design one blueprint for a workload you genuinely care about. Good candidates include:
large codebase debugging
research or policy review
multi-document due diligence
transcript or media analysis
Optional Sidecar With NotebookLM
If you want richer source-grounded material before building the workflow, use a sidecar tool like NotebookLM to extract examples, contradictions, and source summaries. Then turn those outputs into better tasks and checkpoints rather than copying them directly into the final answer.
Next Step
If Foundations taught you how an RLM works, this course should leave you with a clearer sense of how to apply one. Systems Lab is where you make that workflow safe, measurable, and defensible.