How the Deal Screener Works: Code Where You Can, LLM Where You Can't

In my broker dataset, Transworld shows up twice. Once from a direct scrape of their site (4,048 listings), once from the aggregators that resurface their franchise listings (another 781). Same firm, two records, and whether a machine decides those rows are the same company changes Transworld's footprint by roughly 16%.

We Sell Restaurants does it too. 1,204 listings under the direct source, another 297 surfaced through aggregators. One firm, split across two identities, because that's how the plumbing of the broker world works.

Multiply that across 2,473 active US broker firms and you get the unglamorous problem sitting underneath deal screening. Before you can tell a searcher "here's what's new today," you have to know which listings are the same listing wearing a different hat. (At roughly 769 new listings a day, getting this wrong compounds fast.)

I spent weeks trying to teach plain code to settle it. Different spellings, abbreviations, a DBA on one record and a legal name on the other, a stray "LLC" floating around. I threw every trick I had at it. Fuzzy matching, string normalization, all of it.

I could never get past about 80%.

That last 20% was a judgment problem, not a code problem. "Bob's HVAC" and "Robert Smith Heating & Air" might be the same shop, or they might be two competitors on the same street. No amount of normalization tells you which. Somebody has to actually reason about it.

So I left the code in place and bolted an LLM on top for the cases the code couldn't settle. In plain language: "are these the same thing?" Solved. And cheap, because the model only ever looks at the hard 20%. The other 80% never touches it.

The rule that came out of that

Write code where you can, spend the model where you can't.

That split became how I build everything in Searcher OS. Anything that has to be exact lives in deterministic code. Math, dates, price thresholds, buy box filters, days-in-stage detection, the SBA debt-service numbers. Code runs the same way every time, costs nothing per run, and never hallucinates a result it then forgets it invented.

The model gets the genuinely ambiguous work, the stuff with no clean rule:

• Reading a poorly written broker email and pulling out what they actually mean
• Pulling real numbers out of a CIM that wasn't written to be parsed
• Judging whether two messy records describe the same business
• Summarizing what a customer is really asking for under the noise

Here's the part a skeptical searcher should care about. If your screening agent is doing arithmetic, you've already got a bug waiting to happen. The model will hand you a number. It just won't always hand you the same number, and it has no idea when it's wrong. That's a fine trait for writing a summary and a disqualifying one for telling you whether a deal clears DSCR.

Watch one listing go through

Take a single listing off a broker site and walk it through the screener field by field. You can see the line move under your feet.

Asking price is $1.2M, your buy box caps at $1.5M. That's code. There's a right answer, it's the same every run, and I'd be a fool to pay a frontier model to compare two numbers. Same for "how long has this deal been parked in NDA Signed": days in a stage is a date subtraction, deterministic, done. (Searcher OS runs that one for you and flags the deals that have gone stale.)

Then the CIM lands and the screener hits something messier. Picture a financial statement where a line that looks like an owner's salary is buried in operating expenses. Is that a real cost the next owner inherits, or the kind of add-back a buyer would reasonably question? Code has nothing useful to say there. That's a judgment about what the document means, and it's exactly the kind of call I'd want the model making, because nothing cheaper can make it.

One listing, and the line shows up twice. Below it, mechanical. Above it, the model earns its keep. I suspect a lot of "AI is unreliable" frustration is really a placement problem: the model got handed the wrong job.

How Marcus got better and cheaper at once

Marcus is the agent that handles broker follow-up and the first pass of screening. Earlier this year he choked. Sloppy, expensive, and I couldn't trust his output without re-checking it, which defeats the entire point of having him.

The fix was exactly this surgery. I pulled the parts that needed to be exact out of the model's hands and into code, and left Marcus only the judgment calls. He went from a poor performer to something closer to a trusted employee. The bill dropped too, because I stopped paying a frontier model to do long division.

I had the opposite instinct at first, same as everyone. You get excited about the latest model and pipe everything through it, arithmetic included. Then the invoice gets creative, and the model that did its job fine turns out to have been handed work it was never the right tool for.

Boring is the point

I think the mistake most people make is treating the LLM as the product instead of one component inside it. The model is the part that costs the most and surprises you the most. You want it doing as little as possible, and only the part nothing else can do.

Everything around it should be predictable plumbing you can read, test, and trust. When a searcher opens Searcher OS in the morning and asks the three questions that matter (what's new, what's stuck, what do I do next), most of what they're staring at is the output of boring deterministic code. The model only stepped in where a human would've had to squint anyway.

A good screening agent is mostly boring code wrapped around a well-supervised brain. That's the reason the output is worth trusting, and it's the reason I sleep fine letting it run.

If you want to see where that line falls on your own deal flow, the free plan of Searcher OS runs your buy box against listings from hundreds of broker sites and lets Marcus take the first pass. Watch where the boring code does the work and where the judgment kicks in. That line is the whole product.