Capture: stopping the leak at the point of creation

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.

"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.

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