Dun & Bradstreet has been creating a comprehensive business database for over 180 years. Its Business Chart, covering 642 million companies and their relationships, corporate hierarchies and risk profiles, was designed for people. Credit analysts, risk managers, and sales professionals who might wait for query results and work on ambiguous entity matches. AI agents can’t do any of those things.
When D&B clients began pushing agents into credit, procurement, and supply chain workflows, Commercial Graph, which had reliably served nearly 200,000 clients worldwide, became a problem. Systems built to serve human analysts were the wrong architecture for machines. So D&B rebuilt it.
"We need to think of agents as our new category of consumers, evolving from our standard credit analysts or sales and marketing professionals, etc., to now also serving the agents of these customers." Gary Kotovets, director of data and analytics at Dun & Bradstreet, told VentureBeat.
What broke when the agents started asking questions?
The Business Chart was not a single database. It was a collection of separate systems built for different use cases and different markets, tied together through custom integrations. Human analysts navigated that fragmentation through SQL queries or pre-built interfaces. The agents couldn’t.
The scale of the underlying data compounded the problem. The database had 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 performs approximately 100 billion data quality checks per month as records pass through its systems. Querying that with the sub-second latency required by agents, in a fragmented architecture, was not feasible.
The relationships the graph followed were also of the wrong type. Legacy systems recorded static connections between entities. A CEO was linked to a company. That was the line. Agents working on credit assessments or third-party risks need dynamic relationships: When that CEO leaves for a new company, which organization tracks his or her track record? When a subsidiary changes ownership, how does that propagate through the corporate hierarchy? Those questions required custom analyst work beforehand. Agents can’t wait for custom analyst work.
The broader problem is not unique to D&B. Kotovets said he has spoken to hundreds of CDOs and CIOs over the past six months and consistently heard the same limitation: They couldn’t build what they wanted in AI because their databases weren’t standardized, normalized, or queryable by agents. D&B had that foundation, built over decades to serve human analysts. It still had to be rebuilt for the agents.
What they really built
Reconstruction began with consolidation. D&B migrated its fragmented databases to cloud infrastructure, redesigned the underlying schema, and created a data structure layer that normalizes records across markets while preserving regional compliance requirements. The result is a unified knowledge graph that tracks billions of relationships across 642 million companies, continually updated and enriched through AI-powered data processing.
In addition to that graph, D&B created a structured access layer for agents. Raw SQL access on agent query volumes and latency requirements was not the answer. Instead, D&B created a set of tools and skills available through MCP that package data with context and direct agents to the correct records for specific queries. Behind every query is a match and entity resolution engine, which confirms that when an agent asks about a business, the answer resolves to a specific verified entity instead of a name match.
D&B resolved the identity of the agent from both directions
Rebuilding the graph and adding MCP access resolved the data recovery issue. It did not solve the identity problem. Agents are not human and the authentication model created for human users was not extended to machines.
D&B created a new registration model for agents. They must be assigned to a verified IP address and register an individual access key, treated as an authenticated identity in the same process as a human user.
"In fact, we have a Know Your Agent concept, similar to Know Your Customer, that performs those additional checks." Kotovets said.
This solves the initial problem: knowing which company an agent belongs to and what data they have the right to consult. But D&B was also built for the exit problem: what happens when a client’s multi-agent workflow loses track of which company it’s analyzing.
In a workflow that chains together a credit verification agent, a KYC agent, and a third-party risk agent, each queries D&B in a different step. Without a mechanism to confirm that they all reference the same entity, a workflow can complete while operating on divergent records.
"They have to go back to our verification agent to make sure they are still talking to each other about the same entity." Kotovets said. "In a sense, it’s almost like a digital handshake."
The D&B Enterprise Verification Agent can be integrated into any workflow as a persistent reference point and is available on Google’s A2A protocol regardless of which orchestration tool the customer uses.
Four things companies should get right before deploying AI agents
The rebuild exposed requirements that go beyond the D&B stack itself.
-
Databases come before agent infrastructure. The CDOs and CIOs Kotovets spoke to over the past six months have constantly hit the same wall: They can’t build what they want in AI until their data is clean, normalized, and consolidated. D&B already had that foundation. Most companies don’t and they will feel it.
-
Design for dynamic relationships, not static ones. Enterprise data systems often record one-off connections: a person belongs to a company, an asset belongs to a subsidiary. Agents working on credit, risk, or supply chain decisions must reason about relationships that change over time. If the underlying data only captures the static line, the agent will do so as well.
-
Create entity consistency checks in multi-agent workflows. When multiple agents touch the same entity in different steps, there is no guarantee that they are all referencing the same record when the workflow completes. That gap needs to be explicitly addressed. Entity verification is a workflow design requirement, not an optional security measure.
-
Incorporate lineage from the beginning, not as an afterthought. Every response produced by an agent must have a traceable path to its origin. In credit, risk and supply chain decisions, the cost of an error is concrete. Lineage should be added before scaling, not added after problems arise.
"You can always click and see where it came from and validate it back to the original source." Kotovets said. "That’s been the key for us in unlocking a lot of other capabilities, because we have that level of certainty in the things we’ve done."
