Read the Manual: Self-Training on Demand

The agent already fetches its own context

Give an agent a read tool and a search tool, and it pulls in what it needs, when it needs it: file contents, query rows, the relevant section of a long document. We've designed those results with care — handles, search, ask — and in every example so far, what the agent fetched was facts: the typo in the config file, the night-delivery rules, the enrollment numbers.

But we established that there is no wall. Anything that enters the conversation can instruct — and in the earlier examples it was the tool's designer who used that power, steering from the result side at the moment of need. Now hand the same power to the other end of the call:

A manual is just a document.
Reading is just a tool call.

So training is something the agent can fetch for itself —
and CHOOSING what to read becomes part of doing the task.

A one-line description, and a manual behind it

Here is what that looks like as tool design. Instead of a long description that tries to teach everything, the tool carries a pointer:

⟨tool_use⟩
read_manual(name = "xrf-quickstart")

⟨tool_result⟩
XRF Quickstart (4 sections). §1 Modes: use mode="mining" for
geological samples, "alloy" for metals. §2 Duration: 60s minimum;
powdered samples need 120s. §3 The first run after power-on is a
calibration run — discard its readings. §4 Never analyze samples
above 400°C.

⟨tool_use⟩
run_xrf(sample = "S-19", mode = "mining", duration_s = 120)

⟨tool_result⟩
Calibration run complete (readings discarded, per quickstart §3).
Re-run to collect data.

⟨tool_use⟩
run_xrf(sample = "S-19", mode = "mining", duration_s = 120)

The library, not the longer preamble

Why not just put the quickstart in the tool's description? Recall the economics: everything in the preamble is reprinted on every iteration, needed or not. A lab with twelve instruments, each needing a page of instruction, is twelve pages billed on every turn of every conversation — including the conversations that never touch an instrument at all.

The index is the trick. A manual's title works like a tool's name — a pointer, nearly free — and the knowledge behind it costs nothing until some trajectory actually fetches it. Front-load the index; shelve the training.

Manuals for situations, not just tools

Nothing restricts the library to tool documentation. The chapters can be how we do things here — procedures, policies, house rules — and then the agent's first judgment is a librarian's judgment: which chapter is this task in?

⟨tool_use⟩
search_manuals(query = "visiting researcher data access")

⟨tool_result⟩
2 matches: "data-governance" §5 External collaborators;
"onboarding" §2 Guest accounts.

⟨tool_use⟩
read_manual(name = "data-governance", section = "5")

⟨tool_result⟩
§5: External collaborators receive read-only access, term-limited,
after the data steward is notified by email. Access must name a
specific dataset — never "all sensor data."

⟨tool_use⟩
send_email(to = "data-steward@…", subject = "External access:
NTNU visiting researcher", body = "Notifying per governance §5…")

⟨tool_use⟩
grant_access(user = "visitor-ntnu-01", dataset = "sensor-array-2",
             until = "2026-12-20")

You have already watched an agent do this

This pattern is not hypothetical — it is how the strongest working agents operate today. A coding agent dropped into an unfamiliar repository does not arrive knowing the project's conventions. It reads the README. It reads the contributing guide. Many projects now keep a file written specifically for agents — instructions on how to build, test, and behave in that repository — and the agent reads it first, exactly like a new hire reading the onboarding wiki.

That fourth line deserves a pause. Two agents given identical tools and identical preambles can end the day differently trained — each shaped by which chapters its own tasks made it read. The training is not in the agent; it is in the library, and each trajectory assembles the subset it needed.