Module 3 · Planning, Context & Multi-agent Systems · scripted
Lifetimes: What the Conversation Should Carry
The path
To engineer extraneous load, we first need a way to see it. Start with a picture of what a task actually is. An agent's task is a path through decision points: at each node, the loop stands still, the whole conversation is presented, and one choice is made — the next step.
A task is a path through decisions
And at each node, the question that defines this whole lesson: what does the conversation need to contain — for this choice?
Information is born, and information dies
Every piece of context has a history along the path. It is born at some node — a result arrives, a decision gets made — and it dies at the last node whose choice depends on it. Chart the expense task, with a bar for each item's life:
The lifetime chart
This gives extraneous load its exact definition — sharper than "too much stuff":
The definition
EXTRANEOUS LOAD = anything on the wall past the end of its bar. Not wrong information. Not useless information. Information whose last decision is BEHIND it — still being re-read, every iteration, by a reader who cannot know it's dead.
The default: everything lives forever
Now the uncomfortable fact about the medium. A conversation, left alone, has one policy for every word ever said: visible to every later decision, forever. The receipts stay after C. The dead-end attempts stay. The 187 pages stay. The conversation is a room where nothing is ever taken off the table.
And it's worse than storage, because of who reads it. Recall the plays: the model is an actor, trained on documents where what is present matters. Everything on stage is a promise. A prop on the table in act one tells the actor it will be needed; a dead result left on the wall isn't ignored — it is interpreted, held as possibly-relevant, woven into reasoning it should never touch. The venue disaster from the previous lesson is exactly this: nine pages of props, two lines of play.
The medium vs. the task
The TASK gives each piece of information a natural lifetime: born at a node, dead after its last use. The CONVERSATION gives every piece the same lifetime: forever. Managing extraneous load = closing the gap between the two.
Carry · Fork · File
Closing that gap is a discipline of three verbs, and you already own the machinery for all of them:
The three verbs
The interesting verb is fork, and the chart tells you exactly where it applies. Look back at the expense chart: nodes B–C are a segment where "statement rows" and "mismatch details" are born and die entirely inside — only "resolutions" escapes. That shape is the signature of a forkable segment:
The forkability test
A segment can become its own conversation when the cut is thin: · the brief going IN is small and bounded · the result coming OUT is small and composable · no other bar crosses the boundary Information that lives together and dies together belongs in a conversation together.
You have the following tools available for use:
- start_conversation( template, task )
- read_result( conversation )
Task: Reconcile the Molde trip expenses and report anything over policy.
⟨tool_use⟩
start_conversation(template = "reconciler",
task = "Match these 34 receipts to this card statement.
Resolve mismatches. Return: matched list + unresolved items
with one-line reasons. Receipts: [...] Statement: [...]")⟨tool_result⟩
Started: c-317.⟨tool_use⟩
read_result(conversation = "c-317")⟨tool_result⟩
Ended. Result: 31 matched. 3 unresolved: r-12 (no matching
charge), r-19 (amount differs by 112 kr), r-27 (duplicate?).⟨tool_use⟩
check_policy(expenses = "matched-31 + r-19")Every lifetime is a bet
Now the honest part — the part that makes this engineering rather than bookkeeping. The chart looks authoritative, but the path is discovered as it is walked: tasks branch, tools surprise, the 1% case arrives. You draw the bars in advance; the world draws them in ink. Two failures follow, and you've already asked about both:
Wait — r-19's difference of 112 kr: the department head is asking if that was a currency conversion issue. What was the original receipt currency?
That detail lived in the reconciliation — which ended. Its conversation was archived; I'll ask it.
⟨tool_use⟩
ask_history(conversation = "c-317", question = "Receipt r-19:
original currency, amount, and the matched charge's amount?")⟨tool_result⟩
r-19: 890 NOK receipt; matched charge 1,002 NOK (foreign
transaction fee applied by card issuer, noted at step 11).It wasn't a conversion error — the card issuer added a foreign transaction fee: receipt 890 NOK, charged 1,002 NOK.
The bet principle
Every lifetime is a guess about the future. So never delete a scope — FILE it behind an address. A right guess costs nothing. A wrong guess costs a lookup. Only an unfiled scope turns a wrong guess into a loss.
Building roads you can reason about
One question remains, and it closes the loop back to everything we learned about tools. If the path is discovered as it's walked — if the graph is probabilistic — how can we draw bars in advance at all? Because the graph is not lawless: the agent can only walk roads the tool language builds. Compare:
Two tool sets, two kinds of graph
Look at what the structured language did: closure — each result
naming the next tool's input — didn't just help the agent chain
moves. It made the pathways enumerable, and enumerable pathways
have knowable lifetimes: receipts-id visibly dies when
match consumes it. The IDs are doing double duty, too — passing
a name across the wall instead of the thing it names, so the
bulky object never occupies the conversation at all.
The road-network principle
You cannot know the path the agent will take. You CAN build the road network it must take it on. Tool design (the verbs, closure, results-as-grammar) shapes the space of possible trajectories — and a well-shaped space is one whose lifetimes can be reasoned about in advance. An old thread, come full circle: the language was always the design surface.
- Draw the lifetime chart for Example 1a's venue disaster from the previous lesson. Which bars ended long before the booking decision — and what was the longest-dead item still on the wall when the wrong call was made?
- The forkability test has three conditions. Which failure mode does each one protect against? Find the condition that Example 2 shows can be relaxed — and say what makes relaxing it safe.
Take a real transcript — one of yours from the hands-on sessions, or one we provide. (1) List every piece of information that entered the conversation, and mark where each was born and last used: draw the chart. (2) Compute the waste: for the last five iterations, what fraction of the wall was past its bar? (3) Box the one segment the chart says to fork; write its brief and its return contract. (4) Name the bet most likely to fail — and the ask_history call that repairs it when it does.