Module 3 · Planning, Context & Multi-agent Systems · scripted

The Explorer

30 minoutcomes: agent-architectures, context-engineering
🎤 Talk view← Cockpit

The top rung, earned

The spectrum ended with a warning: reach for the loop last, and climb only when the world refuses enumeration. Now we're climbing — because some problems genuinely cannot be drawn as a flowchart in advance. This lesson and the three after it are archetypes: recurring shapes for spending agency well once you've established you need it. The first is the Explorer, and it is the exact mirror of the workflow we just built:

The inversion

CODE AT THE FORKS          THE EXPLORER
minds in the steps,        code in the steps,
code at the forks          a mind at the forks

the path is known;         the path is DISCOVERED;
judgment fills in          judgment IS the path-choosing —
the steps                  every tool is plain, dumb,
                           deterministic code

One classification, which we'll track for every archetype: the Explorer is a single-conversation archetype. The entire investigation lives on one wall — which is both its power (every lead in view) and, as we'll see, its bill.

The Explorer's world: the terrain can only be learned by walking it. Each step's result reshapes the question — so the fork after it cannot be pre-written, not because the branches are many, but because they don't exist until the result is read.

Following the leads

Example 1 · Where did 4.2% come from?
user

You have the following tools available for use:

  1. list_files( folder )
  2. read_file( path )
  3. search_files( pattern )

Task: The annual report claims operating costs fell 4.2%. The board is asking where that number comes from. Trace it to its source.

assistant
⟨tool_use⟩
search_files(pattern = "4.2%")
user
⟨tool_result⟩
3 hits: annual-report.pdf p.7 · q3-finance-memo.docx ·
board-slides-oct.pptx
assistant
⟨tool_use⟩
read_file(path = "q3-finance-memo.docx")
user
⟨tool_result⟩
"…operating costs decreased 4.2% year over year (see
cost-model-v3.xlsx, 'summary' sheet)…"
assistant
⟨tool_use⟩
read_file(path = "cost-model-v3.xlsx")
user
⟨tool_result⟩
Sheet 'summary': YoY change = −3.1%. Sheet 'summary-adj': −4.2%
(note: "excl. one-time relocation costs, per Erik").
assistant

The trail forks in an interesting way: the memo cites the model, but the model's main figure is −3.1% — the −4.2% comes from an adjusted sheet that excludes relocation costs, on an instruction attributed to "Erik". The question has changed: it's no longer "where is the number" but "who authorized the adjustment, and was it disclosed". I'll search for the relocation-exclusion decision next.

assistant
⟨tool_use⟩
search_files(pattern = "relocation")
NoteWatch the shape of this trajectory. No step was plannable before the previous result was read: the memo named the spreadsheet; the spreadsheet revealed the discrepancy; the discrepancy rewrote the question. Three dumb tools — list, read, search — and every ounce of intelligence spent between them, deciding what the last answer means for the next move. That deciding is what a pipeline cannot do, and it is exactly what we're paying for.

This is the Explorer everywhere it appears: the auditor tracing a figure, the engineer debugging an unfamiliar codebase with grep and a test runner, the historian in an archive. The tools read the world; the mind follows the leads.

Why the tools stay dumb

It's tempting to make the Explorer's tools clever. Resist it — the archetype works because the tools are plain:

The Explorer's tool checklist

EXACTread_file returns the file — not a guess, not a summary with opinions. The mind does the interpreting; the tools must not pre-chew it.
CLOSEDevery result names things other tools accept: files, paths, ids. The lead must be followable — a result that describes without naming is a dead end on unknown terrain.
READER-FIRSTresults are written for a mind at a fork: Goldilocks-sized, handles for the bulk, errors that teach. On this architecture the results ARE the interface to the world — every design lesson about them is now load-bearing.

The one enhancement that fits: the retrieval rungs. Give the Explorer string search and meaning search and ask-the-document — dumb, dumber, and one-thought — and let it choose the rung per lead. The intelligence stays at the fork; the rungs are just better legs.

The map lives on the wall

Now the price, and it must be paid knowingly. The Explorer has no external flowchart — the investigation's state exists only in the conversation: what was checked, what it revealed, which leads are open, which died. The wall is the map. That means:

The Explorer pays full fare

every iteration re-reads the whole investigation
(the re-orientation tax, at its steepest)
every dead lead's evidence is a bar that has ended —
cargo, unless managed
the lifetime chart is unknowable in advance —
every lifetime is a bet made mid-walk

So the Explorer, of all the archetypes, leans hardest on the management techniques: compact into case notes when the wall bloats (leads followed → one line each; open leads → carried), file the dead trails behind addresses, and let instructive errors re-teach what the notes dropped. An investigation that never summarizes itself drowns in its own diligence.

Example 2 · The case notes
assistant
⟨tool_use⟩
compact_conversation(max_words = 300)
user
⟨tool_result⟩
CASE NOTES (replacing 23 steps): Tracing −4.2% claim.
ESTABLISHED: figure originates in cost-model-v3 'summary-adj';
excludes relocation costs; adjustment requested by E. Moen
(email, 12 Oct); not disclosed in report footnotes. DEAD ENDS:
board slides (copy of memo); v1/v2 models (superseded). OPEN:
(1) was exclusion policy-compliant — audit policy §7 unread;
(2) who approved Moen's request. Archived: conv-91.
NoteThe investigation continues from one paragraph — and everything in it is a live lead or a settled fact. The 23 steps of walking are filed, not gone. This is the whole context toolkit, deployed under the archetype that needs it most.

When the Explorer is the right shape

The Explorer test

Choose this archetype when ALL three hold:
  1. the forks cannot be enumerated — each result rewrites
     the question
  2. the world is readable through plain tools — the facts
     are THERE, in files, databases, systems; they need
     finding, not explaining
  3. the task ends when something is FOUND — a source, a
     cause's location, an answer with a citation

When the task ends not with finding but with EXPLAINING —
competing stories about why, tested against evidence —
you want the next archetype.
Reading the archetype
  • In Example 1, identify each moment the question changed. Could a label set have anticipated those forks? What would the classifier's brief even say?
  • The Explorer's tools must not pre-chew — but the case notes are pre-chewed by definition. Why is one corruption and the other discipline?
Your turn

Pick a genuine trace question from your world: where a number in a paper came from, why a config value is set, which meeting decided a policy. (1) List the dumb tools the terrain needs — nothing clever. (2) Walk the investigation on paper for six steps, writing each result and the changed question after it. (3) Mark the step where you'd compact, and write the case notes. (4) Verdict: did any step's fork turn out to be enumerable in advance — and could a cheaper archetype have handled that stretch?