Most matching problems get solved the same way. You write a scoring function, weight a handful of fields, sort the results, and ship it. Then the requirements change, and you are back in the function adding another if. Six months later nobody can explain why a particular match scored the way it did.

On a fundraising platform we built, the job was to connect founders with the right investors. We tried the scoring-function path first. It worked, until the definition of "right" turned out to be a moving target that lived in conversations, not columns.

So we tried something different. We gave a language model the database and let it do the reasoning.

The setup

The agent runs on Claude through the Vercel AI SDK. It does not get a frozen list of candidates. It gets tools: one to run read-only SQL against a replica, one to describe a table, and the schema. Its instructions are a rubric, not an algorithm. Hard disqualifiers first, then primary signals like industry and stage and ticket size, then softer ones, and a preference for matches the user has not seen before.

It queries the database itself, shortlists twenty or so candidates, scores each one, and returns the best few through a structured tool call with a fixed schema. If nothing clears the bar, it is told to return nothing rather than pad the list with weak names.

That last instruction matters more than any other. A matching system that always produces matches trains users to ignore it.

What it bought us

The logic now lives in language, which means the people who understand the business can read it and argue with it. When the definition of a good match shifts, we edit the rubric instead of redeploying a scoring function. The agent also explains its reasoning, so a human reviewing a match sees why it was made, not just a number.

It handles the messy cases a fixed function never could. A founder whose stage says one thing but whose deck says another. An investor whose stated thesis and actual history disagree. The model weighs the conflict the way a person would.

When matching logic lives in a prompt, the people who know the business can finally read it.

What we had to cage

Handing an LLM a database is exactly as dangerous as it sounds, so the freedom is fenced on every side.

It only ever touches a read replica, through a connection that physically cannot write. No amount of creative SQL can change data. We cap how much it can pull, so a bad query degrades gracefully instead of hammering the database. The final output goes through a strict schema, so downstream code never has to parse prose. And the whole run is a durable workflow that tracks cost, refunds the user's credit if it fails or returns nothing, and leaves a trail we can audit.

We do not let it act on its own conclusions either. The matches it produces are surfaced through a human review step before anyone is introduced. The model proposes. People still dispose.

When this is the right call, and when it is not

This approach earns its keep when the rule is genuinely fuzzy and keeps changing, when the inputs are unstructured, and when a wrong answer is recoverable. Matching, triage, and ranking fit that shape.

It is the wrong call when the rule is crisp and stable. If you can write the logic as a clear function, write the function. It will be faster, cheaper, and easier to trust. Do not reach for a model to do arithmetic.

The interesting shift is not that an LLM can write SQL. It is that, fenced correctly, you can move a whole class of judgment calls out of code and into language, where they are easier to change and easier to explain. The engineering is no longer in the algorithm. It is in the cage you build around it.