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

The Scientist and the Designer

35 minoutcomes: agent-architectures

One loop, two spaces

The Explorer finds what exists. The next archetype answers a different kind of question — why is this happening? or what should we build? — where the answer doesn't sit in any file waiting to be found. It must be proposed, and then tested. The shape:

The propose–test loop

The division of labor

The MIND guesses. The MACHINE grades.

Proposing takes judgment — imagination constrained by
knowledge. Testing must be exact — a simulator, a query,
a measurement, run by code with no opinions.
This is the verification asymmetry, made into an
architecture: generation needs a mind; checking needs a rule.

Classification first: this is a single-conversation archetype. The proposing and interpreting accumulate on one wall — the hypotheses, the evidence, the shrinking space are one trajectory — while the tests themselves run outside it, as tools.

One loop — but it comes in two faces, depending on what space the mind is searching. The Scientist searches explanation space: which story about the world is true? The Designer searches configuration space: which buildable thing meets the constraints? Same skeleton, different destination — and the differences are exactly where the design decisions live.

The Scientist: searching explanations

Example 1 · The drift anomaly
user

Sensor array 2 shows calibration drift starting sometime in October — way beyond aging curves. Figure out why. Tools: query_readings(sensor, range), query_logs(system, range), get_weather(station, range).

assistant

Three hypotheses fit what I know: (H1) accelerated aging — drift should be gradual and affect the oldest sensors most; (H2) storm damage — the October 19 storm; drift should begin abruptly at that date on exposed sensors; (H3) the November firmware update — drift should begin at deployment, all sensors equally. Cheapest discriminating test: the onset date, one query, and the three hypotheses predict three different shapes.

assistant
⟨tool_use⟩
query_readings(sensor = "array-2/*", range = "Sep–Dec",
               resolution = "daily")
user
⟨tool_result⟩
Drift onset: abrupt, Oct 19–20, sensors S-3, S-4, S-7 only.
S-1, S-2, S-5, S-6 nominal through December.
assistant

One query, two hypotheses dead: gradual aging doesn't start overnight, and the firmware update was three weeks later. H2 survives — and it made a further prediction I can check: S-3, S-4, S-7 should be the exposed, seaward-facing mounts.

assistant
⟨tool_use⟩
query_logs(system = "installation", range = "array-2")
user
⟨tool_result⟩
Mounting: S-3, S-4, S-7 — south quay, unsheltered. Others:
instrument shed.
assistant

Confirmed on an independent line of evidence: the drift is storm damage to the three unsheltered mounts, onset matching the Oct 19 storm. Recommend physical inspection of the south-quay mounts; aging and firmware are cleared.

NoteRead what the judgment did and didn't do. It never computed — every fact came from an exact query. It proposed the space of stories, derived what each predicts, and chose the test that splits them. That last skill is the whole art, and it deserves its own name.

The discriminating test

Three candidate tests, unequal value

The hypotheses:H1 aging · H2 storm · H3 firmware
TEST A:re-run full calibration suite (3 days, on-site) …would show drift exists. All three predict that. Cost: huge. Discrimination: ZERO.
TEST B:query drift onset shape (one query, free) gradual/oldest-first → H1 · abrupt Oct 19 → H2 · abrupt at deploy, all sensors → H3 Cost: nothing. Discrimination: TOTAL.
TEST C:inspect mounts physically (1 day, on-site) …decisive for H2, silent on H1 vs H3. Right test — LATER, as confirmation.

The two rules of testing

1. A test every hypothesis passes teaches nothing.
   Choose tests whose OUTCOMES DIFFER across your hypotheses.

2. Cheapest decisive test first.
   Spend queries before simulations, simulations before
   lab days, lab days before rebuilds.

The Designer: searching configurations

Now the same loop pointed at artifact space. The question isn't "which story is true?" but "which configuration works?" — and the experiment isn't a query against the world but a simulation of the candidate:

Example 2 · Designing the survey drone
user

Configure a drone for the fjord bird-cliff survey: ≥ 40 min endurance, ≥ 800 g camera payload, wind-rated 12 m/s, parts from our approved catalog only. Tools: catalog_search(type, constraints), check_assembly(config), simulate(config, mission).

assistant

Starting hypothesis: the standard survey frame. Quad frame QF-4, four M-220 motors, 6S 8Ah battery, gimbal + camera at 780 g.

assistant
⟨tool_use⟩
check_assembly(config = "QF-4 / 4×M-220 / 6S-8Ah / cam-780")
user
⟨tool_result⟩
Valid assembly. Total mass 3.4 kg.
assistant
⟨tool_use⟩
simulate(config = "…", mission = "cliff-survey-profile")
user
⟨tool_result⟩
Endurance 31 min (FAIL ≥40) · payload OK · wind: marginal at
12 m/s (FAIL) — gusts induce 15° attitude excursions.
assistant

Two failures, and they pull in opposite directions: endurance wants a bigger battery, wind stability wants less mass and more motor authority. The intuitive move: don't grow the battery — switch to the higher-density HD-6 cells (same mass, +22% capacity) and step up to M-260 motors for gust authority, accepting their higher draw.

assistant
⟨tool_use⟩
simulate(config = "QF-4 / 4×M-260 / 6S-8Ah-HD / cam-780",
         mission = "cliff-survey-profile")
user
⟨tool_result⟩
Endurance 43 min · payload OK · wind: stable at 12 m/s, 6°
excursions. ALL CONSTRAINTS MET. Margin: endurance +7%.
NoteThe search space here is enormous — but bounded: an approved catalog, assembly rules the checker enforces. That's the road network again: because the space has structure, the mind's moves stay sane. And look at the move itself — "the failures pull in opposite directions, so change the battery chemistry, not its size." That is taste, applied to a fork in configuration space. No enumerable label set could contain it; that's why this is an archetype of agency.

Truth versus artifact

One skeleton, two faces

THE SCIENTISTTHE DESIGNER
searchesexplanation space configuration space
proposesa story about the a buildable candidate world
the testquery / measurement simulation / prototype
against what ISof what COULD BE
a failed testkills a story — teaches a direction —
meansthe space shrinks "endurance low, wind marginal" is a gradient
stops whenone explanation constraints met and
survives, atgood enough — or the
stated confidencebudget says stop

That last row is not a footnote. In both faces, termination is a contract, written before the loop starts — a confidence to reach, constraints to satisfy, a budget of tests to spend. The propose–test loop has no natural end: there is always another hypothesis, always a configuration with 2% more margin. An unterminated Scientist is a conspiracy theorist; an unterminated Designer never ships. The stopping rule is a design artifact, exactly like the label set and the tool language.

The archetype in your fieldwork
  • Take a "why" question from your research. Write three hypotheses and the single cheapest test that discriminates among them. If you can't find one — what pair does your best test split, and what's the sequence?
  • In Example 2, the simulator is trusted completely. What is the Designer's failure mode when the simulator is slightly wrong — and which archetype from the checking lessons does the finished design deserve before it flies?
Your turn

Build one of each on paper, from your domain. Scientist: an anomaly you've actually met — hypotheses, each one's predictions, the discriminating-test table with costs, the termination contract. Designer: an artifact with real constraints — the bounded space (catalog, rules), three propose–simulate–interpret rounds written out, and the stopping rule. Then compare your two loops line by line: what did the failed test mean in each?