Our founder recently spent a week in San Francisco attending CoLM, the Frontier Data Summit, and other technology events, visiting frontier labs, and talking with researchers and builders. He came back optimistic about what AI could make possible, and thinking about a question familiar from his earlier work on mission-critical systems: how do we check the work as systems take on more responsibility?
That question matters to us at Clara. A mortgage workflow can involve reading documents, reconciling figures, preparing a package, and taking an action on someone’s behalf. Each step creates something the next step may trust. A mistake can travel through that chain even when every individual output looks reasonable.
We want more capable AI. We also want specific answers when someone asks what was checked, what passed, and what still needs a person’s judgment.
Make the question specific enough to check
“Is this package correct?” contains several different questions. Does the calculation follow from its inputs? Do those inputs match the source documents? Are those documents current and relevant? Is the attachment the version that was reviewed? Is this an appropriate submission for this recipient?
Those questions need different methods. Code can recalculate a ratio. A comparison can detect that a file changed. A reviewer may need to resolve an ambiguous statement or decide whether the evidence is sufficient for a particular purpose.
The lesson we take from reliability engineering is to define the property we need to establish and the failure the check should catch. A broad instruction to “double-check everything” gives us much less to test.
A small check with a clear job
Consider an illustrative handoff. A broker reviews a lender package. Before it becomes an email attachment, the system downloads the file. The downloaded file has the same familiar name, but its contents have changed.
Clara’s Admin Portal package-delivery implementation has a check for this situation. The delivery request identifies a particular package and version, with a recorded file size and SHA-256 hash. A hash is a fingerprint calculated from the file’s contents.
The delivery code checks that the authorization returned by the server matches the requested package and recipient. It then downloads the attachment, calculates its hash, and compares both the hash and size against the reviewed reference. A mismatch causes an error before that function returns the attachment for sending.
Review
What is recorded
A specific package version and its content fingerprint.
Question still requiring judgment
Does this package support the intended submission?
Prepare
What is checked
The authorization and downloaded file match the reviewed reference.
If the contents differ
The attachment check fails.
Resolve
What the workflow needs next
Investigate the mismatch and review a changed package before using it.
What a passing check establishes
The file matches the reference. Its factual accuracy still needs evidence.
This is a deliberately narrow control. A perfectly preserved file can still contain an incorrect income figure or an unsupported statement. The hash check helps preserve the connection between review and delivery; assessing the content requires other checks.
Our package review guide covers the broker’s side of that assessment. Here, the engineering point is that a useful control has an explicit job and an explicit limit.
Another agent needs evidence too
An agent reviewing another agent’s work can be useful, especially when it can inspect the underlying documents, reproduce a calculation, or challenge a missing assumption. But agreement between two agents is not enough to establish that the result is correct.
If both reviewers receive the same incomplete extract, they may both miss the missing page. If the second agent sees only a polished summary, it cannot independently establish what the source actually says. Giving the reviewer a different role or prompt does not supply the absent evidence.
For the attachment example, the decisive check is a direct comparison of file contents against the recorded reference. Asking another model whether the filename looks right would answer a much weaker question.
Test what happens when checks fail
A check also needs a defined consequence. Does the workflow stop, request a new review, or continue with a warning? Those outcomes carry different meanings.
Clara’s package-delivery tests include synthetic cases where the downloaded bytes match the reviewed package and where they have changed. The changed-content case expects the delivery function to reject the attachment. This tests a concrete failure without sending a real borrower’s documents.
Earlier in package preparation, Clara’s implementation also treats an incomplete document scan as a blocking issue. That is another specific boundary: a partial evidence set should not quietly be treated as complete. We explored the related problem in When a Failed Read Looks Like an Empty File.
These are controls in particular Clara code paths. They do not establish that every interface or installed version has identical coverage, or that a successful unit test proves a complete live workflow is reliable. The broader system still needs testing at the points where its parts connect.
Make human review more useful
Human review becomes more useful when a system gives the reviewer something concrete: the source behind a claim, the exact version being considered, the checks that passed, and the unresolved questions.
The broker can then assess the evidence and proposed action with that context. An approval button alone cannot provide it, and an automated check should not quietly turn into a broader claim that the whole file is verified.
The optimism from San Francisco fits with this approach. As AI takes on more work, we can use that capability to make the work easier to inspect and challenge. Our aim for Clara is to pair useful automation with checks whose meaning is clear, so people can exercise judgment with better evidence.
Explore Clara
Book a walkthrough of Clara