Data Enrichment Isn't a Batch Job Anymore — It's a Runtime Tool Call

My position: data enrichment is not a step in the workflow. It's a tool the agent calls.

I manage our sales tech budget. Last fiscal year it was $180,000 across about 14 vendors (sequencing, enrichment, intent, verification, LinkedIn tooling — the usual stack). I've negotiated enough of these contracts to know that the pricing model usually tells you more about the architecture than the sales deck does.

So here's my argument, and I'll be blunt about it: if your data enrichment contract is priced per thousand records in a fixed monthly batch, you're paying for records the agent will never touch. In an agent-native prospecting workflow — the okki-go / AI SDR category — enrichment stops being a pipeline and becomes a tool call. That shift is not cosmetic. It changes what you pay for, when you pay, and how you should evaluate vendors.

Why does this matter to someone holding the invoice instead of the keyboard? Because the pricing line items in this category are still stuck on the old model while the product has moved on. That's a negotiating problem, and it's an architecture problem.

Argument 1: Bulk enrichment produces dead inventory in an agent workflow

The classic enrichment playbook: take a CSV of 5,000 accounts, run it through a waterfall of providers, append emails, titles, tech stack, funding signals, and dump it back into the CRM. Done. Everyone feels productive.

In an agent-native workflow, that CSV is not the input. The prompt is. When an AI SDR agent researches an account before writing an email sequence, it doesn't need enrichment for all 5,000 records. It needs enrichment for the 40 it's going to actually work this week — plus a few fields on the 15 lookalikes it decided to check based on what it learned from the first 40.

So what happens to the other 4,960 enriched records? Statistically, most of them sit untouched until they're stale. I audited our own CRM export in Q3 2025 and found that roughly 71% of the enriched contact fields we'd paid for hadn't been referenced by any sequence, call task, or manual outreach in the preceding 90 days. That's not a data problem. That's a purchasing problem.

Here's the thing: the enrichment itself may have been accurate. It was just enriched at the wrong moment, for a decision the workflow never made.

Argument 2: Agents amplify bad data — they don't clean it up

This is the part that catches people off guard. When a human SDR gets an enrichment record that says "VP of Sales" for a person who left the company eight months ago, they hesitate. They check LinkedIn. They ask a colleague. The error gets absorbed by human skepticism.

An agent doesn't do that. It takes the field at face value and writes the email.

I said "automatically reconciled." My vendor heard "automatically enriched." Two different things. We discovered the mismatch three weeks into the pilot when the agent was confidently referencing a prospect's former employer in email sequences. Nobody had defined what "reconciled" meant in the SOW. That was on me as much as on them — but it's the exact failure mode this architecture creates if you don't plan for it.

Which brings the workflow implication: enrichment inside an agent-native system has to return confidence and freshness metadata, not just field values. If okki go account research just fills in a company size and industry and hands them to the agent with no signal about how recent or reliable that data is, the agent has no way to weight it. That's a design flaw in the workflow, not the data.

Argument 3: The counterintuitive cost math — bulk looks cheaper, isn't

I went back and forth between two enrichment vendors for about three weeks. Vendor A quoted $0.08 per enriched record on a batch model with a 5,000-record monthly minimum. Vendor B quoted $0.14 per successful enrichment call, no minimum, pay-per-use.

On paper, Vendor A looked like a 43% savings. My gut said something was off — the pricing structure didn't match how the agent was actually going to consume the data. I ran a two-month shadow test against our actual agent usage logs before signing either.

Real numbers from that test: the agent made an average of 1,240 enrichment calls per month across 620 accounts, and 22% of calls were repeat lookups on the same account at different times (because the agent needed updated intent data before its second-touch sequence). Under Vendor A's batch model, we'd pay the 5,000-record minimum regardless. Under Vendor B, our actual monthly spend was around $172 — under a quarter of the batch minimum, and we weren't paying for records the workflow never asked for.

The lesson wasn't "pay-per-use always wins." It was that the pricing model has to match the call pattern. If the workflow is event-driven, the contract has to be event-driven. A batch minimum is a bet that your team will consume data at a steady rate. Agent workflows don't consume at a steady rate. They spike.

"But we want simplicity" — yes, we did too

I can already hear the objection: this sounds like more moving parts. Runtime enrichment means more API calls, more per-call monitoring, more vendor management. Wouldn't a batch job every Sunday night just be easier?

It is easier. It's also the reason we spent two weeks in Q1 2026 cleaning stale fields out of our email sequences after a job title refresh missed about 800 contacts. The "simpler" model was cheap on the setup side and expensive on the cleanup side. Standard TCO math — you just don't see the second cost until the invoice is behind you.

The other objection I get: doesn't this make budgeting harder? Somewhat, yes. When enrichment is event-driven, your monthly spend fluctuates. What I did was cap it — a monthly ceiling on runtime enrichment calls that the agent respects, with a soft alert at 80%. That's a procurement policy, not a product feature, and it's the kind of thing worth negotiating into the contract before you sign, not after. Vendors will almost always add a usage cap clause if you ask. They won't volunteer it.

Where this lands

I'm not arguing that batch enrichment is dead. There are legitimately static use cases — territory planning, annual account scoring, list-building for a one-off campaign. When the consumer is a human analyst working off a spreadsheet, batch is fine.

But in an agent-native prospecting workflow — the okki-go class of tools, the data enrichment sales automation category broadly — the consumer of enrichment is a decision-making loop, not a spreadsheet. That changes the answer to "how does data enrichment fit in" completely. It doesn't sit at the front of the pipeline. It sits inside every account research call the agent makes, priced per call, returning fresh data with provenance, and capped so finance isn't surprised.

If your current enrichment vendor won't sell it that way, the honest question isn't whether you can live with the batch model. It's whether the batch model is living off you.