D&B’s database of 642 million businesses is built for people, not AI agents. So they rebuilt.
Dun & Bradstreet has spent more than 180 years developing comprehensive commercial databases. Its Business Graph, which includes 642 million businesses and their relationships, company categories and risk profiles, is built for people. Credit analysts, risk managers and sales professionals who can wait for the results of inquiries and work on business intelligence. AI agents cannot do any of those things.
When D&B’s customers began to include agents in credit processing, procurement and supply chain, Commercial Graph, which had reliably served nearly 200,000 customers worldwide, became a problem. The programs designed to assist human analysts were poor machine architectures. So D&B rebuilt.
"We need to think of agents as our new customer category, from our standard credit analysts or sales and marketing professionals, and so on, to now cater to these customer agents," Gary Kotovets, Chief Data and Analytics Officer at Dun & Bradstreet, told VentureBeat.
What happens when the agents start asking
Commercial Graph was not a single database. It was a collection of different systems designed for different use cases and different markets, held together by custom integration. Human analysts navigate that classification with SQL queries or pre-built interfaces. The agents could not.
The scale of the underlying data complicates the problem. The database nearly doubled in five years, expanding from more than 300 million to more than 642 million business records, with 11,000 fields per record, according to D&B. The company now checks the quality of approximately 100 million records per month as records move through its systems. Asking what the second latency agents need, against different structures, did not work.
The relationship traced by the graph was also non-typical. Legacy systems recorded static communication between organizations. The CEO was linked to the company. That was the line. Agents working in third party credit or risk assessment need strong relationships: when that CEO leaves the new company, which organization is their records tracked? If a subsidiary changes ownership, how does that spread across the list of companies? Those queries required custom parser work beforehand. Agents can’t wait for a custom analyst job.
The broader problem is not unique to D&B. Kotovets said he spoke to hundreds of CDOs and CIOs in the past six months and kept hearing the same barrier: they couldn’t build what they wanted in AI because their data bases weren’t consistent, generic or agent-based. D&B has that foundation, built over decades to serve human analysts. It still needed to be rebuilt for agents.
They didn’t really build it
Reconstruction began with consolidation. ID&B migrated its disparate databases to a cloud infrastructure, redesigned the underlying schema and built a data fabric layer that standardizes records across markets while maintaining regional compliance requirements. The result is a unified knowledge graph that tracks billions of relationships across 642 million companies, continuously updated and enhanced by AI-driven data processing.
On top of that graph, D&B built a structured access layer for agents. Raw SQL access to agent query volumes and latency requirements was not the answer. Instead, D&B created a set of tools and capabilities available through MCP that package contextual data and route agents to the right records for specific queries. A business matching engine sits behind every query, ensuring that when an agent asks about a company, the answer resolves to a verified, exclusive business instead of a name match.
ID&B resolved agent ownership from both directions
Rebuilding the graph and adding MCP access solved the data retrieval problem. It did not solve the identity problem. Agents are not humans, and the authentication model built for human users has not reached machines.
ID&B has developed a new subscription model for agents. They must map to an authenticated IP address and register each access key, which is treated as an authenticated identity on the same line as a human user.
"We actually have a concept called Know Your Agent, which is like knowing your customer, which makes that extra assurance," Kotovets said.
That addresses an internal problem: knowing which company the agent belongs to and what data it has the authority to query. But D&B is also building on an emerging problem: what happens when a multi-agent customer workflow loses track of which company it’s analyzing.
In a transaction involving a credit check agent, a KYC agent and a third-party risk agent, each asks D&B for a different step. Without a way to ensure that they all refer to the same entity, workflows can end up working on different records.
"They should go back to our verification agent to make sure they are still talking to each other about the same business," Kotovets said. "It’s almost like a digital handshake in a sense."
D&B’s business authentication agent can be embedded in any workflow as a continuous reference point and is available on Google’s A2A protocol regardless of the music device the customer is using.
Four things businesses should address before deploying AI agents
Revealed needs for rebuilds that go beyond the D&B stack itself.
Databases come before agent infrastructure. The CDOs and CIOs Kotovets spoke with over the past six months always hit the same wall: they can’t build what they want in AI until their data is clean, normalized and aggregated. ID&B already has that foundation. Most businesses don’t, and will feel it.
It is designed for dynamic relationships, not static ones. Business data systems typically record relationships that exist in time: a person belongs to a company, an asset belongs to a subsidiary. Agents working on credit, risk or supply chain decisions must consider relationships that change over time. If the underlying data captures only a static line, the agent will also capture it.
Build business consistency checks into multi-agent workflows. If multiple agents touch the same entity in different steps, there is no guarantee that they all refer to the same record when the workflow is completed. That gap needs to be made clear. Business validation is a requirement of workflow design, not an optional goal.
Embed genealogy from the beginning, not as an afterthought. Every response generated by an agent must carry a traceable path back to its source. In credit, risk and supply chain decisions, the cost of error is real. Pedigrees need to be created prior to measurement, not added after problems appear.
"You can always click to see where it came from, and verify it from the original source," Kotovets said. "That’s been key for us in unlocking a lot of other skills, because we have that level of confidence in the things we’ve done."
