Answer
How should an agent use previous work without blindly trusting it?
Treat earlier output as a claim to be checked against the artefact, not as an established fact to build on.
Use it as a claim rather than a fact. Earlier output tells you where to look and what was concluded; the artefact tells you whether the conclusion holds. Checking costs seconds and inheriting an error costs the run.
The problem is compounding. An early conclusion that is slightly wrong becomes a premise, work is built on it, and by the time anything surfaces the error is not a line but a structure. This is more dangerous in multi-session work than in a single run, because the receiving session has no memory of how confident the conclusion was, and a written statement carries the same weight whether it was carefully established or guessed.
The discipline is to keep the pointer and re-check the claim. A prior finding that a record contains a particular value is useful because it tells you which record to look at; opening it takes a moment and converts testimony into observation. A prior conclusion that an approach will not work is useful because it names the approach; whether it holds depends on why it failed, which is why the reason has to be recorded alongside.
How much checking is proportionate follows from dependency. Anything the current step builds on directly should be verified. Anything providing background can be taken as read, because being wrong about it produces an obviously odd result rather than a quietly wrong one. This is the same principle as elsewhere: verification effort goes where an error would propagate rather than being spread evenly.
There is a specific version of this failure worth naming. A summary of earlier work presented at the start of a session is treated as established context rather than as a report, and everything after it inherits its errors with no visible seam. The countermeasure is to mark inherited claims as inherited — this is what the previous session concluded — which is one phrase and changes how the material is weighted.
The opposite failure is real and should be stated so this does not read as an argument for redoing everything. A session that re-verifies every prior conclusion is not continuing the work, it is repeating it, and multi-session work then costs more than doing it in one pass. The judgement is dependency: check what the next step rests on, inherit the rest, and note that you inherited it.
Yesterday's output is testimony, not evidence, and a system that treats one as the other will compound a small error into a confident structure.
Siddharth Sharma, Context Theory
Related questions
Should an agent be told which earlier findings are reliable?
Where you know, yes, and marking the difference is more useful than a general instruction to be careful. A handover distinguishing verified from believed gives the next session a basis for allocating its checking, and without that distinction it will either check everything or nothing, both of which are wrong.
Does this apply to work done by a person?
The same logic applies and the base rates differ. A colleague's note carries a track record, an implicit context and someone you can ask, none of which a prior session provides. The practical consequence is that inherited machine output deserves a slightly higher checking rate for the same level of dependency, not that human output should be taken on faith.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | A written prior conclusion carries the same apparent weight whether it was carefully established or guessed, because the receiving session has no record of the confidence behind it, which is why compounding is worse across sessions than within one. | Checking whether a handover distinguishes verified findings from provisional ones. |
| Response | Retaining the pointer while rechecking the claim converts inherited testimony into observation at low cost, because the prior output's durable value is identifying where to look rather than what is true. | Timing the re-verification of a prior finding against the cost of an error propagated from it. |
| Software | Checking effort should follow dependency rather than being spread evenly, because an error in background material produces an obviously odd result while an error in a direct premise produces a quietly wrong structure. | Classifying each inherited claim by whether the next action rests on it directly. |
| Constraint | A prior-work summary presented at session start is treated as established context rather than as a report, so marking inherited claims explicitly as inherited changes how subsequent reasoning weights them. | Comparing how a session treats the same claim presented as context and presented as a previous session's conclusion. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one