Keep facts and assumptions separate in an agent handoff
Label what a primary source states, what the agent observed, and what remains a hypothesis.
Guide · Updated 2026-10-20 · 3 min read
Label what a primary source states, what the agent observed, and what remains a hypothesis. Give each material claim an evidence reference and scope. Tinovio can keep those distinctions attached to the next task and shared decision.
A researcher may read that a payment provider returns a particular error code. That does not prove the checkout displays the message correctly. The source fact and project behavior need different checks.
Name the evidence type
Use clear categories such as documented, observed, proposed, and unverified. A documented statement links the source and its version. An observed result identifies the run, artifact, and conditions.
A proposed method explains what the agent intends to do. An unverified statement identifies a question that still needs evidence. Do not turn a proposal into an observation through confident wording.
Keep the claim within its scope
If a focused test passed on one commit, say that. Do not expand it into a claim that every environment works. If a keyword tool returned an estimate, keep it distinct from visits or buyers.
The same rule applies to model answers. A sampled API response is not a count of private user prompts or proof of future citations. Preserve the method and date with the result.
Put evidence near the action
In the handoff, state the conclusion and link the supporting artifact. Explain what the next owner should do with it. A long source list without a task relationship leaves the receiver to reconstruct the reasoning.
For a checkout investigation, identify the relevant provider fact, code path, and unresolved behavior. The builder can then verify the missing part rather than repeating the entire search.
Use Tinovio to preserve the distinctions
Place detailed evidence in a shared file and summarize it in the task thread. Record durable decisions with their reasons as shared context. Link the evidence that supports the chosen requirement.
Assign the next action to a particular session with an explicit completion condition. The receiver should know whether it must investigate a hypothesis, implement a confirmed requirement, or review a changed version.
Correct the record when evidence changes
If the original claim was wrong, record the correction and identify affected work. Do not silently overwrite the only explanation behind an active task. Ask the relevant owners to use the corrected requirement or evidence.
When a decision changes, preserve the relationship to the earlier record. Later sessions should distinguish historical findings from current guidance. Tinovio provides the shared record, while the agents remain responsible for reading it accurately.
Test the handoff with the receiver
Ask which claims it treats as confirmed and which still need checks. Compare that answer with the evidence record. Any mistaken certainty is a reason to revise the brief before implementation.
Use the research-to-implementation workflow to apply the method to one bounded task.