What changed: Enterprises building agentic AI systems are finding that model capability isn't the bottleneck, it's data verification. The shift from models that assist to agents that act has exposed a fundamental gap: most organizations lack the infrastructure to verify the data their agents retrieve before making decisions.
According to Gary Kotovets, Chief Data and Analytics Officer at Dun & Bradstreet, the issue isn't what a model was trained on. It's whether you can verify what the model retrieves when it needs to answer a specific question about a customer, transaction, or third party.
Key Findings
Verification operates at enterprise scale, not project scale. At a major commercial data provider, data verification requires billions of automated quality checks running continuously across incoming sources. Quality rules are modified as upstream feeds shift, not written once and trusted indefinitely. This isn't a data science problem solved with better prompts; it's an operational infrastructure problem.
Small models deployed with verified data outperform general models on cost and accuracy. Deployment across at least seven use cases produced token cost reductions of 95% to 97%. Accuracy improved alongside the savings. A focused model handling entity extraction from structured sources beats a frontier model asked to reason across unverified web scrapes, and it costs materially less to run at volume.
Agent-to-agent handoffs introduce verification gaps most teams haven't closed. When one agent completes a task and passes the result to another, two things need verifying: entity continuity (are we still operating on the same customer or transaction?) and agent identity (does this agent actually belong to the counterparty it claims?). Multi-agent workflows crossing vendor or company boundaries fail without verification protocols at those seams.
Governance frameworks decide what reaches production before agents get built. A working framework answers three questions for every model and use case: what the model's terms permit, what data privacy and transfer rules require for that workload, and what counts as ethical use. Both the model and the use case get separate reviews before deployment, drawing reviewers from legal, the chief risk officer's organization, technology, and product.
One rule enforces lineage across every workflow. Anything anyone builds has to demonstrate where the answer came from. That requirement rules out architectures that can't explain themselves and makes audit evidence a byproduct of normal operation instead of a separate compliance project.
What This Means for Your Team
If your agents can't trace every answer back to a verified source, you're automating decisions you can't defend. Hallucination stops being an unavoidable model property when the data is ground truth. A wrong answer becomes the model failing to serve what the data already said, which is testable.
The test runs continuously. Any new model, whether open source or a new frontier release, enters a standing qualification pipeline as soon as it appears. Evaluation covers how the model responds across datasets and how it executes as an agent: whether the steps it took were the right ones, not just whether the final answer looked plausible.
Stale data is harder to catch than conflicting sources. 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 current data supports.
Action Items by Priority
1. Establish your governance framework before you scale agent deployment. Define what models and data sources are allowed to reach production. Set review processes for both models and use cases, with clear ownership from legal, risk, technology, and product. This work blocks agent proliferation in a useful way: it prevents teams from building workflows the organization can't actually stand behind.
2. Implement lineage requirements as an architectural constraint. Make "where did this answer come from?" a question every workflow must answer by design. Pair the requirement with a central platform carrying data entitlements and access controls, so the constraint gets enforced by the environment rather than by individual developer diligence.
3. Build verification into agent-to-agent handoffs. When workflows cross vendor or organizational boundaries, verify entity continuity and agent identity at the seam. A verification service acts as the digital handshake. Without it, you're trusting that the receiving agent is operating on the same entity and belongs to the counterparty it claims.
4. Deploy small models against verified data before scaling general models. Start with narrow tasks where you can verify inputs and measure outputs. A focused model handling entity extraction or classification will outperform a general model asked to reason across unverified sources, and you'll cut token costs by 95% or more on those tasks.
5. Convert existing business logic into agent architecture. Your enterprise software already encodes years of validated business rules. That logic converts directly into prompts and skills. A risk platform's KYC workflow becomes a KYC agent with sub-agents handling discrete subtasks. Building this way means the agent inherits checks and balances the software spent years accumulating.
6. Monitor agent behavior, not just agent outputs. Agents break their own rules over time, neither maliciously nor predictably. Monitoring has to answer whether an agent actually followed the steps it was designed to follow. That check surfaces drift before it reaches a customer decision.
Within a few years, a substantial share of business-to-business interaction will run agent to agent. Those agents will need the same controls you'd put on people in the same roles. The question to ask now: can every answer your agents produce be traced back to where it came from? If the answer is no, that's the gap to close before adding more agents.
