Part 1 made the case that every working session - human or agent - produces
knowledge with a real replacement cost, and that almost all of it is written
off at session end. The obvious response is: fine, let's document better.

This part is about why that response fails, and what actually works instead.

![Two cubes far apart on a ground line; the left one glows amber and gives off particles that thin and fade as they drift toward the right one, which arrives cold and empty.](/assets/blog/p2-deferred-capture.webp)

## "Write it up later" is not a process. It's a hope.

Every organization has tried some version of documentation discipline. Write
the decision record after the meeting. Update the wiki after the incident. Add
the gotcha to the runbook when you get a minute.

It fails, and not because people are lazy. Three reasons:

**Capture-after competes with the next task, and loses.** Once the work is
done, it's done - the pressure that made the knowledge valuable is
gone, and the next piece of work is already applying its own pressure.
Deferred capture asks you to spend time now for value later, every time,
forever. That trade loses to the inbox.

**Memory decays fastest for exactly the most valuable material.** A week
later, you remember the conclusion. You do not remember the three alternatives
you rejected, the specific error message that revealed the constraint, or the
order in which you tried things. The conclusion was going to survive anyway -
it's in the deliverable. Deferred capture preserves the cheap part and drops
the expensive part.

**The author can't tell what's worth writing.** In the moment, a discovered
quirk feels too small to document - "surely everyone knows the API wants
DD/MM/YYYY." Six months later, it's a two-hour debugging session for someone
else. The value of a captured fact is mostly determined by future situations
the author can't see. Asking humans to filter at write time means the filter
runs on the wrong information.

The conclusion isn't "try harder." It's that capture as a separate, later,
human-initiated step is the wrong architecture.

## The design rule: capture where the knowledge is born

Knowledge is created at a specific moment: the instant a fetch fails, a
constraint surfaces, an option gets ruled out, a decision gets made. That
moment has everything - full context, exact details, zero recall loss. Every
second between that moment and capture is decay.

So the rule is simple: **capture must happen at the point of creation, by the
same tooling that's doing the work, at near-zero marginal cost.**

Three properties fall out of that:

**Ambient, not initiated.** Nobody should have to decide to capture. The
default is that working produces a record as a side effect, the way version
control made "having history" a side effect of committing code. Git didn't win
because developers became more disciplined about archiving; it won because
history became free.

**Cheap enough to over-capture.** Since value is unknowable at write time, the
filter has to move from write time to read time. Capture liberally, curate
later. Storage is cheap; re-derivation is not. (Yes, this creates a noise
problem. That's real, and it's exactly why this series has a Part 4 - raw
capture without distillation rots. But the fix for noise is downstream
processing, not upstream abstinence.)

**Structured enough to find again.** A transcript is technically a record and
operationally a landfill. Capture needs just enough shape - what kind of
learning is this, what does it apply to, when was it true - that a future
session can pull it back out. Timestamp and provenance matter more than prose
quality: *when* something was learned and *from what* determines whether it
can be trusted later.

![A row of cubes representing steps of work; one has opened and dropped a single amber shard into a tray beneath the row, which already holds a few, while the sequence continues uninterrupted.](/assets/blog/p2-capture-at-source.webp)

## What this looks like for agents

With agents, point-of-creation capture stops being a philosophy and turns
concrete, because the knowledge is born inside tool calls that a machine can
already see.

Some examples of session-generated knowledge that tooling can catch
automatically:

**Failure modes as first-class learnings.** An agent fetches a URL and gets a
429. Today, in most stacks, that's an error string that scrolls past and dies
with the context window. The next session - maybe an hour later - pays for the
same discovery. But "this endpoint rate-limits aggressively" is a durable fact
about the world. Caught at the moment of failure, with the URL, the status,
and the timestamp, it converts a wasted request into an asset.

**Escalation paths as a self-writing registry.** Some sites need heavier
machinery - a real browser, stealth measures - and finding out *which* sites is
trial and error. The move is to make the infrastructure remember its own
escalations: the first time a domain forces the expensive path, and that path
works, the fact gets recorded. Every later request to that domain routes
correctly on the first attempt.

The qualifier matters. Registration waits for the expensive path to succeed,
because a domain that defeats both routes has taught you nothing worth
routing on - you'd be pinning traffic to a path that also fails. So the
registry fills with domains you know how to reach, not domains you've merely
struggled with. No human involvement either way: the system learns as a side
effect of operating.

**Environmental quirks.** The API that wants dates in DD/MM/YYYY. The endpoint
that silently truncates at 1,000 rows. The service that returns 200 with an
error in the body. Each of these is discovered inside a failing tool call,
which means each is capturable at the exact moment of discovery, with the
evidence attached.

**Working state at session end.** What was in flight, what was ruled out, what
the next step was. An agent can write its own handover note far more cheaply
than a human can - it's a summarization task over context it still holds. The
"exit interview for a chat tab" from Part 1 doesn't require a new ritual; for
agents, it's one more step in the loop.

## What this looks like for humans

Humans can't be instrumented like tool calls, but the same principle applies:
move capture into the flow, shrink it until it's frictionless.

**Decisions get recorded when made, not after.** The moment a discussion lands
on "we're doing B," the capture is three lines: chose B, over A and C, because
X. Thirty seconds while the reasoning is still loaded in everyone's head. The
formal write-up can come later or never - those three lines are the part with
the replacement cost.

**Rejected alternatives are the payload, not a footnote.** "We considered A"
is the sentence future-you needs most and current-you values least. In-flow
capture is the only time it gets written honestly, because it's the only time
anyone remembers why A actually lost.

**The assistant in the loop is the scribe.** If the work is already happening
in conversation with an AI - and increasingly it is - then the tooling is
present at the moment of creation by definition. Asking it to log the
decision, the constraint, the dead end is a one-line instruction, not a
context switch. The marginal cost of capture approaches zero precisely because
the knowledge is being born inside an instrumentable medium.

## The test, applied at write time

Part 1 offered the asset test: would you pay to acquire it again? At capture
time, it becomes a routing rule. A learning passes if re-deriving it would
cost real time or money - a debugging session, a re-litigated decision, a
repeated dead end. Transient trivia doesn't pass; the shape of an error that
took an hour to understand does.

Apply the test generously. You moved the filter downstream because write-time
judgment is poor. When in doubt, capture - the cost
of a false positive is a few bytes; the cost of a false negative is the full
replacement cost, paid by someone who doesn't know it was ever paid before.

## Full reservoirs you can't drink from

Suppose you do all of this. Failures logged, decisions recorded, quirks
registered, handover notes written - the leak is substantially plugged. You
now have a growing reservoir of session-generated knowledge.

And by default, it will help nobody. Captured knowledge that the next session
doesn't *consult* is a write-off with extra steps - you paid the storage cost
and kept the re-derivation cost.
![A tank filled to the brim with glowing amber shards, its outlet pipe dry and ending above a completely empty basin.](/assets/blog/p2-full-reservoir.webp)
 The difference between an archive and an
asset is whether it changes what happens next.

Making that consultation automatic - starting every session warm instead of
cold - is Part 3.

---

*Next in this series: **[Retrieval - starting
warm](/blog/retrieval-starting-warm).***