Use AI Where Interpretation Helps

The hard rules run first now, and they dispose of most of the inbound without argument. What is left is the question none of them could answer.

Two submissions, identical on every structured field. Same company size, same industry, same country, same landing page, both with a matched account. One message reads: We are replacing our current search provider before renewal in March and need to understand how your relevance tuning works at our catalogue size. The other reads: Hi! I help enterprise SaaS companies like yours improve their search rankings. Do you have 15 minutes this week?

No rule distinguishes them, because everything a rule can see is the same. The difference is entirely in the meaning of a paragraph of English, and reading paragraphs of English is the one thing a model is unambiguously better at than a rule.

The line: can it be checked, or does it have to be read?

That is the whole test, and it holds up better than any list of use cases.

A rule can check it when the answer is determined by a value, a comparison, a lookup, a date calculation, or the presence or absence of a record. Revenue at or above a threshold. Domain on a known vendor list. Open opportunity exists. Meeting date in the future.

Something has to read it when the answer lives in unstructured language, or requires recognizing intent, tone, or a category nobody has enumerated. Is this a buying enquiry or a sales pitch? Does this message describe a use case GTM Lab serves? Is this description of a problem specific enough to be real?

Everything on the first list should be a rule, permanently. Not because models cannot do arithmetic, but because a rule doing arithmetic is free, instant, testable, and identical every time, and a model doing arithmetic is none of those.

The model gets one question, not the record

The mistake that survives all of this is handing the model the whole record and the whole decision, then telling it about the rules in the instructions. Do not do that. A rule described in a prompt is a suggestion. A rule evaluated in code is a rule.

GTM Lab's model is asked exactly one thing: given this message, is the sender attempting to buy from us, attempting to sell to us, or neither, and what in the message tells you that? It does not know the revenue threshold. It is not asked whether to route. It does not decide the outcome. It answers one interpretive question, and deterministic logic combines that answer with the hard rules to produce the outcome.

This has a benefit past correctness. When the decision is wrong, you can tell which part was wrong. The interpretive step produced a defensible reading and the threshold was set badly, or the threshold was right and the reading was wrong. A model that owns the whole decision gives you one wrong answer and no way to localize it.

Adjudication: the model as a filter, not a decider

There is a second shape worth knowing, because it is often better than putting the model in the main path. Let deterministic logic produce candidates, then use the model to filter false positives before anything acts.

GTM Lab's duplicate detection works this way, and Keep Your CRM Data Trustworthy built the policy behind it. Exact and fuzzy matching produce candidate pairs. The model evaluates the ambiguous ones and either clears them or holds them. Anything it is not confident about is held in an explicit uncertain state rather than merged, and account-level merges stay review-only no matter what it says, because the consequence of being wrong there is categorically larger.

The pattern generalizes: rules for recall, model for precision, an explicit uncertain state, and a hard review-only floor for consequences you cannot undo.

Carry this into your business

Take the last decision your team pointed a model at and split the question in two: what could a rule have checked, and what genuinely needed reading. If the second list is empty, you do not need the model. If it is one item, that is the only thing the model should be asked.