Module 2 · Tools, Knowledge, Memory & Research Design · scripted

The Table of Contents

30 minoutcomes: context-engineering, knowledge-systems
🎤 Talk view← Cockpit

Every conversation begins in rediscovery

Return to the hardest fact we know, and read it this time as an engineering constraint. The LLM has no memory. Every prompt is a rediscovery — the whole situation, reconstructed from the words on the wall. And every new conversation starts from absolute zero: whatever context the task needs must be built up, again, from nothing. Look at the bill:

The bootstrap bill

A fresh conversation, before it can do ANY useful work, must come to hold:

what the task iswhat the constraints are
what the domain's ruleswhat's been done already
arewhere the relevant things live
which tools existwhat "correct" looks like

…and it must acquire all of this THROUGH the conversation — there is no other door. Whether we push it in up front, or the agent pulls it in on demand, the question is the same:

given this task, how do we FIND the right context — and only the right context — at minimum cost?

That question needs an architecture, not a trick. And the remarkable thing is that you already own the architecture — you've used it your whole life.

You already know the answer

You need one fact from a 400-page policy handbook: the meal allowance for travel abroad. Nobody — nobody — reads the book.

How a human finds one fact in 400 pages

TABLE OF CONTENTS(1 page)
"Ch. 7 — Travel and Expenses" ......... p. 214
CHAPTER 7 OVERVIEW(half a page)
"7.1 booking · 7.2 domestic rates ·
7.3 international per-diem · 7.4 exceptions"
SECTION 7.3(2 pages)
…the answer.

Pages read: 3.5 of 400. And every page you read was CHOSEN — by you, the one person who knows what you're looking for.

Now the same walk, performed by an agent with three plain tools:

Example 1 · The agent reads like a human
user

You have the following tools available for use:

  1. get_toc( doc )
  2. read_overview( doc, chapter )
  3. read_section( doc, section )

Task: What's the meal allowance for conference travel to Japan?

assistant
⟨tool_use⟩
get_toc(doc = "policy-handbook")
user
⟨tool_result⟩
1. Employment basics … 2. Facilities … 7. Travel and Expenses …
12. Data governance … [14 chapters, one line each]
assistant
⟨tool_use⟩
read_overview(doc = "policy-handbook", chapter = "7")
user
⟨tool_result⟩
7.1 booking rules · 7.2 domestic travel rates · 7.3
international per-diem (by country group) · 7.4 exceptions and
approvals
assistant
⟨tool_use⟩
read_section(doc = "policy-handbook", section = "7.3")
user
⟨tool_result⟩
[2 pages: country groups, rates table — Japan: group A,
940 kr/day, meals covered at 60%…]
assistant

Japan is per-diem group A: 940 kr/day with meals at 60% — so 564 kr/day for meals on conference travel.

NoteCount what the wall carries: a 14-line contents page, a 4-line overview, one 2-page section — call it 40 lines, out of a 400-page book. And at every hop, the agent chose the branch, because the agent is the one holding the task. Navigation replaces reading — and the chooser is the one who knows why.

The principle

Don't bring the book to the reader.
Bring the reader a table of contents — and let every
page that enters the conversation be one the task CHOSE.

Why trees: the mathematics of not reading everything

What you just watched has a shape — a tree: one root, branches, sub-branches, leaves. And trees are not just tidy; they have mathematics, and the mathematics is the whole reason this works. Two numbers govern everything: the branching factor (entries per level) and the depth (hops to a leaf):

The arithmetic of an index

10 entries per level, 3 levels deep:

reachable leaves:10 × 10 × 10 = 1,000 sections
cost of ANY lookup:3 reads of ~10 lines each

10 entries per level, 6 levels deep:

reachable leaves:1,000,000
cost of ANY lookup:6 reads. Six.

Growth is exponential in depth; lookup cost is LINEAR in it. Doubling the library adds ONE hop — not double the reading.

And now say it in the currency this course cares about, because this is the property no other context structure we've met can offer:

The bounded-wall guarantee

The wall cost of a lookup is bounded by the DEPTH of the
tree — not by the SIZE of the corpus.

depth × (lines per index page) = the whole bill.

The library behind the index can grow a thousandfold,
and the conversation's cost for finding any one thing
stays flat. The tree is how a small wall commands an
unbounded shelf.

Knowledge graphs, and why the tree is the default

You will hear a great deal about knowledge graphs — entities, relations, edges everywhere. They are genuinely useful, and they are one of many representations. But when the task is "let an agent find what it needs," the humble tree should be your default, and the reasons are exactly the properties graphs give up:

Tree vs. graph, as navigation architecture

TREEGENERAL GRAPH
where do I start?the root — always …good question one, always known
cost of a lookupbounded: ≤ depth unbounded — paths wander, cycles loop
can I estimate costyes: b and d tell rarely — depends
before building?you everything on connectivity
does the model alreadydeeply — books, conventions vary
know the conventions?folders, outlines per graph

The rule that falls out:

The default rule

If the knowledge CAN be a tree, make it a tree.
Where reality refuses — a topic that truly belongs in two
places — add a cross-reference link, the way books have
always done ("see also §7.4").

Reach for richer structures only when the RELATIONS are
the knowledge. Navigation wants a root.

The filesystem is a tree you already have

Here is the practical gift waiting at the end of this idea: you do not need to build this architecture. Every computer ships with it. Folders contain files and subfolders; those contain more; one structure, arbitrarily deep — and, critically, the model has read millions of well-organized projects. The conventions — a README at the root, names as labels, nesting as decomposition — are trained in. Hand an agent an organized folder and it already knows how to walk it:

Example 2 · Dropped into a folder, cold
user

You have the following tools available for use:

  1. ls( path )
  2. read_file( path )

Task: You've been given the folder for our fjord-monitoring project. Find the calibration procedure for the salinity sensors.

assistant
⟨tool_use⟩
ls(path = ".")
user
⟨tool_result⟩
README.md · data/ · instruments/ · reports/ · admin/
assistant
⟨tool_use⟩
read_file(path = "README.md")
user
⟨tool_result⟩
"Fjord monitoring project. data/ = raw exports by month.
instruments/ = per-instrument docs and procedures. reports/ =
weekly summaries. admin/ = contracts, access."
assistant
⟨tool_use⟩
ls(path = "instruments/")
user
⟨tool_result⟩
salinity-array/ · temperature-chain/ · weather-station/
assistant
⟨tool_use⟩
read_file(path = "instruments/salinity-array/calibration.md")
user
⟨tool_result⟩
[the procedure: monthly calibration, reference solution, the
two-reading rule…]
NoteFour calls, cold start, no instructions about how to navigate — because none were needed. The folder structure IS the table of contents, and its conventions decompress from the model's training like any well-known word. One warning rides with the gift: this works because the folder is organized. A dump of 743 files named final_v2_REAL.docx decompresses into nothing. The tree must actually be a tree.

Writing the tree: knowledge that outlives the conversation

So far the agent has been the tree's reader. Now the move that completes the architecture: the agent can be its author. A conversation that did real work — decisions made, dead ends found, results established — usually preserves it, if at all, as a transcript. But a transcript is a terrible representation of knowledge: the decisions are buried in the walking. The better move, and it costs a few tool calls:

Example 3 · The conversation writes its legacy
user

You have the following tools available for use:

  1. write_file( path, content )

Task: Good stopping point — capture where we are for whoever picks this up.

assistant
⟨tool_use⟩
write_file(path = "notes/INDEX.md", content = "START HERE.
Project state as of 2026-09-18:
· GOAL: see notes/goal.md (unchanged)
· DECIDED: mixed models over ANOVA — why: notes/decisions.md
· DEAD ENDS: two approaches ruled out — notes/dead-ends.md
· OPEN: reviewer 2's power question — notes/open-questions.md
· DATA: cleaned set at data/v3/ — do NOT use v2 (unit bug)")
assistant
⟨tool_use⟩
write_file(path = "notes/decisions.md", content = "[each
decision, three lines: what, why, what it rules out]")
NoteAnd weeks later, a brand-new conversation — total amnesia — begins with one instruction: "Read notes/INDEX.md first." Three reads later it knows the goal, the decisions, the traps, and the one thing it must not touch. The tree is how one conversation trains its successors: not by leaving a transcript of everything it said, but by writing the table of contents it wishes it had been handed.

The two directions

READ the tree:   bootstrap this conversation from the
                 structure someone left.
WRITE the tree:  leave the structure the next conversation
                 will bootstrap from.

An agent that does both has something an LLM cannot have:
a memory — kept in folders, addressed by an index,
paid for only when walked.

Choosing the structure: how would you train a human?

One question remains: facing a new domain, how do you decide what the tree should be — what the branches are, what lives at the leaves? Here is the heuristic that almost never fails: ask how the discipline trains a brand-new human. Every mature field has already invented, tested, and debugged its training architecture on generations of confused beginners:

Pre-validated trees, everywhere

MEDICINEprotocols and checklists — indexed by situation, one page each, drill-down to the rare cases
A LABthe SOP binder — one procedure per tab, front page = the index of tabs
OPERATIONSthe runbook — symptom → page → steps, written to be read at 3 a.m.
A KITCHENthe recipe canon + the station layout — what to make, and where everything is

Every one of these is a tree with an entry point, grown to train zero-knowledge humans fast. Steal it: the folders and files are already designed — they're just not written down as folders and files yet.

The training heuristic

When you don't know how to structure a domain's context,
ask: how would we train a new employee to do this?

The structures that teach humans are pre-validated
context architectures. You rarely need to invent the
tree — the discipline already grew one.
Stress-testing the tree
  • Find the cross-cutting concern in your field — the topic that honestly belongs under three branches at once. Does a "see also" link solve it, or is this the case where the tree genuinely fails?
  • In Example 3, what did the agent choose NOT to write down? Propose one rule for what earns a line in INDEX.md — and what should stay buried in the transcript.
Your turn

Take a real corpus from your research world — a regulation, a methods literature, your own project's accumulated material. (1) Design its tree: the root index, the branching factor, the depth; justify both numbers. (2) Walk two realistic lookups on paper, counting the wall cost at every hop. (3) Write the INDEX.md — the actual text — that would make a zero-knowledge agent (or a new student) productive in three reads. (4) Name the discipline whose human-training structure you just stole, and what you changed.