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.

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:

This gives extraneous load its exact definition — sharper than "too much stuff":

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 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 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:

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.

⟨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:

⟨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).

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:

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.

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.