An applicant uploads an invoice, but the supplier's name doesn't match the company on the application. The agent asks about it. The applicant sends another document.

Someone has to read that response, work out whether it answers the question, and update the file. In Klarefi, that's one persistent case agent that handles both the investigation and the conversation with the applicant. As the case develops, it can go back to the source documents and reconsider an earlier answer.

The unit of work is the case

Our earlier pipeline processed documents, extracted facts, ran checks, and turned gaps into questions. Those stages had separate code paths for updating the case when an answer arrived.

That split works when the job is “read these fields from this file.” Intake is different: a question only makes sense in relation to the evidence that prompted it. The reply may settle the question, introduce a contradiction, or reveal that we asked for the wrong thing.

The current agent retains the case conversation and works from the institution's published requirements. It can search and read sources, run configured connector checks, ask the applicant for information, and publish facts and findings. When new information arrives, the case resumes with that context. It may delegate a task, but one case agent owns the resulting file.

Document parsing, storage, and validation still use ordinary code. What changed is who decides what the intake needs next: the case agent.

A reply can change the question

Consider this fictional factoring application:

Suppose this workflow requires evidence identifying the invoice issuer and its relationship to the applicant. Before the reply, the open question was whether the trading name belonged to the applicant. After it, asking for the same trading-name document again may be pointless. The file now needs to establish which sister company issued the invoice and explain the relationship.

The extraction can be accurate and the file can still need a different question. The reply changed what the evidence means when read together.

A citation must support the answer it sits beside

Linking a PDF next to a company name is easy. Making sure the link actually supports the value takes more work.

In the example above, the invoice supports one statement: its supplier is North Quay Trading. Whether North Quay Holdings BV issued it is a separate question. The applicant's reply is a separate source, and it counts as proof only for what it actually says.

Klarefi retains the passage and source version behind a document-derived fact. It distinguishes evidence supporting a value from material that corroborates or conflicts with it. Our validation checks prevent an attached support reference from being detached from the answer it is meant to support.

That check is structural. It keeps the evidence attached; it cannot prove the agent read the passage correctly. So reviewers can always open the source and challenge the interpretation. Klarefi preserves the evidence, and a person checks what it says.

Corrections need to reach earlier findings

A revised value can make an earlier finding obsolete. Updating the value alone leaves the reviewer with a file that contradicts itself.

We test this explicitly. In one deterministic test, a fact changes from 1,200 to 1,300. The finding tied to it is marked for reassessment; a finding about an unrelated fact is left alone. A second test prevents an old contradiction from being presented as freshly assessed before the agent revisits it.

The old finding stays traceable when new evidence arrives. A reviewer can see the current assessment and the path that produced it.

The same problem shows up in different files

For an MGA, a proposal might request €750,000 of contents cover while the attached schedule totals €900,000. A broker's explanation that the schedule covers two premises changes what needs checking: whether the requested cover concerns one premises or both. Comparing the two numbers again cannot answer that.

For a mortgage team, a self-employed applicant might supply one year's accounts and a forecast where the workflow asks for two completed years. Extracting both income figures gives two numbers, and only one of them is a completed year. The document periods and the kind of evidence matter.

For the factoring case, the missing relationship between issuer and applicant is the issue. Each institution defines the evidence its workflow requires. Klarefi prepares that material for review; underwriting, affordability, and financing decisions remain with authorized people.

What we would test before a pilot

Take one file your team knows how to review. Run it complete, remove a required source, introduce a contradiction, then answer the resulting question with new evidence. Finally, make a required test check unavailable. Our reusable test sheet lays out those versions for factoring, insurance, and mortgages.

Look at the file after each change. Did the agent ask a useful question? Did the reply change the right finding? Can the reviewer trace the conclusion to its source? Did an unavailable check stay visibly unresolved?

These constructed cases expose failure modes. Production accuracy needs real files: for a pilot, compare reviewer preparation time and missing items found after handoff on similar cases, using the same definition of a complete file in both the baseline and the pilot.

If you want to see how the requirements are authored, start with Form, Fact, and Verify. To work through a file from your own process, bring it to an intake review.