A mortgage application says a borrower earns $120,000. An employment letter says $105,000. A tax document records $132,000.
An agent can retrieve all three documents and still produce a misleading answer to a simple question: what is this person's income?
The missing information may be the relationship between the figures. One describes base salary. Another includes variable compensation. Another covers a previous year. Before choosing a number, the system needs to understand what each source actually supports and what remains unresolved.
At Clara, we build software for mortgage professionals. Files stay active while documents arrive, borrowers clarify their circumstances, and lender requirements change. That makes them a useful test of a harder question about AI agents: can a system keep its understanding grounded as the work evolves?
More context helps. Reliable behaviour also depends on how the system records facts, handles corrections, and controls actions.
Three figures do not have to mean three contradictory facts
Consider this fictional sequence:
Monday
New evidence
The application reports annual income of $120,000.
File state
A borrower-reported figure, with its source.
Tuesday
New evidence
An employment letter states a base salary of $105,000.
File state
Base salary is a separate claim; the application figure still needs explanation.
Wednesday
New evidence
A tax document shows $132,000 for the previous year.
File state
Historical total income, attached to the period it covers.
Friday
New evidence
The borrower explains that the application included expected variable compensation.
File state
The explanation connects two figures, while support for the variable component remains an open question.
Choosing the most recently uploaded document would lose useful information. Averaging the numbers would invent a fact. Repeating all three without explanation would leave the broker to reconstruct the file.
A useful representation keeps the amount, definition, period, source, and review status together. It also distinguishes a borrower's explanation from independent supporting evidence.
This changes the next step. The task becomes identifying what support is missing for the variable component, rather than treating the whole file as inconsistent or declaring the income question settled.
Remembering a statement is only the beginning
Agent memory can include structured state, so “memory versus state” is not a strict technical boundary. The distinction that matters is whether the system merely retains statements or manages their meaning over time.
For an important claim, it should be possible to answer:
- What does this claim describe, and for which period?
- Which source supports it?
- Has it been disputed, corrected, or superseded?
- Has a person reviewed it, and what did that review settle?
The history matters too. A corrected value should stop driving current work without erasing the record of the correction.
The same applies to documents. A later upload can contain an older agreement. A filename containing “revised” can help locate a document, but does not by itself establish which terms govern the file. Recency, document identity, and meaning have to be considered together.
Evidence needs to survive the answer
An important conclusion should remain connected to its supporting material:
- Conclusion
- supporting claim
- source document and version
- relevant passage
That connection gives a reviewer something concrete to inspect. It also gives the system a way to identify conclusions that may need review when a source changes.
Otherwise, a generated conclusion can become a summary, the summary can become stored context, and a later agent can treat it as independently established evidence. Repetition has increased its apparent authority without adding support.
Source links alone are not sufficient either. A citation can point to the correct document while the answer misinterprets it. The evidence needs to support the particular claim being made.
The aim is an inspectable record of evidence, decisions, and actions. A fluent explanation generated afterward cannot substitute for that record.
Uncertainty must carry into the next action
Finding a discrepancy is useful only if subsequent work respects it.
Suppose review notes identify an unsupported income component, but a later lender-facing draft presents the total as verified. The system retrieved the evidence and noticed the problem. It still failed to carry the unresolved status into its output.
This is why uncertainty belongs in the working state of the file. It should affect what the agent drafts, which questions it asks, and when it requests a decision.
The same principle applies to authority. Preparing a request for additional documents and sending it are different actions. Updating a working assumption and authorizing a submission are different decisions. Software needs explicit permission boundaries for those transitions; a model's confidence does not supply authorization.
Evaluate what happens after the correction
Single-turn accuracy remains useful. It does not establish that an agent can manage an evolving file.
A more revealing evaluation starts with a sequence: an initial application, supporting documents, a discrepancy, a human correction, and a request to prepare the next step.
Then ask:
- Did the correction change the current understanding without erasing its history?
- Did the later draft use the corrected information?
- Were unresolved questions still visible?
- Could a reviewer locate the evidence behind the important claims?
- Did the agent stay within the authority granted to it?
At Clara, we are exploring these questions through bounded replays of mortgage work. Such replays can expose specific failures across consecutive requests. Passing one does not demonstrate reliability over an entire month-long file; that requires broader coverage and evaluation at later stages of the workflow.
That limitation matters. A convincing demonstration and evidence of sustained reliability are different levels of proof.
What this means for Clara
A larger context window gives a model more material to work with. It does not, by itself, enforce source tracking, preserve review decisions, or prevent an unauthorized action. Those are responsibilities of the surrounding system.
These are the design requirements shaping our approach to Clara: keep evidence close to the claims it supports, make open questions visible, and let professional judgment determine consequential next steps. They are also requirements we need to keep testing as the product develops.
For a brokerage evaluating an agent, a useful demonstration is to introduce a conflicting document, correct the system, and ask it to continue the work. Inspect what changes, what remains uncertain, and what appears in the next draft.
The question is not just whether the agent can answer correctly now. It is whether its later work still respects what the file has taught it.
Explore Clara
See the file, evidence, and next step together