Agents Need Data Products That Know the Business

When I was conceiving Dataplex at Google, I spent a lot of time talking to customers. One thing became clear: there was a disconnect between what the industry was building and what customers actually needed.

We were very good at finding tables, storing files, and moving data through pipelines. Customers needed something more basic and more difficult. They needed to organize assets around a business purpose, know whether the data was good enough to use, move it through stages of readiness, and understand what it meant to the people doing the work.

A field called customer_id is technical metadata. Knowing which customer is legally responsible for an invoice, which entity receives payment, and what to do when those differ is business context. That distinction matters.

At the time, Data Catalog and Dataplex were separate products. Bringing them together was difficult for reasons I am not in a position to discuss. But the customer need was clear to me: a catalog could not remain a separate destination where people went to search for assets. Its context had to travel with the data into the work.

Google subsequently announced a unified Dataplex and Data Catalog experience in 2022.¹² The product has been renamed twice since, to Dataplex Universal Catalog in April 2025 and to Knowledge Catalog this April, and the original Data Catalog service began a phased shutdown on June 1.³⁴ Its current documentation describes data products as curated collections of assets with documentation, contracts, access, and ownership, and the feature went generally available on May 25. It even names AI agents as consumers.⁵⁶ This is encouraging progress. When I recently tried the experience, though, it still felt to me like some pieces had come together more fully than others. That is my observation, not a claim about an internal roadmap.

Seven years to get from a searchable inventory of tables to a first-class object that packages assets around a business problem. I do not say that as criticism. It is a measure of how hard the problem is, and of how much of the industry's energy went into the parts that were easier to build: discovery, indexing, lineage.

Agents make this question urgent again.

Imagine an agent asked to resolve a delayed insurance claim. A search across the enterprise lake may return policy tables, claims histories, scanned forms, repair estimates, fraud signals, state-specific rules, customer emails, and old slide decks. Somewhere in there is what the agent needs.

But finding those assets does not answer the working questions:

• Which policy version applied on the date of loss?
• Is this repair estimate current, or was it superseded?
• What does "complete claim" mean in this line of business and state?
• Who can ask the customer for missing evidence?
• Which discrepancies may an agent resolve, and which must go to an adjuster?
• What evidence must be retained to explain the action later?

Giving an agent broad access to a catalog is like sending a new employee into a warehouse with a map of every box. The map helps. It does not tell them which materials are approved for this job or how to handle an exception.

So I don't think the catalog, as we know it, remains the main thing customers organize around. We will still need discovery, indexing, lineage, and a way to trace an asset back to its source. Those capabilities may sit underneath the product. But the object that a business owner opens, that an agent is assigned to, and that a team measures should be the data product.

I also think our definition of a data product has to grow. A bundle of curated tables with a description and an owner is a useful starting point. For agentic work, it is too passive. The product should represent a use case and everything required to make progress on it: the data, its business meaning, its quality, the work to be done, the decisions involved, and the limits on what an agent can do.

Think about an Invoice to Pay data product. You would not begin with a search result showing twenty invoice tables. You would open the product and see the invoice, purchase order, contract, receiving evidence, vendor identity, payment instructions, and exceptions in their business relationships. You would see which definitions apply, how current each source is, who owns a discrepancy, and what outcome the process is meant to achieve. The agent would be able to ask for missing evidence, reconcile records, prepare an approval, or route a risk it cannot resolve. The work happens in the context of the product.

That means a data product has several connected parts:

• Purpose and outcome. What process is this for, where does it start and end, who owns it, and how do we measure success?
• Assets and relationships. Which tables, documents, events, APIs, and records matter? How do customer, policy, invoice, contract, and payment entities relate? The product points to source systems; it does not require copying every asset into one place.
• Ontology and taxonomy. What are the entities in this process, how are they classified, and how do they relate? A claim has a policy, a policy has endorsements, an endorsement changes a deductible on an effective date. Without this, the agent has a pile of records and no way to know which ones bear on which decision.
• Business meaning. What do "approved," "complete," "active," and "paid" mean here? Which jurisdiction, date, customer segment, or policy version changes the answer? Every important definition needs an owner and an effective date.
• Quality and readiness. Which checks apply at intake, review, approval, and execution? What missing or conflicting evidence stops the next action? A product can move from incomplete to reviewable to ready for a bounded action, with the reason for each transition recorded.
• The agent harness. Which tools and actions are available, under whose authority, with what permissions, limits, and escalation path? What must be cited before an action is proposed or taken? What can be retried, reversed, or never done automatically?
• Learning and accountability. Which exception did a person resolve, why, and what happened afterward? Which lesson is specific to this case, and which proposed change deserves review before it becomes a reusable rule?

Two more things follow from taking the use case seriously, and I think both are underbuilt.

Every data product needs an ontology, and the ontology needs to be a graph the agent can walk. A taxonomy tells you what kinds of things exist in this process and how they are classified: a claim is a property claim or an auto claim; a vendor is an individual, a partnership, or a corporation; an invoice is a PO invoice or a non-PO invoice. An ontology tells you how those things relate and under what conditions: a policy covers a property during a term; an endorsement modifies a policy from an effective date; a purchase order authorizes an invoice up to a tolerance; a bank account belongs to a vendor entity as verified by a process on a date. Today most of this lives in the heads of the people who do the work, in the joins buried in a reporting layer, or in a glossary nobody reads at the moment of decision. For an agent, it has to be explicit and machine-traversable. That is a context graph: the entities of the product, their relationships, the effective dates and jurisdictions that qualify those relationships, and the evidence behind each edge. When the agent asks "which deductible applies to this loss," it should be walking that graph, not guessing at column names. The graph is scoped to the product, or to a collection of related products that share an ontology, so that "customer" in Invoice to Pay and "customer" in Claim Readiness can mean different things without either being wrong.

Data products have to nest. Real processes are built from smaller processes. Invoice to Pay depends on a Vendor Identity product (who is this supplier, which legal entities, which verified bank accounts) and a Contract product (what was agreed, with whom, until when). Invoice to Pay itself sits inside Procure to Pay. Claim Readiness contains a Policy Version product and a Property Identity product, and both of those are reused by Underwriting. If a product cannot include another product, one of two bad things happens: every product copies the same vendor and policy logic and they drift apart, or one giant product tries to hold the whole company and nobody owns it. Composition solves both. The inner product keeps its own owner, quality contract, and permissions; the outer product inherits them and adds its own. The context graph composes the same way, with the inner product's entities and edges appearing in the outer product's graph under the inner product's guarantees. A bank account verified by Vendor Identity is verified for Invoice to Pay too, with the verification date and process carried along as evidence.

Procure to Pay
  contains  Invoice to Pay
              contains  Vendor Identity
              contains  Contract
              contains  Receiving
  contains  Sourcing
              contains  Vendor Identity   (same product, reused)
              contains  Contract          (same product, reused)

Claim Readiness
  contains  Policy Version
  contains  Property Identity
Underwriting
  contains  Policy Version              (same product, reused)
  contains  Property Identity           (same product, reused)

Google's current data product is a flat collection of assets with one owner. Collibra's carries a data contract. Neither, as far as I can tell from the public documentation, lets a product contain another product with its guarantees intact, and neither exposes the product's ontology as something an agent traverses at decision time. Those two capabilities are, in my view, the difference between a data product that distributes data and one that can host work.

I would separate the product definition from each work instance. The Invoice to Pay product defines the trusted context, tests, permissions, and workflow. An individual invoice is an instance moving through it. That keeps the product reusable while preserving the exact evidence, decisions, and actions for every case.

This also changes how we think about metadata. Technical metadata still matters. But business metadata becomes operational: it determines which agent can see a record, which interpretation is valid, and whether the next step is allowed. A definition hidden in a catalog page is documentation. The same definition, applied to an invoice exception at the moment of decision, is part of the work.

The catalog becomes a service underneath and across data products. It discovers assets, records their lineage, and helps a product owner find and govern them. Common assets and definitions can be reused by several products. But each product makes its own promise about fitness for a specific use case. A customer record may be good enough for outreach and insufficient for opening a bank account. There is no useful enterprise-wide "good data" badge that settles both questions.

This is the shift I think we need:

Business use case
  -> living data product
  -> agents doing the work
  -> human interventions
  -> better context, quality, and outcomes
     in that product

This is a proposed operating model, not a claim that any one platform delivers the whole loop today. Google's current definition already packages assets, context, contracts, and access around a business problem.⁵ I think agents will push data products beyond distribution into execution and learning.

For analytics, a quality issue might create a misleading dashboard. For an agent that can act, it may create a wrong payment, a delayed claim, or a bad customer communication.

The analytics-era cost was already large. Gartner's long-standing estimate is that poor data quality costs organizations at least $12.9M a year on average, and that figure predates any agent touching a payment system.⁷ When the consumer of the data is a dashboard, a bad value produces a bad chart that a person may or may not act on. When the consumer is an agent with a tool, the bad value becomes the action.

Quality therefore cannot be an isolated score attached to a table. It has to be evaluated against the action the agent is about to take.

Consider an invoice. Its vendor identifier may be populated, so the completeness check passes. But the vendor's bank account changed yesterday, the purchase order names a different legal entity, and the invoice references a contract that expired last month. Each record may look valid by itself. Together, they are not safe to pay.

How often does that happen? More often than the automation vendors' demos suggest. Ardent Partners' 2025 accounts payable benchmarks put the invoice exception rate at 22% for the average team and 9% for the best-in-class. The same gap shows up in cycle time, 17.4 days against 3.1, and in cost per invoice, $10.89 against $2.78.⁸⁹ Roughly one invoice in five, at a typical company, lands in the messy middle. That is the population an agent will spend most of its time on, and it is exactly the population where "the field is populated" tells you least.

A useful data product needs several kinds of checks:

1. Structural quality: Are required fields present and in the right format?
2. Freshness and lineage: Where did a value come from, when was it last verified, and has it been superseded?
3. Cross-source consistency: Do the contract, invoice, vendor master, and payment instructions agree?
4. Business fitness: Is this data suitable for this decision in this jurisdiction or process stage?
5. Action thresholds: Can the agent proceed, prepare a draft for review, or must it stop and escalate?

Notice that only the first of those is what most data quality tooling measures today. The other four require knowing what the data is for.

Google's Knowledge Catalog supports automated quality rules and scans on supported tables.¹⁰ That is an important foundation. Forrester's Q1 2026 evaluation of data quality vendors describes the category moving the same direction: away from static, rule-based cleaning toward continuous observability, agentic remediation, and validation of documents and images alongside tables.¹¹ The next design step, in my view, is to connect those signals to the specific business action and its risk. A 98% complete dataset might be sufficient for a trend analysis and completely inadequate if the missing 2% contains the claims an agent is about to settle.

Quality is not a property of a table. It is a property of a table, a decision, and a moment.

Most enterprise work does not fail at the first step or the last step. It gets stuck between them.

The order is received but the billing entity is unclear. The policy is active but the endorsement date is disputed. The customer's identity is verified but two records describe different beneficial owners. Someone experienced notices the discrepancy, checks an old email, calls another team, and makes a judgment. The ticket closes. The reasoning disappears.

That is tribal knowledge, and there is a rough measure of how much of the enterprise runs on it. In a Panopto and YouGov survey of employees at companies with more than 200 people, respondents estimated that 42% of the knowledge needed to do their jobs was held by a single colleague and unavailable to anyone else, that they spent 5.3 hours a week waiting for a coworker to supply it, and that a new hire needed about six months to become fully productive, most of it spent hunting for what nobody wrote down.¹² The survey is from 2018 and the numbers are self-reported, so treat them as a shape rather than a measurement. The shape has not changed.

Asking people to fill in more catalog fields will capture some of it, but not enough. People are busy, definitions change, and the useful knowledge often appears only when a real exception occurs.

We should bootstrap context from Confluence, Google Docs, operating procedures, contracts, historical cases, and system events. Google already documents a sample agent that enriches catalog metadata from internal documents, wikis, code, and chat channels.¹³ But extracted content should start as candidate context. A five year old playbook cannot quietly become a current rule because an agent found it in search.

The better loop is to learn at the point of intervention:

• The agent identifies a conflict and shows the evidence it used.
• A qualified human resolves the case and records a short reason.
• The system distinguishes a one-off exception from a reusable rule.
• A process owner reviews proposed changes to definitions, quality checks, or escalation policy.
• The approved change is versioned, linked to its source, and made available to the next agent working on the same use case.

Every resolved exception can improve the product. It can also reveal a broken upstream process. If an agent repeatedly has to ask whether the invoice entity matches the contracting entity, the answer may be a better onboarding check, not a smarter prompt.

Take a property claim after a storm. The customer reports damage and uploads photos. The insurer has the policy and endorsements, previous claims, a catastrophe event feed, a repair estimate, correspondence, and state-specific handling requirements. Some arrive as structured records. Others arrive as PDFs, images, or notes.

Insurers are not waiting for permission to use AI on this. In the NAIC's surveys of state-regulated carriers, 88% of private auto insurers and 70% of homeowners insurers reported using, planning to use, or exploring AI and machine learning models, with claims (image analysis, settlement estimation, fraud detection) among the most common uses.¹⁴ The question is not whether models touch the claim. It is whether the model's inputs know what "policy active on the date of loss" means in this state.

A Claim Readiness data product could bring together the applicable policy version, coverage terms, date-of-loss facts, claimant and property identity, submitted evidence, approved repair estimate sources, relevant handling rules, and a clear record of provenance. It would specify what each field means and what constitutes enough evidence for each next step.

An intake agent could then do real work:

1. Match the reported loss to the active policy and the correct date of coverage.
2. Check whether essential evidence is present and request missing items using an approved communication flow.
3. Compare the reported damage with available photos, estimates, and event information, while marking uncertainty.
4. Prepare a case summary with citations to the underlying evidence.
5. Route coverage ambiguity, suspected fraud, disputed damage, or a consequential decision to the appropriate professional.
6. Track whether the claim advanced, stalled, reopened, or needed rework.

The messy middle is not extracting text from a form. It is deciding what to do when a roof estimate includes damage that predates the storm, an endorsement appears to change the deductible, and the customer has already been told to expect a quick answer. An agent can assemble the evidence, find the conflict, request a missing document, and prepare the next action. A licensed or authorized human handles judgments that require one, under the insurer's rules.

The data product's quality checks must be sensitive to time and context. "Policy active" is not enough; it must be active on the date of loss. An extracted deductible is not reliable if the endorsement that changed it has not been linked. A missing photo can be a request for evidence. A conflicting policy version can be a hard stop.

I would measure this workflow by time to a complete, reviewable claim file; percentage of avoidable back-and-forth; adjuster rework; and error or complaint rates. Straight-through processing alone would be a poor goal if it encouraged weak decisions. The NAIC's model bulletin, adopted in December 2023, puts the responsibility for accuracy, fairness, and human oversight squarely on the insurer, whichever vendor built the model.¹⁴

There is an adjacent underwriting example. A commercial submission includes an application, broker emails, prior loss runs, property schedules, inspection reports, and changing appetite guidelines. An agent can reconcile the entities and locations, ask for missing loss history, identify contradictions, and prepare an underwriter's brief. The underwriter decides whether to quote and on what terms. Each exception teaches the data product what "submission ready" means for that class of risk.

Now consider invoice to pay. Many organizations have automated pieces of it: document capture, approval routing, and payment execution. Three quarters of AP departments already use some form of AI, by Ardent's count.⁸ The difficult work remains between those steps.

A Payable Invoice data product could package the invoice, purchase order, contract, receiving record, vendor master, approved banking details, tax treatment, payment history, approval authority, and documented exceptions. It should explain the business relationships among them. Which legal entity bought the service? Which entity invoiced it? Was the work actually received? Who may approve a price variance?

An agent could match the records, request missing receiving evidence, investigate a duplicate invoice, prepare a variance explanation, and route a bank detail change through a verified approval path. It could also record why a discrepancy was accepted so the next case is easier to handle.

Here is the messy middle: a supplier changes its name after an acquisition. The purchase order uses the old name, the invoice uses the new one, and the remittance details have changed. A simple match fails. A naive agent might either block a legitimate payment or approve a risky one. A useful agent gathers the acquisition documentation, tests entity relationships, flags the bank change, and sends a concise case to the authorized approver. It does not infer that a plausible email is sufficient proof.

The outcome is not "invoices touched by AI." It is fewer payment exceptions per thousand invoices, faster resolution, fewer duplicate or misdirected payments, and less human time spent chasing documents, with a full audit trail.

A second finance example is business customer onboarding at a bank. The relevant product would join applications, customer and beneficial owner records, identity evidence, screening results, entity documents, risk policies, and prior relationship data. An agent can gather missing documents, reconcile name variations, prepare an evidence trail, and queue ambiguous ownership or screening matches for review. It should know which data is verified, which is merely asserted, and which checks must be refreshed before an account is opened.

This is particularly important because financial supervisors identify data quality, privacy, and security as barriers to using AI in core financial work. The BIS Financial Stability Institute's March 2026 paper on AI data use frames those three as the central obstacles, sharpened by dependence on a small number of third-party providers.¹⁵ FINRA's 2026 oversight report states that existing supervision, communications, and recordkeeping obligations continue to apply when firms use generative AI, and that a firm relying on such a tool must address "the integrity, reliability and accuracy of the AI model."¹⁶ The design implication is mine: finance agents need an accountable data and decision trail built into the workflow.

Let me make this concrete with the supplier name change in Invoice to Pay. This is an illustrative design, not a description of a deployed system.

Before work starts, the product owner defines the Invoice to Pay product. Finance owns the business outcome: pay valid invoices on time without duplicate or misdirected payments. Procurement owns the purchase order and contract definitions. Vendor operations owns the approved vendor identity and banking verification process. The product links to source systems, captures the effective versions of policies, and defines which actions an agent may take. It has a separate work record for every invoice. Nobody has to copy the entire finance lake into an agent's prompt.

1. An invoice arrives. An email attachment or supplier portal event creates an invoice work instance. The agent receives access to the Invoice to Pay product and this instance, not open-ended access to every finance system.
2. The product assembles context. It resolves the invoice to the purchase order, contract, receiving record, vendor master, and payment history. The underlying catalog helps locate and trace the assets. The product presents their business relationships and current versions.
3. Quality checks run before reasoning. The invoice has a valid number and amount. The purchase order has budget. The receipt shows delivery. But the invoicing legal name differs from the vendor master, and the bank account was changed yesterday. The product marks the invoice as not ready to pay, recording the failed checks and their sources.
4. The agent works on the exception. It finds a supplier acquisition notice in the contract repository, checks whether the new entity is covered by an approved vendor change, looks for prior duplicate invoices, and prepares a short explanation of what matches and what remains unverified. The acquisition notice is evidence, not automatic authorization to change payment details.
5. The agent takes bounded actions. It can ask the supplier for an approved tax or entity document and ask vendor operations to verify the bank change through its established process. It can draft an approval packet with links to the exact records and dates. It cannot alter the vendor master or release payment.
6. The right human makes the decision. Vendor operations verifies the new bank account through an independent channel. An authorized finance approver confirms the entity relationship and any contract assignment requirement. If the documents conflict, the case goes to procurement or legal. The reviewer sees the evidence, the agent's proposed interpretation, the failed checks, and the action requested, all in one place.
7. The work moves forward. Once the verified records are updated, quality checks rerun. The product moves this invoice from exception to ready for approval. The authorized approval and payment systems perform their usual checks before payment. The agent monitors confirmation and closes the work instance only when the outcome is known.
8. The product learns from the outcome. The team records whether payment was on time, whether it was correct, how much rework occurred, and why the exception was resolved. If this acquisition pattern recurs, the agent proposes a new entity-mapping rule or an intake check. A product owner reviews it before publication. Future agents receive the approved rule with its source and effective date. The individual invoice's audit trail remains intact.

Catalog       finds and traces the evidence
Data product  decides what the evidence means here,
              and whether the work may advance
Agent         gathers, reconciles, communicates,
              prepares the action
Human         verifies the bank change, approves
              the consequential decision
Outcome       feeds back into the product

Notice the roles. The catalog finds and traces the evidence. The data product decides what that evidence means for this process and whether the work is ready to advance. The agent gathers information, communicates, reconciles, and prepares action. Humans handle the bank change and consequential approval. The outcome feeds back into the product. That is the end-to-end loop I would want to buy.

I looked at analyst research, vendor documentation, a customer example, and G2 reviews. These are signals of direction, not proof that the complete model above exists today.

Enterprises are buying agents faster than they are building the harness for them. Gartner's January 2025 poll of 3,412 respondents found 61% had already invested in agentic AI, most of them conservatively. Five months later the same firm predicted that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating cost, unclear business value, and inadequate risk controls, while still forecasting that a third of enterprise applications will include agentic AI by 2028 and that 15% of day-to-day work decisions will be made autonomously.¹⁷ Read those two sets of numbers together. The demand is real, and the failure mode is the absence of exactly the things a data product is supposed to supply: a clear business outcome, a quality bar tied to the action, and a control boundary.

Analysts see data quality moving into agentic work. Forrester's Q1 2026 assessment says data quality tools are expanding beyond rule-based cleaning toward automation, monitoring, and multimodal validation for AI. It stresses governance and visibility across systems.¹¹ That supports the argument for a quality gate at the point of action. Forrester also describes separate planes for building agents, orchestrating work, and controlling agents.¹⁸ My inference is that a use case data product can give those planes a shared business object, while the underlying services may remain separate.

The data product is already becoming a first-class asset in catalogs. Google describes a curated group of assets with documentation, contracts, access groups, and an owner; an AI agent can be a consumer.⁵ Collibra documents a Data Product asset tied to business context and machine-readable data contracts for quality and service levels.¹⁹ Alation has introduced a builder agent that recommends products from a use case and active metadata.²⁰ These are different implementations, but all are moving beyond a flat inventory of tables.

Catalog context is beginning to reach agents. Google documents an agent that enriches metadata from internal documents, wikis, code, and communication channels.¹³ At Atlan's Re:Govern conference last November, Mastercard's data leadership described the progression as "privacy by design, to data by design, to now context by design," with lineage and quality automated and stewards adding the meaning, on the argument that context cannot be bolted on later.²¹ This is evidence that the connection is being built. It is not evidence that those agents own every business workflow or learn a policy from each exception.

Users still feel the gap between finding data and using it. One Alation reviewer on G2 praised curation and business use, while describing manual mapping of glossary terms to fields and documents.²² A Collibra reviewer described how a technical interface and training needs can hinder business adoption.²³ These are individual, self-selected reviews, and some are several years old. They should not be treated as current product audits or market-wide statistics. They illustrate a persistent design challenge: business meaning has to be maintained and brought into the moment of work, not merely stored somewhere people can search.

Even vendors now describe the gap in similar terms. Collibra's March 2026 marketplace announcement says traditional catalogs are built for data experts rather than the analyst in finance or the recruiter in HR, and positions data products as the single curated entry point for business users and AI agents alike.²⁴ That is a vendor's account of its own direction, so I would treat it as a market signal, not independent validation.

The opportunity, as I see it, is to connect these pieces all the way to the outcome. Today's evidence is strongest for product packaging, discovery, governance, and context delivery. My prediction is that the product also becomes the place where agents do bounded work, encounter exceptions, receive human decisions, and improve the next run.

1. The data product will replace the catalog as the main thing users work with. The catalog will continue to discover assets, maintain lineage, and serve context behind the scenes. A business user will open a product such as Claim Readiness to see the work, its evidence, quality, owner, and progress. An agent will receive the product's scoped context and capabilities, rather than roam an enterprise-wide search index. Current catalog work on agent grounding points in this direction, but the product-centered interface is my prediction.²⁵ The tell will be in the vendors' navigation: when the home screen of a catalog is a list of products and outcomes rather than a search box, the shift has happened.
2. Data products will become agent harnesses for decisions and workflows. "Customer 360" may remain useful, but "resolve a claim," "pay an invoice," or "onboard a business customer" gives an agent a clearer job, owner, quality bar, tools, permissions, escalation path, and outcome. The same asset may appear in several products with different permitted uses, and the same product will appear inside several larger ones. If Gartner is right that inadequate risk controls will cancel a large share of agent projects, the harness is where the surviving projects will differ from the canceled ones.
3. Quality will become action aware. Instead of a green badge on a table, quality will be a gate: Can this specific action proceed with these specific records and this level of uncertainty? The answer may differ for summarizing a case, requesting a document, approving a payment, or denying a claim. Expect the data quality vendors Forrester rates on observability to start shipping thresholds expressed in terms of actions, not tables.
4. Exceptions will become the main source of business context. Documents will bootstrap the system. Repeated human interventions will reveal where definitions are missing, records conflict, and policies fail in practice. The winners will turn those interventions into reviewed, reusable context without treating every individual decision as a universal rule. The 22% of invoices that are exceptions today are not a cost to be driven to zero. They are the training set.
5. Agents will take over more of the work between systems. They will collect evidence, reconcile records, chase missing information, prepare decisions, execute bounded actions, and monitor the result. Humans will spend more time on disputed cases, consequential approvals, and improving the process. The measure of progress will be completed work with acceptable quality and controls, not the number of agents deployed.

Working from first principles, the starting point is not a platform or a model. It is one piece of work the business has to finish. I would pick one workflow with a named owner and a measurable backlog. Map every decision from the trigger to the outcome. Identify the few assets and definitions the agent truly needs, write down the entities and relationships as a small graph, and notice which of them already belong to a product someone else should own. Add checks for freshness, consistency, and permission. Let the agent handle a bounded set of actions and route consequential exceptions to the right person. Then study what the interventions teach you.

That is how the catalog, the data product, data quality, and agents come together. The data product is the thing the business owns and the agent works within. The catalog supplies discovery and lineage underneath it. Quality determines whether the next action is safe. Agents move the work forward. Human intervention improves the product.

Years ago, the question was how to make data easier to find and trust. With agents, the sharper question is: can the business put its data to work without losing the meaning, judgment, and accountability that make the work possible?

If you run a claims, payables, or onboarding operation and have tried to put an agent into it, I would like to know which exception it got stuck on first. That is usually where the data product should have started.

The Dataplex history at the top is my recollection of customer conversations, not a statement of Google's plans then or now, and the product observations are from trying the public product as an outside user. The Ardent Partners, Panopto, NAIC, and Gartner figures come from surveys with the usual self-selection and self-reporting caveats, and the Panopto study is from 2018; I use them for their shape, not their decimals. The G2 reviews are individual and some are several years old. Data product availability dates are from Google's public release notes.