How to Ground AI Agents in Company Data

Ask a large language model whether a specific company is active, who its directors are, or who ultimately controls it, and you will get a confident answer. Ask it about a company it has never seen — a three-year-old GmbH in Frankfurt, a private limited company in Manchester — and you will often get a confident answer too. The model does not know that it does not know. It predicts the most plausible continuation, and a plausible continuation of "the registration number is" looks exactly like a real registration number.

This is a manageable quirk in a chatbot. It is a structural liability in an AI agent — a system that acts on its own outputs. An agent that onboards a supplier, screens a counterparty, or pre-fills a credit assessment based on an invented filing status has not made a small error. It has made a decision on fabricated evidence, at machine speed, with no human in the loop to catch it.

The fix has a name: grounding. But grounding is only as good as the data underneath it, and most of what the industry calls "company data" cannot ground anything — because it cannot be traced back to a source. This guide covers how to ground AI agents in official company data: what grounding actually is, why the source tier matters more than the technique, and the seven design decisions that separate an auditable agent from an articulate one.

In short, the seven decisions are:

What grounding actually means — and what it does not fix

Grounding an AI agent in company data means connecting every entity-level claim the agent makes — status, officers, ownership, financials — to a record retrieved from a verifiable source at task time, so that each answer can be traced to a specific registry filing rather than generated from the model’s training memory.

Grounding is the practice of connecting a model’s output to a verifiable source of information, so that answers are anchored in retrieved data rather than in the model’s training memory. Retrieval-augmented generation (RAG) is the best-known technique, but it is one technique, not the definition: grounding can equally be achieved through tool calls and structured data lookups. For company data, the tool-call form matters most — the agent queries a database mid-task and receives typed fields, not prose passages.

The distinction is worth pausing on, because most readers arrive equating grounding with RAG. RAG retrieves passages — chunks of text ranked by semantic similarity — and asks the model to read them. That fits documents: policies, contracts, filings as prose. Company facts are not prose. A filing status, a director appointment, a shareholding percentage are discrete, typed values with exactly one correct answer per entity, and similarity search is the wrong retrieval primitive for them: it can surface the record of a similarly named company and the model will read it just as fluently. For entity data, the right primitive is the exact-match structured lookup — a tool call keyed on identifiers, returning fields, with no interpretive step in between. Use RAG for the documents; use tool calls for the facts.

Two clarifications keep this honest. First, grounding reduces hallucinations; it does not eliminate them. No current architecture gets to zero. What grounding adds — and what makes it viable in regulated workflows — is traceability: when every claim links to a retrieved record, the remaining errors are detectable and attributable. Second, grounding shifts the burden, it does not remove it. An agent grounded in wrong data will faithfully repeat wrong data, with a citation attached. That is why the rest of this article is about the data, not the model.

Figure 1. One question — "Is Meridian Trading GmbH active, and who controls it?" — answered two ways. The ungrounded path produces fluent, unverifiable claims; the grounded path retrieves a record and inherits its provenance.

Not all company data can ground an agent

The grounding literature treats "connect the model to a verified source" as the end of the story. For company data, it is the beginning, because the market sells four very different things under one label.

Tier 1 is the registry itself — Companies House, the Handelsregister, the Kamer van Koophandel, a Secretary of State. This is the primary record: the legal filing, made by the company, held by the state. Everything else is derived from it. (For a full breakdown of what registries hold and how access models differ by country, see our guide to government registry data.)

Tier 2 is registry-sourced data: records collected directly from Tier 1 and stored with their provenance intact — which registry, which filing, which date. The chain of custody is one link long.

Tier 3 is the aggregated feed: data bought from other vendors, merged, and re-sold. The records may be accurate, but the chain of custody blurs. When one vendor buys from another who bought from a third, "where did this field come from and when was it last refreshed?" stops having a clean answer. An agent can retrieve such a record; it cannot cite it in any meaningful sense.

Tier 4 is scraped and AI-generated data: fields harvested from websites or inferred by models to fill coverage gaps. There is no filing behind these values at all. Grounding an agent in AI-generated data is circular — you are anchoring one model’s output in another model’s guess.

Figure 2. The chain of custody. The agent sits one hop from the registry, and the same provenance fields ride the record at every step — which is what lets the agent cite its source.

The practical rule: grounding quality cannot be added downstream. No amount of retrieval engineering turns a Tier 4 field into evidence. If the workflow must survive an audit question — and every compliance, KYB, and credit workflow must — the data layer has to sit at Tier 1 or Tier 2.

How to ground AI agents in official company data: seven design decisions

What follows is the implementation core. None of it requires exotic infrastructure — it requires discipline about seven decisions that most agent builds get wrong by default.

1. Treat company data as a tool call, never as knowledge

The foundational rule: the model’s parametric memory is not a data source for company facts. Every entity-level claim — status, officers, ownership, financials — must originate from a lookup executed at task time. In practice this means giving the agent a company-data tool (a REST endpoint or an MCP server) and instructing it, in the system prompt, that company facts may only come from tool results. The Model Context Protocol has become the standard way to expose such tools to agents across Claude, ChatGPT, Copilot, and custom frameworks, which makes this pattern portable rather than bespoke.

"But my agent already has web search"

This is the most common objection to decision 1, and it deserves a direct answer, because search-based grounding is the default in most agent stacks. Web search is grounding — but it grounds the wrong shape of question. A search tool retrieves pages ranked by relevance to a query. A company lookup retrieves a record matched to an identifier. Different operations, different failure modes.

Point a search-grounded agent at Meridian Trading GmbH and it will find the company’s own website, a directory listing, perhaps a news mention. It will not find the filing. Registry records overwhelmingly sit behind search forms that crawlers never reach, and are not published as indexable pages — the primary record is, for practical purposes, invisible to a search engine. So what comes back is prose about the company rather than the company’s record, and the model has to read and summarise that prose. Summarisation is generation. You have reintroduced the model’s judgement at precisely the point you were trying to remove it.

Three things break specifically. There is no canonical key, so nothing confirms the agent found the right Meridian Trading rather than a namesake in another jurisdiction — the resolution step in decision 2 has nowhere to land. There are no typed fields: the word "active" appearing on a webpage is not status: active from a filing, and the difference is invisible to the model. There is no provenance: a URL and a fetch timestamp tell you where the agent read something and when, not who filed it or on what date. Citing a page is not citing a source.

The honest converse: search is the right tool for everything that genuinely lives in prose — adverse media, litigation coverage, news, reputational signals. A serious agent uses both. The rule is simply not to ask a relevance engine to answer an identity question.

2. Resolve entities on canonical keys, not names

Names are the single largest source of silent grounding failures. Company names are duplicated across jurisdictions, abbreviated inconsistently, and translated freely. The canonical key for a legal entity is the registration_number plus the jurisdiction — a UK company number with GB, an HRB number with its register court, a SIREN with FR. The agent’s first job on any task is to resolve a name mention to that key pair, and to treat ambiguous resolution (multiple candidates, fuzzy match below threshold) as a failure state, not a coin flip. Tax identifiers can serve as validated secondary keys — formats differ by country, which is a solved problem if the data layer validates them per jurisdiction (see our global tax ID formats reference).

3. Return structured records with a fixed schema

Agents reason better over typed fields than over prose. A grounded lookup should return a stable schema — legal name, number, status, address, officers, beneficial owners, latest accounts — that is uniform across jurisdictions, so the agent’s logic does not fork per country. This is also where hallucination re-enters through the back door if you are careless: if the tool returns a free-text blob, the model summarises it, and summarisation is generation. Structured in, structured through.

4. Make "not found" a first-class answer

This is the decision that separates grounded agents from decorated ones. When the lookup returns nothing — the company does not exist, the jurisdiction is not covered, the match is ambiguous — the tool must return an explicit not_found status, and the agent must be instructed to report it as such. The failure mode to design against is the silent fallback: the tool comes back empty, and the model quietly answers from memory anyway, because that is what a language model does with a gap. In compliance workflows, "we could not verify this entity" is not a degraded answer. It is frequently the most valuable answer the system can produce, because it is the one that triggers escalation.

5. Attach provenance to every field

A record that can ground an agent has two halves: the facts, and the proof of where the facts came from. The proof half is a small set of fields — source_registry, registry_reference, filing_date, retrieved_at, collection_method — that costs almost nothing to carry and changes everything about what the output is. Without it, the agent’s answer is an assertion. With it, the answer is evidence: a reviewer, an auditor, or a regulator can trace any claim to a specific filing on a specific date. Provenance is also what makes the agent’s residual errors detectable — a wrong answer with a citation can be checked; a wrong answer without one can only be believed or disbelieved.

Figure 3. Anatomy of a record that can ground an agent. The provenance block is what turns an answer into evidence. Illustrative payload — field names simplified for clarity.

6. Solve freshness structurally, not per call

Agents change the economics of data freshness. A human analyst makes a handful of lookups a day; an agent fleet makes thousands per hour. The naive answer — hit the official registry live, at call time, for every lookup — collapses at exactly this point. Many registries have no API at all. Those that do impose rate limits designed for human traffic. Registry downtime becomes agent downtime. And a live call returns only today’s snapshot — no history, which means no way to answer "what did we know, and when?" after the fact.

The architecture that survives agent workloads is stored and perpetually refreshed: registry data collected on a continuous schedule, held in a uniform schema, served at database speed, with historical versions preserved. The agent gets millisecond reads and a consistent contract; the audit function gets point-in-time reconstruction; and freshness becomes a measured property of the layer — visible in retrieved_at — rather than a hope attached to each call.

Figure 4. Live-only retrieval versus stored-and-refreshed, dimension by dimension. Both start from official registries; they differ in whether the data survives the call.

7. Keep the grounding alive with change monitoring

Everything above grounds a decision at a moment in time. But companies do not hold still after onboarding: directors resign, ownership transfers, statuses lapse — and each of those events arrives as a new filing in the registry. A lookup-only architecture leaves the agent grounded in the world as it was on the day of the check. The complete design closes the loop: the data layer watches registries for new filings against the entities in your portfolio, and a material change — officer, ownership, status — triggers the agent to re-run its assessment. This turns grounding from a gate into a standing state, and it is the same shift regulators describe as ongoing due diligence: monitoring instead of periodic review. Monitoring endpoints are a standard part of the verification stack — we cover the pattern alongside lookup, ownership, and financials endpoints in our guide to the five essential APIs for automating KYB and compliance workflows.

Putting it together: a worked example

The success payload is Figure 3 — no need to repeat it. Two things the figure does not show are the call itself and, more importantly, the miss:

// The lookup, keyed on canonical identifiers — never on a name
GET /companies/lookup?jurisdiction=DE&company_number=HRB74122

// The miss is an explicit result, never an empty body
{ "match": "not_found",
   "query": { "jurisdiction": "DE", "company_number": "HRB99999" } }

The rest of the work happens in the system prompt — four lines carry most of the weight:

1. Company facts (status, officers, ownership, financials) may only
   come from tool results in this conversation — never from memory.
2. Before any lookup, resolve the entity to company_number +
   jurisdiction. If resolution is ambiguous, ask — do not pick.
3. On match: "not_found", answer exactly "I could not verify this
   entity" and stop. Do not describe the company.
4. Every entity claim in your answer must name its source_registry,
   filing_date, and retrieved_at.

That is the whole trick. The payload carries the evidence; the prompt forbids the model from manufacturing any; and the not-found branch is a scripted sentence rather than a gap.

Why regulators will force this architecture anyway

If the engineering argument does not settle it, the regulatory calendar will. Two frameworks are converging on the same requirement from different directions.

The EU AI Act’s obligations for high-risk AI systems become enforceable on 2 August 2026. Systems used for creditworthiness assessment sit explicitly in the high-risk category, and the obligations include data governance, logging, and traceability — the ability to show what data a system relied on and where it came from. An agent that assesses counterparty risk on data with no provenance has a documentation problem it cannot fix retroactively.

The EU’s AML package — the AMLR and AMLD6, applying from 10 July 2027 — carries forward the long-standing requirement that customer due diligence rest on reliable, independent sources, now as a directly applicable EU regulation with a dedicated supervisor. "Reliable and independent" is, in practice, a description of government registries. When a supervisor asks where a verification came from, "from the registry, filing reference attached, retrieved on this date" ends the conversation. "From our AI system" starts one.

Put together: an AI agent performing KYB or credit work in Europe will need to demonstrate both that its data governance is sound (AI Act) and that its sources are reliable and independent (AML package). A registry-sourced data layer with provenance fields satisfies both with the same architecture. Nothing else does.

What grounding cannot do

Two boundaries, stated plainly, because they shape the architecture around the data layer.

Registries do not hold everything an agent needs. Sanctions designations, adverse media, litigation records, and PEP status live outside company registers, in different sources with different reliability profiles. A registry-grounded agent is grounded for entity facts — existence, status, officers, ownership, accounts — and those facts are the anchor the other checks attach to. But screening still requires its own grounded sources; registry data narrows the question to the right entity, it does not answer every question about that entity.

Registry depth varies by jurisdiction — and the agent must know what its layer cannot see. Filing requirements, financial disclosure, and above all beneficial ownership access differ sharply across countries: since a 2022 Court of Justice of the EU ruling struck down general public access to UBO registers, access in much of the EU has been restricted to parties with a legitimate interest, and the AML package now rebuilds access on that basis. The practical consequence for agent design is the same principle as not-found, one level up: coverage gaps must be explicit, machine-readable facts about the data layer — "UBO data not available for this jurisdiction" — so the agent reports the gap instead of papering over it. A grounded agent that overstates its own coverage is hallucinating about its data layer instead of about the company.

Failure modes to design against

Inverting the question — how would a grounded agent still fail? — surfaces four patterns worth engineering against explicitly.

Silent fallback to memory. The most common and most dangerous. The tool errors out or returns empty, and the model answers anyway. Mitigation: hard instruction plus output validation — any entity-level claim in the final answer must map to a field in a tool result, or the answer is rejected.

Entity confusion. The agent grounds correctly — on the wrong company. Same name, different jurisdiction; parent instead of subsidiary; the dissolved namesake instead of the live entity. Mitigation: canonical keys (decision 2) plus a confirmation step that surfaces the resolved number and jurisdiction before downstream reasoning proceeds.

Stale grounding. The record was true when collected and false at decision time — a director resigned, an ownership transfer filed, a status changed. Mitigation is structural freshness (decision 6): daily refresh cycles and a retrieved_at field the agent can reason about, so staleness is visible instead of invisible.

Aggregator recursion. The subtlest one. As more vendors patch coverage gaps with model-generated fields, an agent grounded in an aggregated feed may be citing another AI’s output without anyone having decided that. The only defence is upstream: know the tier of every source in the layer, and keep Tier 4 out of any field an agent will act on.

A useful lens for all four: the goal of grounding is not an agent that is always right. It is an agent whose answers can always be checked. Which raises the obvious question — checked how?

How to test that an agent is actually grounded

Grounding is a property you verify, not a feature you enable. The test design is simple and most teams skip it.

Build a golden set with traps in it. Assemble a fixed evaluation set of company questions in three groups: real entities your data layer covers, real entities it does not cover, and — the part almost nobody does — fabricated entities that do not exist anywhere: invented names with plausible-looking registration numbers in real jurisdictions. The fabricated group is the direct probe for the silent-fallback failure mode, because a language model will happily describe a company that was never incorporated. The only acceptable output on every trap is the scripted "could not verify" response; any biographical detail about a fake company is a hard failure, regardless of how the agent scores elsewhere.

Trace every claim, not just the verdict. For the real entities, do not grade answers on overall correctness — grade them on attribution. Parse each entity-level claim in the agent’s output and check it maps to a field in a tool result from the same run, with the provenance details quoted accurately. An answer that is factually right but contains one claim with no corresponding tool field is a grounding failure: the model got lucky from memory, and luck does not survive distribution shift.

Re-run on every change — including the vendor’s. Model upgrades shift behaviour without any change on your side, and so do prompt edits and tool schema changes. The golden set runs on each of them, and the fabricated-entity pass rate is the number to watch: it is the earliest indicator that a new model version has become more willing to fill gaps. A grounded agent is not something you shipped; it is something your last evaluation run says you still have.

Frequently asked questions