Boolean answers who you think qualifies. AI answers who might fit. One is a literal count of what’s actually in your data. The other is an informed opinion. You need both, and you need to know which one you just asked for.
A year ago I wrote Search is Dead: The Rise of Discovery. I stand by every word. Search as the front door to your database is finished. Asking a high-billing recruiter to become a database archaeologist was always backwards, and AI fixed it.
So why did I just publish a three thousand word guide to Boolean operators? Because those two positions don’t conflict at all.
Killing the search box was right. Killing the logic underneath it would be a mistake, and I think a lot of this industry is about to make it. Boolean was never really a search technology. It’s a language for stating requirements literally. We just made the mistake of bolting it onto a text box and asking recruiters to type it.
The box is going away. The language is moving somewhere more interesting: underneath the agent, where the agent calls it.
Boolean is literal matching, and literal has value
Let me ask a simple question. How many software developers do I know in Maryland?
That’s not a fuzzy question, and it has a real answer. There’s a specific number of records in my database where the location says Maryland and the person does development work. I either know that number or I don’t. A Boolean query hands it to me. Every record is in or out, and I can count them, list them, export them, and call them.
Now ask an AI the same thing. What you get back is an informed opinion: a ranked list of people it thinks are probably developers, probably in Maryland, sorted by confidence and cut off wherever somebody set the threshold. That’s useful for plenty of things. It just isn’t an answer to the question I asked.
That’s the property worth protecting. Boolean matches characters, not meaning. It has no idea that “owned the P&L” and “ran the business unit’s finances” are the same claim, and no idea that “no healthcare experience” is the opposite of what you wanted. It only knows whether the string you typed is sitting there or not.
Both halves of that are true at the same time. The literalness is the weakness, and it’s also the entire point.
One correction to how I’ve framed this in the past. Boolean doesn’t tell you who qualifies. It tells you who matches the criteria you wrote down, which is really just your belief about what qualifying means. Get that definition wrong and Boolean will execute it perfectly and hand you the wrong people with total confidence. It’s precise about your specification, not about reality. Keep that straight and most of the arguments about Boolean get a lot simpler.
Three reasons Boolean still matters
Total control. You decide what’s required and nothing gets inferred on your behalf. No model decides that your request for a controller probably also means accounting managers. No ranking function sits between you and the result, quietly reordering it. When you write a clause, that clause is the rule. Value precision over convenience when the answer has to be right.
Counting. Literal matching gives you a set, and a set has a size. How many contractors roll off in Q3. How many candidates in this market have the certification. How many records are missing a phone number. These are questions about your business, and a ranked list of maybes doesn’t answer any of them.
A durable artifact. A string is readable, storable, shareable, and re-runnable. You can hand it to a colleague, paste it into a ticket, or pull it up in nine months and see exactly what you asked for, which isn’t the same as remembering what you meant. A similarity score is none of those things.
Three flaws of Boolean
The limitations are real and structural.
1. You only find what you thought to ask for, and only what’s literally written down. If you didn’t list “SRE” next to “DevOps engineer,” those people don’t exist as far as your search is concerned. And you’ll never know, because Boolean has no mechanism for reporting what it missed. It also can’t infer that running a $40M region implies P&L ownership, and it can’t look outside your database at all.
2. Titles lie. Title inflation, title deflation, internal taxonomies, translation drift. “Member of Technical Staff” is a senior engineer. “Analyst” at a bank isn’t an analyst anywhere else. Candidates describe their work in the language of their last employer, not the language of your req, and there’s no incentive for them to do otherwise. You can’t OR your way to completeness.
3. It puts the work on the wrong person. Nesting, precedence, per-platform quirks, curly quotes, stop words. To be frank, it’s just hard, it’s easy to get subtly wrong, and the failure is silent. A string that returns plausible results while quietly dropping your best candidate looks exactly like a string that worked. It’s unfortunate, but we spent three decades asking recruiters to think like databases instead of building databases that think like recruiters. That’s not a training gap. That’s a bad interface.
One thing worth saying before we move on. The cleanest fix for that first flaw usually isn’t AI at all. If the fact you need isn’t on the resume, capture it as structured data the moment you learn it. Relocation, notice period, contract end date, how far they got in a previous process. Ask once in a screening form, store it in a field, and it’s searchable with total precision forever.
A large share of what people want AI to infer is just data nobody bothered to write down.
How AI search works, without the hand-waving
A model converts text into a long list of numbers called a vector, positioned in a space where things with similar meaning land near each other. “Registered nurse” and “RN” end up close together. So do “P&L responsibility” and “owned the business unit’s financials.” Your query becomes a vector too, and the system returns the nearest records, ranked by distance.
What that buys you is recall without enumeration. You didn’t have to think of “SRE.” The model knows it lives near “DevOps engineer.” For “who might be right for this?”, it’s straightforwardly better, and anyone telling you otherwise is selling something.
But notice what changed. There’s no true or false anymore. Only nearer and farther.
Three flaws of semantic search:
1. It always returns something. No empty result set warns you that nothing qualifies. And somebody picked the cutoff: top fifty, or similarity above 0.78. That number is a product decision, not a fact about your requirement.
2. Similar isn’t equal. “No prior healthcare experience” and “extensive healthcare experience” are semantically adjacent. Same topic, opposite meaning. Negation and numeric thresholds are what embeddings handle worst.
3. It can’t explain itself and it doesn’t hold still. A score of 0.83 isn’t a reason. Your vendor rebuilds the index or upgrades the model behind the scenes, and yesterday’s results shift. Nothing broke. Nothing warned you. The answer is just different now.
| Boolean | Semantic | |
|---|---|---|
| Returns | A set. In or out. Countable. | A ranked list. Nearer or farther. |
| Answers | “Who matches what I specified?” | “Who might fit?” |
| Negation, numbers, thresholds | Precisely | Poorly |
| Synonyms and phrasing | Only if you enumerate them | Natively |
| Reads implied meaning | No. Literal text only. | Yes, imperfectly |
| Reaches outside your records | No | Yes, when wired to external sources |
| Reproducible | Yes, against the same index | No. Drifts with model and index. |
| Explainable | Yes. The query is the explanation. | No. A score isn’t a reason. |
| Fails by | Missing people silently | Including people confidently |
| Cost per query | Effectively zero | Real, and it adds up |
Boolean is hard to write and easy to defend. Semantic is easy to write and hard to defend.
The flaw they both share
Neither one has any opinion about whether the data is from last week or from 2019.
Your data ages as it sits there. People change jobs, get promoted, change numbers. The most rigorous Boolean string ever written, run against a record nobody has touched since 2021, hands you a disconnected phone number with total confidence. The most sophisticated embedding model in the world, pointed at that same stale profile, finds you an excellent match for a job that person left two employers ago.
Precision against rotten data isn’t precision. It’s historical fiction with good syntax.
This is why the argument about query languages is only half the story, and why we built the Living Platform the way we did. Agents that continuously clean and refresh your records aren’t a layer on top of search. They’re a precondition for either approach meaning anything. Get the data right first, then argue about operators.
AI doesn’t replace Boolean. It calls it.
Here’s the part I think the market is missing, and it’s happening right now rather than someday.
When you ask an agent to find you developers in Maryland, the good ones don’t embed your sentence and go hunting for vibes. They translate it into a structured query and run it against a real index. So where did the Boolean go? Nowhere. It moved under the hood, and the model became the thing that writes it.
This is exactly what tool-calling protocols like MCP are for. An ATS exposes its search as a tool with a defined shape: fields, operators, values. The agent reads your sentence, picks the right tool, fills in the arguments, and gets back a set. The model handles the part it’s genuinely good at, which is turning messy human language into precise syntax. The database handles the part it’s good at, which is answering exactly. Value each piece doing the job it’s actually suited for.
Large language models are excellent at writing Boolean. They know the synonyms and the abbreviations. They never forget a closing parenthesis. They’ve read more sourcing strings than any human alive. Turning “senior ICU nurses with a compact license who’ve worked in a Level I trauma center” into a correct, well-parenthesized, platform-appropriate query is close to an ideal use of the technology.
So the right design isn’t natural language instead of Boolean. It’s natural language into Boolean, with the Boolean visible:
Describe what you want in a sentence. The system builds the structured query. It shows you the query. You fix one clause. It runs deterministically. Semantic ranking goes on top. The whole thing gets logged.
You get the speed of natural language and the auditability of a specification. Recruiters learn Boolean by reading it rather than memorizing it. And when something looks wrong, there’s a specific line to point at.
The alternative is natural language in, an opaque list out, no artifact and no explanation. That demos beautifully right up until the first time it actually matters. So if your vendor’s AI search can’t show you the query it ran, ask them why not. The answer is always interesting.
Not everything needs AI
Here’s a related failure that costs real money and nobody markets against.
Does every question deserve a model? Of course not. “How many developers do I know in Maryland” is a database lookup, full stop. Send it through an AI instead and you pay for the privilege, wait longer for the answer, and can get a slightly different number every time you ask. All to end up somewhere worse than a simple filter would have put you instantly, and for free.
We’re in a phase where AI gets bolted onto everything because it’s the thing people want to buy. But an agent that spins up a language model just to count records is a slower, pricier, less reliable version of something databases have done well since the 1970s. Multiply that across a team running hundreds of searches a day and the bill adds up fast.
The discipline here is simple. Use the model for the parts that need judgment and let the database handle the parts that don’t. Turning a sentence into a query needs judgment. Executing that query does not. Ranking your twenty finalists by fit needs judgment. Filtering out everyone without an active license does not.
This isn’t really about saving money, it’s about being right. Work that has an exact answer should get an exact answer. The smaller bill is just a nice side effect.
How would you know if it stopped working?
The whole industry is sprinting toward agents that source, screen, rank, and reach out with less and less human review at every step. We’re building them too. Which raises a question nobody’s sales deck answers: if one of those agents quietly started doing a worse job, how would you find out?
You can’t spot-check a feeling. Nobody can look at a quarter of AI matching and say whether it slipped. But you can absolutely write down a rule and check it. No candidate in this pipeline is missing an active license in the state we’re placing them. Nobody on the do-not-contact list got an email. Every submittal met the minimum the client actually asked for.
Those are yes-or-no questions. Yes-or-no questions can be checked automatically, every day, without a human reading a single profile.
That’s the job Boolean quietly takes on as agents do more of the work. It stops being something you type into a search box and becomes the set of rules your agents have to operate inside. The guardrail. The standing check. The thing that raises its hand when something drifts and nobody noticed.
Every serious automated business system has something like this underneath it. Your payroll system doesn’t feel like it paid everyone correctly. Recruiting isn’t going to be the exception.
Recall is a search problem. Precision is a liability problem.
These get treated as two ends of one dial. They’re different in kind.
Poor recall means you missed a candidate. An opportunity cost, real but recoverable. Poor precision means you submitted an unlicensed nurse to a hospital, or contacted somebody on a do-not-contact list, or let a protected-class proxy into your filter logic. Those aren’t missed opportunities. They’re incidents, and they have names, dates, and sometimes attorneys.
You don’t want a system that’s making its best guess anywhere near that second category.
One honest caveat, because it cuts against me. If you run retained executive search, your universe is two hundred people, you’ll personally verify every credential, and the missed candidate is the expensive failure. Recall really is your problem. The precision argument lands hardest on high-volume, credentialed, compliance-exposed desks.
What the regulators are converging on
AI employment law is moving faster than anything I’ve watched in twenty-five years of building software, so treat this as a snapshot rather than a status report.
Roughly where things stand: New York City has required bias audits for automated employment decision tools since 2023. Colorado passed the first comprehensive state AI act, delayed it more than once, saw enforcement paused in court, then replaced it with a narrower law built around notice, human review of adverse decisions, and multi-year record retention. Illinois made discriminatory use of AI in employment a violation based on effect rather than intent, added a notice requirement and an explicit ban on zip codes as a proxy for protected classes, then proposed implementing rules and withdrew them weeks later. The EU pushed its high-risk employment obligations out by more than a year.
Nearly every deadline there has already moved at least once. What hasn’t moved is the direction. Strip out the dates and all of them converge on the same three demands: notice that AI was involved, human review of adverse outcomes, and records you can produce later.
Every one of those is a demand for something you can hand over. AI produces a score. Boolean produces a written requirement. Only one of those means anything to a client, a candidate, or a regulator.
Three consequences follow. Zip-code proxying is a Boolean clause, and you can audit a string for zip codes just by reading it, which you simply cannot do to an AI model. Liability based on effect needs a defined group of people, and a Boolean query gives you exactly that, where a ranked list only does if somebody wrote down where they cut it off. And meaningful human review needs something a human can actually review. “They failed the compact-license requirement” can be checked, and found wrong. “The model ranked them 340th” can only be taken on faith.
Two things I’m not going to claim. No law requires determinism. These rules require documentation, notice, and non-discrimination, and an AI-driven system can satisfy all three with thorough enough logging. Boolean is the cheapest durable path to the artifacts they want, not the mandated one.
And Boolean carries its own exposure, worse in one specific way. NOT "career break". Graduation year ranges. “Recent graduate.” Those are age and sex proxies, and unlike an embedding’s learned correlations they’re written in plain English with a name and timestamp on them. Determinism makes good decisions auditable and bad decisions provable. A plaintiff’s lawyer would much rather have your Boolean string than your vector index.
I’d still take that trade, because the alternative isn’t safety, it’s ignorance. But nobody who’s thought about this believes explainability is free.
None of this is legal advice and I’m not a lawyer. Talk to counsel about your own exposure.
The architecture that’s actually right
Every well-built retrieval system uses both, in a specific order.
- Filter deterministically. Hard constraints first: location, license, availability, work authorization, suppression lists. This defines the universe you could legitimately submit. One caveat: a hard filter is only as good as its field coverage. If the license field is stale, the filter silently drops a qualified person, which is the recall problem coming back in the front door.
- Search two ways. Run both a keyword search and an AI search across whoever survived step one. Keyword catches the exact certifications, product names, and employers. AI catches the people you’d never have thought to look for. They miss different people, which is exactly why you want both.
- Combine the two lists and re-rank the top slice with a stronger model. Spend the compute where it matters, on the twenty people a human will actually look at.
- Log the ranking, not just the filter. If AI sets the order and your recruiter only ever calls the top twenty, your filter explains who was eligible but not who actually got picked.
- Show your work. Which constraints they satisfied, which terms matched, what the model found similar. Surfacing which document a keyword came from is a small feature that does enormous work, because it turns “this person matched” into “this person matched here, for this reason.”
Boolean isn’t the fallback here. It’s step one, and it’s the floor everything else stands on precisely because it doesn’t bend.
Buyer’s checklist
“Does it have AI?” stopped being a useful question a while ago. Everything has AI. Here are better ones:
- When your AI search runs, can I see the query it built?
- Can I edit that query, or only re-prompt it?
- Are hard constraints applied as filters, guaranteed, or as ranking signals that can get outranked?
- Can I save a search, share it with my team, and run it again in ninety days against the same data?
- Is there an audit trail, does it cover the ranking as well as the filter, and how long do you keep it?
- Does full Boolean syntax still work, or did you deprecate it in favor of the AI?
- What happens when nothing qualifies? An honest empty set, or a confident list of near-misses?
- Does every question run through AI, or can a simple lookup stay a simple lookup?
- What are you doing to keep the underlying data from rotting?
Get honest answers to six through nine and you’ll learn a lot about how a platform thinks.
Back to Boole
George Boole spent the 1840s and 50s trying to prove that reasoning has rules. That “and,” “or,” and “not” aren’t just words but operations you can trust, with results you can check. He died in 1864 without ever seeing a machine run a single one of them.
That took another seventy years, until a twenty-one-year-old named Claude Shannon wrote a 1937 master’s thesis at MIT connecting Boolean algebra to electrical relay circuits. It’s probably the most consequential master’s thesis ever written. It’s the reason a switch can compute.
Which sets up my favorite irony here. When you run an AI-powered semantic search, the GPU computing those vector embeddings is built from billions of Boole’s ANDs, ORs, and NOTs etched into silicon. Boole isn’t on one side of this debate. He’s the floor everything else stands on.
We’ve built machines that are astonishingly good at intuition, at pattern and resemblance and the useful leap. That’s a real achievement and I’m not the least bit nostalgic about what it replaced.
But intuition without verification isn’t intelligence, it’s confidence. The systems worth trusting pair a model’s reach with a specification’s rigor. Something that can guess brilliantly and prove it stayed inside the lines.
Boole gave us the second half. Turns out we still need it.
The search box is dead. Long live logic.
Want the operators themselves? Boolean operators for recruiting has all eight, a platform support table, ten copy-paste strings, and a troubleshooting guide.