Agents

Entity resolution for AI agents

For the team that owns a company master and has to defend it.

An agent that acts on a company has to decide which company it is acting on, and in most stacks that decision is invisible. The model is handed a name from an email or a search result, forms a belief, and the next tool call spends money against it. Nothing in the transcript distinguishes a counterparty identified from a register from one inferred from a plausible website, because both arrive in the context window as the same kind of sentence. The fix is not a better model. It is a tool contract that can return "I do not know" in a form the agent can route on.

A stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, counterparty onboarding that has to survive an audit. Read the argument here, take the takeaways at the foot into your next vendor conversation, and send us a file when you want the same measurement on your own rows.

Agents · 2,106 words · every figure carries the population it was measured over

Reading time
11 min read
Sections
8
Questions answered
6
Key takeaways
7
the same measurement, on your rows
A first file is a few hundred of your own rows with the matches you already have beside them. The numbers in this article come back measured on your data, and we write nothing to your systems.
Start free →
Self-serviceCreate your workspace online and verify your email to start matching company records. Free starts with 300 credits and no card. Paid monthly plans are available in workspace Billing; VAT is added where applicable. Usage is tracked without automatic overage charges. Trust and security
On this page

The failure is in the tool contract, not in the model

Three tool designs are common in this space and all three teach an agent something false.

A search endpoint that returns candidates hands disambiguation back to the model, which will pick one, because picking one is what a language model does with a ranked list. A matching endpoint that returns a similarity score hands over a number the model cannot calibrate, so 0.72 and 0.91 both read as "probably yes". And a tool that returns null on failure teaches the agent that failure means absence, so "we could not tell" becomes "there is no such company" one hop later, and the agent proceeds to create a new supplier record for a company you already have.

None of those is a model quality problem, and none is fixed by a larger model. They are contract problems: the tool has no way of expressing uncertainty that the caller can act on differently from certainty, so the caller flattens both into a decision.

Why the blast radius is different

A person who is unsure asks somebody. That single behaviour absorbs an enormous amount of ambiguity in a manual process, and it is the behaviour that does not survive automation.

An agent that is unsure and has a payment tool available proceeds, at machine speed, across every record in the queue, with a self-reported confidence that has never been measured against an outcome. The same error a human would make once gets made four thousand times before anybody looks, and each instance carries a plausible-sounding justification in the transcript, which makes the review harder rather than easier.

So the property an agent needs from an identity tool is not higher accuracy. It is a refusal it can distinguish from an answer, and a refusal that tells it what to do next.

Abstention as the safe default

Anything below 0.90 confidence is not returned as a match at all. A match below 0.90 confidence is unrepresentable. The record comes back as an abstention with a ranked shortlist instead. That means an agent's branch is on the decision rather than on a threshold: a match to act on, an abstention to escalate or enrich, or a non-match. There is no low-confidence answer to mishandle, because there is no low-confidence answer.

An abstention is a first-class result rather than an error or a null. It carries a ranked shortlist of up to five candidates, each with a probability read from how often decisions like it turned out right rather than from a model's own self-report, a typed reason for stopping, a clarification naming the one field that would settle it, a review id so the row lands in a queue a human can work, and a decision id that reopens the whole evidence trail at a URL. It costs zero credits at every stage, including the stages that spent the most getting there — which is the property that makes it safe to build an agent that asks unanswerable questions.

The four typed reasons instruct four different behaviours, and an agent that branches on them behaves very differently from one that retries blindly.

The distinction the flags exist to preserve is between a retry that might work and a retry that cannot:

  • more_input_needed — the paid stages could not separate the shortlist. Retrying deeper will not change it. Ask a human, or fetch an identifier from the contract or the invoice.
  • no_identifying_signal — the fields normalised to nothing identifying. The only one the agent can fix by itself, by supplying more of what it already has.
  • depth_capped — you stopped this. A deeper call may resolve it, if the credential allows the depth.
  • escalation_unavailable — a dependency failed. A retry is genuinely worth trying, which is exactly what the first two are not.

A decision with a receipt, not a similarity score

The second thing an autonomous caller needs is an artefact that outlives the context window. Transcripts are not evidence: they are a reconstruction of what the model said it did, they are lossy, and they are not addressable from outside the run.

Every resolution — including every refusal — persists a receipt that reopens at a URL. It carries the feature vector, the top weighted contributions, the thresholds the call was judged under, the cited evidence with source URLs, the adjudicating model id and prompt version where one ran, the pipeline version, and a re-run of the score from the stored features so the probability can be checked rather than believed. Redeeming it is free and unmetered.

That is what makes an agent's counterparty check auditable after the fact, and it is also what makes the unchecked path visible. A payment made after a resolve has a decision id attached to it; a payment made after the model decided from a website has nothing. Nothing here stops a badly built agent paying the wrong company — it is a tool, not a control plane — but it does make the difference between a checked and an unchecked counterparty something you can query rather than something you have to read four thousand transcripts to establish.

One caveat worth building around: the stateless pairwise comparison tool persists nothing, so it mints no receipt, no decision id and no audit row. If the agent's action needs to be defensible later, it needs a resolve rather than a match. If you add a confidence filter, evaluate its coverage cost and the evidence behind each eligible population. Confidence bounds depend on the recorded evidence population; there is no universal score for every match. Read match_confidence_basis and the evidence. A 0.99 filter can return some v8 adjudicated matches while excluding valid identifier matches, so validate its coverage cost on your own inputs.

The MCP surface

The same pipeline is exposed as eleven Model Context Protocol tools, over local stdio or a remote streamable HTTP endpoint, with the same credentials, the same tenancy and the same credit rule as the HTTP API. Two of the eleven are billable — resolving a company, and comparing two records — and nine are free and unmetered: reading an entity, walking the identifier crosswalk, discovering enrichment fields, searching known entities, redeeming a receipt, reading usage, and three review-queue tools.

Three design decisions in that surface are about what an agent must not be able to do, and each is structural rather than advisory.

  • Tenancy is derived per call from the credential and is never a request parameter, so a model cannot address another tenant by writing a different id in an argument. Cross-tenant reads report not-found rather than forbidden, so ids cannot be probed by watching which error comes back.
  • The credential caps depth before the cascade runs. A key pinned to the no-egress stages cannot reach agentic research by choosing this surface instead of the HTTP one.
  • There is no erasure tool, no batch tool, no catalogue export and no provisioning tool on this surface, and an admin-scoped key is refused before a caller object even exists. The credential that can mint credentials is structurally unreachable by a model, and an erasure obligation is discharged by a person who can be asked why rather than by a step in a plan.

Spend the agent can audit

Both billable tools return a usage block: credits charged, credits remaining, deep attempts remaining, the plan, and whether billing is enforced. A tool call has no response headers, so that block is the only place an agent can learn what a call cost — and it means the agent can check on every call that it was charged for an answer rather than for an attempt.

The rule itself is short enough for an agent to reason about. 1 credit for a decision reached by the deterministic or probabilistic stage. CPU only, no egress. 5 for a decision that needed LLM adjudication or agentic research. 0 for an abstention, at any stage, including the ones that spent the most getting there. 0 for a byte-identical replay. Per tenant, per exact content, and with no expiry. And 0 for an input that normalised to no identifying signal. There was nothing to answer.

One field in the usage response is routinely misread and it matters here more than anywhere. The automation rate is the share of calls answered automatically, not an accuracy rate. Precision cannot be measured from usage at all, because review items exist only where the pipeline abstained, so the automatically merged population carries no labels to score against.

Untrusted text, treated as untrusted

Where the research stage runs, it fetches web pages, and a web page is attacker-controlled text arriving inside a prompt. Four mitigations are in place and one residual risk is open rather than declared solved.

Fetched content is fenced as data with its own closing tag stripped, so a page cannot terminate the fence and issue instructions. Findings are constrained to an attribute allow-list from which registration identifiers are deliberately absent, so a page cannot supply the field that would decide a match. Web observations rank below your own facts in the source precedence, so a page cannot overwrite something you told us. And the adjudicator's output is constrained to a schema and abstains below the floor: the model can recommend and can never commit.

The residual is open and dated rather than closed. A poisoned page can supply plausible false content that nudges a genuinely borderline verdict into human review. That is a denial of decision rather than a false bind, which is the right direction for the failure to point, and it is recorded as an open risk rather than a solved one.

What this does not do

A pre-action policy check bound to a specific action, with a short-lived receipt scoped to that action, is a design-partnership build rather than a shipped feature. What ships today is the decision, the calibrated confidence, the abstention and the receipt.

An empty search result is not a claim that a company does not exist. It means no known entity shares an identifier or a name key with the input, and an agent reading it as non-existence will be wrong — which is exactly the null-means-absence failure described at the top, reappearing on a different endpoint.

The scope boundary applies unchanged on this surface: companies and organisations only, never people, and never an eligibility decision about an individual. An agent asking about a person gets nothing, by design rather than by omission. And no MCP tool creates a key: keys are made in your Entity Bind workspace, so an agent working over MCP cannot provision itself one — which is a deliberate property of the system rather than a temporary state of the onboarding flow.

Key takeaways

What to take away

  • The failure mode is the tool contract, not the model: search endpoints delegate disambiguation, similarity scores are uncalibrated, and null teaches the agent that uncertainty means absence.
  • An agent that is unsure does not ask anybody. It proceeds at machine speed across the whole queue, which is why abstention has to be a first-class result rather than an error.
  • Nothing below 0.90 is returned as a match, so the agent branches on the decision rather than on a threshold. Abstentions cost zero credits at every stage.
  • The four typed abstention reasons separate a retry that might work from a retry that cannot, which is the difference between an agent that escalates and one that burns budget.
  • A receipt that reopens at a URL is what survives the context window. The stateless pairwise tool mints none, so an action that must be defensible needs a resolve.
  • Tenancy comes from the credential and never from an argument; depth is capped by the credential; and there is no erasure, batch, export or provisioning tool on the agent surface.
  • Prompt injection is mitigated four ways and one residual is left open: a poisoned page can push a borderline verdict into human review, which is a denial of decision rather than a false bind.

Those takeaways hold for anybody's data. The number for yours comes out of your own rows — a few hundred of them, with the matches you already have beside them.

Start free
Still not answered?it will name the article that covers it, or say where the field has no settled answer
Ask whatever this article left open. If the answer is a number it comes with the population it was measured over, and if it belongs to another article or a glossary entry I will name that one.

Prefer to put it to a person? Talk to us instead →

Is this your file?

The article is for anyone. The measurement behind it is worth commissioning for one kind of team.

built for

Teams with a company master they have to defend — an MDM or stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, or counterparty onboarding that has to survive an audit.

wrong for

Buying breadth as the product: we hold a fraction of an incumbent’s records and are not building a global company graph. Entity Bind resolves companies and organisations only. It does not resolve people, vessels, bank-account ownership, sanctions exposure, emissions or geolocation, and its results may not be used for eligibility decisions about individuals, including employment, credit and tenancy.

the basis for every figure above

Internal fixtures only. The historical 2026-08-29 per-tier recording covers 317 GB companies with identifier-rich arrivals seeding the catalogue first; the context tier includes country and registered-town prose. Its legacy replay has no full-prompt-verified calls and cannot certify current calibration. The September 5 CI reports cover 1,176 labelled pairs and 705 records over 250 companies using offline stubs. These are not independent customer holdouts or live production validation; the 99% minimum-input product target remains unmet. Scope is company and organisation identity only — not people, vessels, bank-account ownership, sanctions or emissions. Results may not be used for eligibility decisions about individuals, including employment, credit and tenancy.

Figures read off the product repository on 2026-09-05. The per-tier rates come from the live-adjudicated 317-company recording of 2026-08-29; the gate figures come from the stub-adjudicated continuous-integration run and are a floor rather than a ceiling. The two are never averaged. Entity Bind holds no SOC 2, no ISO 27001 and no other certification, and claims none. Every figure, with the population it was measured over and the method behind both recordings, is set out on the accuracy page. The retention, erasure, tenancy and sub-processor detail a security review asks for is under Trust and security, with where assurance stands: no external validation of the accuracy figures and no customer holdout.

the ask

The same measurement, on your own rows.

Create your workspace, verify your email and run your first company file. The Free plan needs no card. Create API keys in your workspace when you need an integration.

300 credits. No card.

For a guided review of your file, explore the Merge Safety Sprint →

The questions this article answers

Why can't an agent just use a company search API?

Because a search API returns candidates and delegates the decision to the model, which will choose one. That is fine when a human reads the list and notices that two of the five are plausible; it is not fine when the next tool call is a payment. What an autonomous caller needs is a tool that either decides or refuses, where the refusal is structurally distinct from an answer and carries an instruction about what would resolve it.

What should an agent do with an abstention?

Branch on the typed reason rather than retrying. more_input_needed means the paid stages could not separate the shortlist, so a deeper retry will not help and the agent should ask a human or fetch an identifier. no_identifying_signal is the one the agent can fix itself. depth_capped means a deeper call may work. escalation_unavailable means a dependency failed and a retry is genuinely worth trying. Abstentions cost zero credits, so an agent asking an unanswerable question is not a bill.

Is the confidence score something a model can threshold on?

It is calibrated against the recorded outcomes of the population that decision belongs to rather than taken from a model's self-report. Anything below 0.90 is never returned as an accepted match, so branch on the decision first. If your policy needs a stricter filter, evaluate its coverage cost on labelled records. Confidence bounds depend on the recorded evidence population; there is no universal score for every match. Read match_confidence_basis and the evidence. A 0.99 filter can return some v8 adjudicated matches while excluding valid identifier matches, so validate its coverage cost on your own inputs. The adjudicating model's own self-reported confidence is carried separately, is uncalibrated, and is never thresholdable.

Does an MCP call cost more than an API call?

No. It is the same resolve, at the same price, against the same rate-limit bucket — the tools delegate to the same application services as the HTTP surface, so limits are shared rather than doubled. Two of the eleven tools are billable and nine are free and unmetered: reading an entity, reading a crosswalk, discovering enrichment fields, searching, redeeming a receipt, reading usage, and the three review-queue tools. On either surface, 0 credits is the price of an abstention, at any stage, including the ones that spent the most getting there.

Can a prompt injection in a fetched page change the answer?

It can push a borderline verdict into human review, and that residual is recorded as open. What it cannot do is issue instructions — fetched content is fenced as data with its own closing tag stripped — or supply a registration identifier, which is deliberately absent from the findings allow-list, or outrank your own facts in the source precedence, or commit a merge, because the adjudicator's output is schema-constrained and abstains below the floor.

Can an agent settle its own review items?

It can read the queue with a resolve credential and it can settle nothing. Settling requires a separately issued review credential, and the reviewer identity written onto a verdict is the immutable name assigned when that credential was minted rather than a name supplied in the call. So an agent cannot assert whose judgement a merge represents, which is the point of the separation.