Algorithm Tour

A proposal is born in three ways: the broker saves the client in iList (the agency’s CRM), the broker creates the proposal in Clave in five questions, or the buyer arrives on their own through the website. Each door speaks a different dialect — fields, formats and data quality.

First, we normalize. CPF with digits only and its check digits verified, mobile phone in international format, standardized address. What fails validation does not enter the process: it goes back with the reason.

Then, we resolve entities. The same buyer can arrive through two doors, and the same person can be both buyer and broker. We compare attribute by attribute, with weights, and decide: same person, different person or doubt for Ops.

Finally, confirmation. The mobile phone is confirmed with a six-digit code; the CPF data is checked against identity sources once per person. If they do not match, a person helps — the algorithm does not insist.

Avoids duplicate proposals for the same person and the same property.

The buyer talks to the assistant by text or audio: sends a photo of a document, asks “so?”, complains, asks to talk to someone. Each message is transcribed, if it is audio, and becomes text with the context of the proposal.

A classifier estimates the intent: document, status, question, request for a person, out of scope. The output is not an answer, it is a probability distribution — and that is what makes it possible to know when to doubt.

Routing uses confidence. If the highest probability passes the threshold and the margin over the second is large, the assistant answers. If not, the conversation goes to Ops, with its context. Asking for a person always leads to Ops, by rule.

What the assistant sends is also classified. Messages A and B go out on their own; C — bad news, third collection notice, any sentence outside the templates — only goes out with approval from an Ops person; D never goes out. The class comes from a deterministic rule, not from the model.

The buyer photographs a document and sends it through the web area or WhatsApp. It is the moment they decide whether to trust Clave: seeing the first document checked in minutes, without chasing anyone.

First, a vision model recognizes the document type: payslip, bank statement, proof of address. “Other document” is a legitimate answer — better than forcing a fit.

Then, reading: OCR and vision-language models extract the fields — name, CPF, amounts, dates, issuer. Each field comes with its own confidence, because an unreadable value should not contaminate a clear name.

Cross-validation compares what was read with what the proposal says: does the name match? is the document within its validity? is the amount compatible? This is where a perfectly legible document can still be rejected.

Finally, a combined confidence and one of five outcomes: looks right, unreadable, expired, data does not match or other document. Above the threshold the model checks it on its own; below, the case goes to the Ops desk.

The model is probabilistic; the policy is deterministic. The decision engine confronts the evidence with a threshold: above it the model checks on its own, below it the document goes to the Ops desk. That is why the desk only sees what stayed uncertain — and why it may, one day, be empty.

For the threshold to hold, the probability has to be calibrated: when the model says 90%, it should be right about 90% of the time. We measure this by comparing confidence and accuracy per band.

And where to put the threshold? Reviewing costs c_r; accepting an error costs c_f. Accepting is worthwhile as long as the expected cost of the error is lower than that of the review. The minimum of the total cost curve comes straight from this calculation.

The threshold is not an eternal number. It changes by document type, by bank and by model version — and sampling audit, in chapter 8, verifies whether it still holds.

Use the controls at the end of this chapter and watch the optimal threshold shift.

With the buyer’s consent, Clave sends the proposal to the three chosen banks at the same time. Each submission is an independent task, with its own state: created, under review, document requested, answered, late.

Integrations fail: the bank’s portal goes down, the response is slow. The policy is to try again with growing waits and a little randomness, so thousands of proposals do not knock on the bank’s door in the same second.

Resending must not duplicate. Each submission carries an idempotency key derived from the proposal and the bank: if the same request arrives twice, the bank sees only one.

When a bank asks for a document, only that submission stops; the others continue. Each bank has a typical response time: past the deadline, the submission becomes “late” and Clave chases the bank, visibly to whoever is waiting.

Banks answer by PDF, email, portal or phone. Clave turns each answer into comparable fields — amount financed, term, rate, installment, CET, total paid — always as the bank sent it. It does not invent conditions and does not choose the bank for the buyer.

Before showing any offer, an arithmetic validation: does the stated installment match the rate and the term? If it diverges beyond the tolerance, the answer goes to Ops to be classified instead of reaching the buyer.

Under the Price system, the installment is constant, but its composition changes: at the beginning, almost all of it is interest; over time, amortization grows. The total paid and the CET — the total effective cost, the rate that equates the net amount received to the stream of installments — come from this calculation and are solved numerically.

The buyer compares the offers side by side and chooses. Clave shows what each bank sent, withdraws the submissions that were not chosen and, if the property appraisal comes in lower, offers to go back to another bank.

The values shown are fictional, as in the rest of the example.

Once the bank is chosen, the Contract stage begins: inspection, signing through the bank’s link, ITBI (the property transfer tax), registry office requirements, registration and handing over the keys. Almost none of this happens inside Clave — the bank decides in its own portal, the registry office has its own pace.

Each step is a state in a state machine, with dependencies: signing only comes after the inspection, and registration only after the ITBI and the requirements. Every state change emits an event, and the event is what notifies each actor.

The stage’s deadline is the critical path: the longest path in the graph. Knowing which branch is on the critical path says where to spend attention — delaying the ITBI within its slack does not change the keys date; delaying the registry office does.

What Clave does off screen is turn each registry office requirement into a task with an owner and a deadline, chase the bank visibly and leave the right message ready, in each place, for whoever needs to act.

Ops is a small team of analysts, each with up to 200 proposals. The desk shows only what the model and the assistant did not decide on their own. The analyst sees what the model read, picks one of five labels and confirms. No free text.

Each label does two things: it triggers the consequence — a request to the buyer, a stalled proposal — and becomes a training example, once validated. When there are more cases than people, the most uncertain come first.

Above the threshold the model decides on its own — so how do we know it is still right? By sampling: Ops reviews a daily sample of the automatic decisions. Disagreement becomes a label, and the disagreement rate is the metric that has to fall.

Sample size to see, with confidence C, at least one error of rate p.

In the end, what matters is the economics of the operation: how many interventions per 100 proposals, how many false accepts, how much each completed contract costs. We measure by bank, by document type, by model version and by confidence band.

Design references, not measured results: the productivity gain still needs to be demonstrated.

Every state change of a proposal emits an event: document.sent, document.checked, proposal.documents_checked, consent.recorded, submission.created, submission.answered, key.delivered. No screen synchronizes another — it is the event that notifies broker, buyer, Ops and the real estate agency.

The heart of the system is a durable workflow engine, not the language model. It stores the proposal’s state, controls what can happen and resumes from where it stopped when an external service fails. Agents are specialized workers, with their own tools and limits.

Around it, layers: experience, agents, workflow, intelligence, integration, trust and data. The rule of who sees what — the broker and the agency never see the content of documents, the full CPF or the offers — lives in code, not on a screen.

A proposal’s state is a function of its events: replaying the history rebuilds any moment. That is what gives end-to-end traceability — and allows auditing and learning later.