enrichment pricing
How should enrichment be priced for agent workloads (no per-field bills)?
Personalization, at scale.
Here is the number that breaks per-field pricing: a developer running enrichment for an AI agent at scale found that data costs exceeded inference costs — not by a little. The model was cheap. The fields were not. Every retry, every fallback, every partial match: billed. The agent looped. The bill compounded. The budget died before the campaign launched.
That is not a vendor problem. It is a pricing-model problem.
Why does per-field billing punish autonomous agents specifically?
Human operators enrich a list once, review it, and move on. An agent does not work that way. It retries on null returns. It re-queries when confidence is low. It fans out across multiple providers to reconcile conflicting titles or stale LinkedIn URLs. Every one of those operations is a billable event under a per-field model — even when the field comes back empty, even when two providers return the same value, even when the enrichment fails silently and the agent never knew.
Databar's analysis of outcome-based enrichment makes the case plainly: retry-heavy AI workloads broke credit-based pricing. The cost structure was designed for humans clicking buttons, not agents running loops at three in the morning.
The result: teams stitching together multiple enrichment tools and receiving separate bills for data that may or may not agree with itself. No provenance. No confidence scores. No way to know which field came from which source when the agent acts on it.
What does a record-based model actually look like?
Instead of charging per field returned, a record-based model charges per contact or company enriched — one price, one record, regardless of how many providers were queried behind the scenes to fill it.
One call, multiple providers behind it — aggregated, deduped, reconciled. No per-source bills.
The practical difference:
- Per-field: enrich a title, pay. Enrich a LinkedIn URL, pay. Retry the title because it came back null, pay again. Reconcile two conflicting company sizes, pay twice.
- Per-record: send a name, email, or domain. Receive a structured, verified record. Pay once.
For ABM practitioners building agent-driven go-to-market, this matters at the architecture level. The agent does not know in advance which contacts will match. It cannot pre-screen. It sends the whole list through enrichment, acts on what comes back verified, and discards the rest. Under per-field pricing, the discarded records still cost money. Under record-based pricing, unmatched records cost nothing — you pay for delivered intelligence, not attempted queries.
Databar's agency pricing guide addresses the broader shift: aligning cost with delivered value rather than effort expended on the provider's side. The same logic applies to agent workloads. You should pay for what the agent can use, not for the waterfall mechanics that produced it.
What does bad pricing reveal about the underlying data model?
Pricing is only half the problem. The other half is what gets returned when a record does match.
Consider an enrichment run against twenty-one contacts at a professional services firm with offices in Cambridge, Norwich, and London. Seven contacts based in Cambridge. Three in Norwich. Seven in London. One contact received a correct office address. The rest received nothing — or worse, inherited the company envelope's default: the registered HQ address.
The identity layer was HQ-biased. It knew the company. It did not know the offices.
This is not a data-freshness problem. It is an architecture problem. Standard enrichment APIs resolve a domain to a company record and return the registered address. They do not model the fact that a firm with staff across multiple cities has multiple offices, not one. When an agent tries to send a personalized physical piece to a Cambridge partner, it gets the wrong city. The send is wrong before it leaves the queue.
Verifiable, agent-ready enrichment means the record carries citations — not just a field value, but the source, the confidence score, and the evidence chain that lets the agent audit what it is acting on. A Cambridge contact should return a Cambridge office address, with the source that confirmed it. No silent fallbacks to HQ.
Built for autonomous agent loops, not human dashboard-watching.
What does agent-ready enrichment actually require?
Three things separate enrichment that works in an agent loop from enrichment that merely works in a spreadsheet.
One. Deterministic output. The same seed — name, email, domain — returns the same structured record every time, or flags a confidence change. No silent fallbacks. No fabricated facts. An agent that cannot trust the consistency of its data layer cannot act reliably at machine speed.
Two. Auditable provenance. Every field carries its source. The agent can inspect why a title was returned, which provider confirmed a LinkedIn URL, whether a phone number was verified or inferred. When something goes wrong downstream — a bounce, a wrong address, a misrouted send — the trace is there.
Three. Record-level pricing. The agent enriches the whole list. It pays for matches. It does not pay for retries, fallbacks, or the waterfall mechanics that produced the final record. The cost is predictable. The loop can run.
A great rep once knew every account. Now your agents do.
The enrichment layer is what makes that true or false. Eighty-nine canonical fields, ten providers, one API call — that is the infrastructure. The pricing model is what determines whether you can afford to run it at the volume agents actually require.
What should you actually pay per enriched record?
For context, Databar's current pricing runs from ninety-nine dollars per month for five thousand credits on the Build plan. That is a per-credit model — each field or API call consumes credits. At scale, with agent retries factored in, the real cost per enriched contact climbs well above the headline rate.
Record-based pricing inverts this. You know the cost before the agent runs. You can model the campaign budget. You can set a ceiling. The agent operates within it without generating surprise invoices.
For founders and growth engineers building agentic outbound, the pricing model is not a procurement detail. It is a system constraint. Get it wrong and the agent loop is economically unviable before the first reply arrives. Get it right and the marginal cost of personalization at scale approaches zero.
The architecture question and the pricing question are the same question. An enrichment API that charges per field is telling you something about how it was designed — for human workflows, not agent loops. One that charges per record, returns citations, and holds a consistent schema across providers was built for the workload you are actually running.
Try it
abm.dev — the enrichment API for AI agents. Turn a name, email, or domain into verified, structured intelligence: titles, LinkedIn URLs, firmographics, office locations with citations, GTM attributes. One call. Record-based pricing. No per-field bills.
The playground is free. Launch credits with the code LAUNCHCODES.
Personalization, at scale.
Stuart McLeod · Co-founder, abm.dev