Dun & Bradstreet has spent over 180 years building a comprehensive commercial database. Its commercial graph, covering 642 million businesses and their relationships, corporate hierarchies and risk profiles, was designed for people. Credit analysts, risk managers, and sales professionals who can wait for query results and work through ambiguous entity matching. AI agents can’t do any of these things.
When D&B’s customers began pushing agents into the credit, procurement and supply chain workflows, the commercial graph that had reliably served nearly 200,000 customers globally became a problem. Systems built to serve human analysts were the wrong architecture for machines. So D&B was rebuilt.
"We need to think about agents as our new consumer segment, evolving from our standard credit analysts or sales and marketing professionals, etc., to now also being agents serving these customers." Gary Kotovets, chief data and analytics officer at Dun & Bradstreet, told VentureBeat.
What broke down when the agents started questioning
Commercial Graph was not a single database. It was a collection of different systems built for different use cases and different markets, put together by custom integration. Human analysts navigate that fragmentation through SQL queries or pre-built interfaces. The agents couldn’t.
The scale of the underlying data exacerbated the problem. According to D&B, the database has nearly doubled in five years, growing from more than 300 million to more than 642 million business records, with 11,000 fields per record. The company now runs approximately 100 billion data quality checks per month as records move through its systems. It was not practical to query the need for sub-second latency agents against a fragmented architecture.
The relationships tracked by the graph were also of the wrong type. Legacy systems recorded static connections between entities. A CEO was associated with a company. That was the line. Agents working on credit assessment or third-party risk need dynamic relationships: When that CEO leaves for a new company, what organization does their track record follow? When a subsidiary changes ownership, how does this propagate through the corporate hierarchy? Those queries previously required custom analyst work. 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 hurdle: They couldn’t build what they wanted in AI because their data foundation wasn’t standardized, normalized, or agent-queryable. D&B had a foundation that had been built over decades to serve human analysts. It still had to be rebuilt for the agents.
what they actually made
Reconstruction began with consolidation. D&B migrated its fragmented database to a cloud infrastructure, redesigned the underlying schema and created a data fabric layer that normalized records across markets while preserving regional compliance requirements. The result is a unified knowledge graph that tracks billions of relationships across 642 million companies, constantly updated and enriched by AI-powered data processing.
On top of that graph, D&B built a structured access layer for agents. Raw SQL access was not the answer to agent query volume and latency requirements. Instead, D&B created a set of tools and skills available through MCP that package data with context and route agents to the right record for specific queries. Behind each query sits a matching and entity resolution engine, which confirms that when an agent asks about a company, the answer resolves to a verified, specific entity rather than a name match.
D&B resolved agent identity from both directions
Rebuilding the graph and adding MCP access resolved the data retrieval issue. This did not solve the problem of identification. Agents are not humans, and the authentication model built for human users did not extend to machines.
D&B created a new registration model for agents. They must map to a verified IP address and register a personal access key, which will be treated as an authenticated identity in the same pipeline as a human user.
"We actually have a concept of Know Your Agent, which is similar to Know Your Customer, which adds additional verification," Kotovets said.
This handles the inbound problem: knowing which company the agent belongs to and what data he is entitled to query. But D&B has also built in an outbound problem: what happens when a client’s own multi-agent workflow loses track of which company it’s analyzing.
In a workflow that combines a credit check agent, a KYC agent, and a third-party risk agent, each queries the D&B at a different stage. Without any mechanism to confirm that they are all referencing the same entity, a workflow may end up working on different records.
"They need to come back to our validation agent to make sure they’re still talking about the same entity to each other," Kotovets said. "In a way, it’s almost like a digital handshake."
D&B’s Business Verification Agent can be embedded into any workflow as a consistent reference point and is available on Google’s A2A protocol, regardless of which orchestration tool the customer uses.
Four things enterprises must get right before deploying AI agents
The rebuild highlighted needs that go beyond D&B’s own stack.
- Data foundation agents come before infrastructure. The CDOs and CIOs Kotovets spoke to over the past six months consistently stuck to the same thing: They can’t build what they want in AI until their data is cleaned, normalized, and aggregated. D&B already had that foundation. Most enterprises don’t do this, and they will realize it.
-
Design for dynamic relationships, not static relationships. Enterprise data systems typically record point-in-time connections: a person belongs to one company, an asset belongs to a subsidiary. Agents working on credit, risk or supply chain decisions need to reason about relationships that change over time. If the underlying data only captures the static line, the agent will do the same.
-
Build entity consistency checks into multi-agent workflows. When multiple agents touch the same entity at different stages, there is no guarantee that they are all referencing the same record by the time the workflow is complete. That difference clearly needs to be engineered out. Entity validation is a workflow design requirement, not an optional guardrail.
-
Involve lineage from the beginning, not as an afterthought. The answer produced by each agent must lead a traceable path to its source. In credit, risk and supply chain decisions, the costs of error are tangible. Lineages should be built before scaling, not added after problems arise.
"You can always click to see where it came from, and verify it back to the original source," Kotovets said. "That’s the key for us to unlock a lot of other capabilities, because we have that level of certainty in the things we’ve done."
<a href