Key Takeaways
- Verified data, not the model, is what decides whether an autonomous decision can be reliable.
- Once the underlying data is verified, a wrong answer becomes a model problem to fix, not a data problem to accept.
- Governance decisions, like which data and which models are allowed to touch production, have to be made before agents go live, not after something breaks.
- Years of validated business logic already sitting inside enterprise software converts directly into agent skills.
- Small, task-specific models applied to narrow steps cut token costs 95% to 97% on some tasks, and raised accuracy at the same time.
A landscaping company applying for insurance will usually tell you one thing about itself: it cuts grass. That's the self-reported answer underwriters have worked with for years, and it's often wrong.
In a recent AI Explained, Gary Kotovets, Chief Data and Analytics Officer at Dun & Bradstreet, walked through why verified data, not the model doing the reasoning, is the part of the agentic stack most enterprises get wrong, and what it actually takes to build a data foundation an autonomous agent can be trusted to act on.
Verified Data Is the Difference Between a Grounded Answer and a Guess
Data here means the information an agent retrieves in order to answer, not the data a model was trained on. It's the difference between what a model knows in general and what it can verify about a specific company, customer, or transaction.
That verification work has to happen continuously. Sources get validated, and the values extracted from them have to stay accurate, timely, and consistent as the underlying facts change. Quality rules get modified as upstream sources shift, rather than written once and trusted indefinitely. At the scale of a major commercial data provider, that means billions of automated quality checks running across incoming data.
Hallucination Becomes a Model Problem When the Data Is Ground Truth
Hallucination is usually treated as an unavoidable property of language models. For a team grounded in verified data, it looks different, because a wrong answer isn't a data failure. It's the model failing to serve up what the data already said, which is a far more tractable problem.
It's tractable because it's testable. The approach that works is a standing qualification pipeline, where any new model, open source or a new frontier release, automatically enters testing and validation as soon as it appears. Evaluation covers how the model responds across datasets and how it executes as an agent, meaning whether the steps it took were the right ones.
Verified Data Has to Reach Where Agents Already Live
Enterprise data already sits inside risk applications, procurement systems like SAP, and CRMs, and the agents being built against it sit in those same places, or in the coding assistants where developers assemble the workflow. Reaching them takes deliberate packaging: data made available through MCP so it becomes a callable context layer rather than an export, skills and tools published as markdown so builders can adapt capabilities into agents already running against first-party data, and agent-to-agent protocols so a service like entity verification can be discovered in a marketplace and dropped into an existing workflow.
That packaging decision determines whether verified data actually reaches the point of decision, or whether an agent quietly substitutes something it scraped instead.
Stale and Conflicting Sources Are a Monitoring Problem
Two trusted sources disagreeing is normal when data arrives from thousands of upstream feeds, and an agent caught between them can't adjudicate on its own. Stale data is harder to catch, because nothing about a stale value announces itself as wrong. It gets caught operationally, by requiring upstream changes to be communicated through the data supply chain, and behaviorally, by checking periodically whether agent outputs still match what the current data supports.
Governance Decides What Data and Models Are Allowed to Reach Production
None of the data work above matters if there's no framework deciding which sources, which models, and which use cases are even allowed to go live. That's the job governance does, and it has to run alongside the data work, catching problems before an agent is built on top of them rather than after.
Every Model and Every Use Case Gets Reviewed Before It Ships
A working framework answers three questions before anything goes live: what a model's terms and conditions permit, what data privacy and transfer rules require for that specific workload, and what counts as ethical use, including how personal data is protected and where it's allowed to travel.
Two separate reviews follow from those questions. The model gets reviewed before any team is cleared to build with it, and the use case and its workflow get reviewed before they reach production. Both draw reviewers from legal, the chief risk officer's organization, technology, and product. Standing up that process takes time, but considerably less time than pulling an unapproved model out of a live workflow.
One Rule Does Most of the Work
Among all the policies an enterprise can write, one rule carries disproportionate weight: anything anyone builds has to demonstrate where the answer came from.
That requirement forces lineage into every product decision and rules out architectures that can't explain themselves. Audit evidence becomes a byproduct of normal operation instead of a project on its own. Paired with a central platform carrying data entitlements and access controls, the constraint gets enforced by the environment rather than by the diligence of whoever happens to be building.
Autonomy Is a Risk Tolerance Decision
How much human oversight a workflow gets is configured per workflow, and the choice belongs to the business owner who will answer for the outcome. The same agentic workflow supports three settings: it can run fully automated, a person can hold a checkpoint at any individual step inside it, or a person can sit only at the end and make the final call, issuing the credit, onboarding the supplier, sending the message to the customer.
The Best Agent Tooling Already Exists Inside the Business
Tools means the agent stack: the agents that carry out the work, the smaller components they call to complete individual jobs, and the monitoring that watches what they do. This is the layer most teams buy first, and the most valuable pieces of it are usually not bought at all. They get rebuilt from business logic the enterprise already has running inside its existing applications.
Existing Software Logic Becomes Prompts and Skills
Enterprise software already encodes years of validated business logic, and that logic converts directly into agent architecture. An internal chat interface over the enterprise's own data is a useful on-ramp, because it becomes the framework for the task agents that follow.
From there the pattern extends. A risk platform gets an agent per major function, a KYC agent and a credit check agent, with sub-agents handling individual subtasks. The agents are built to mimic the workflow the software already performed, so the software's logic becomes the prompt and its discrete steps become skills:
Building this way means the agent inherits checks and balances the software spent years accumulating, instead of an engineer reconstructing them from memory in a prompt.
Monitoring Is What Catches an Agent Breaking Its Own Rules
A shared tools library with rigid rules embedded, which every internal builder is required to call, is the right starting control, but it isn't sufficient on its own. Agents break those rules over time, neither maliciously nor predictably, which is why the control has to be behavioral rather than declarative. Monitoring answers what the rules can't: whether an agent actually followed the steps it was designed to follow. That check is what surfaces drift before it reaches a customer decision.
Multi-Agent Handoffs Need Verification at the Seam
Complex workflows rarely run on a single agent. One agent finishes a task and passes the result to the next, and increasingly that next agent belongs to a different vendor or a different company entirely. Two things need verifying at that handoff.
The first is entity continuity: the receiving agent needs to confirm it's still operating on the same entity. A verification service acts as the digital handshake at that seam, which matters most when the handoff crosses a company boundary.
The second is agent identity: when a workflow reaches a third-party agent operated by a counterparty, that agent's claim about which business it belongs to needs verifying before work proceeds.
Agent-to-agent reliability has to be established rather than assumed, and it's the gap most multi-agent deployments haven't closed.
Small Models Cut Cost and Raise Accuracy
Token cost is where agentic ambition meets the budget. Small language models deployed across at least seven use cases produced token cost reductions of 95% to 97% on some of those tasks, with accuracy improving alongside the savings, because a focused model handling a narrow step outperforms a general one asked to do everything.
Commercial underwriting illustrates the point. A landscaping company applying for workers' compensation self-reports that it cuts grass, and the industry codes confirm it as landscaping. Small models extract and filter information across the company's website and other sources, a large model synthesizes what they surface, and the result reveals the company also does tree pruning, which carries a materially different premium.
A second lever has nothing to do with model size. Financial stability scores, verified corporate hierarchies, and supply chain analytics are answers that already exist. Retrieving one instead of having an agent scrape the web, work out which companies are related, and assemble the assessment itself can produce significant token savings.
Durable Advantage Sits Below the Model
Model capability is converging, which pushes advantage down onto the layers underneath it. Three of those layers have durable value.
Asked where an enterprise just starting this journey should begin, Gary's answer follows a specific order: get the governance framework in place, then get the data foundation right, then bring in the tools to scale. Skipping ahead to tools before the data and governance work is done is how enterprises end up automating decisions they can't actually stand behind.
Within a few years, a substantial share of business-to-business interaction will run agent to agent, with no reliable way to tell whether the party on the other side is a person or a system. Those agents will need the same controls and monitoring an enterprise would put people in the same roles.
Enterprises evaluating their own agentic AI roadmap can start with the same question D&B asked itself: can every answer an agent produces be traced back to where it came from? If the answer is no, that's the gap to close before adding more agents, not after.
This post draws on a conversation with Gary Kotovets, Chief Data and Analytics Officer at Dun & Bradstreet, from Fiddler's AI Explained AMA series. Watch AI Explained webinars on demand.