I recently read the Medium article "How Long Until We Call AI Agents Data Products?" It connects closely with the direction we have been taking with the Open Data Products standards family under the Linux Foundation.
The article raises a simple but important question. Once an AI agent has users, ownership, interfaces, quality expectations, observability, governance, feedback loops, and a roadmap, how different is it from a data product?
Many organizations still treat AI agents as a separate class of technology. AI teams build them, connect them to data sources, add controls, and deploy them as applications. The product model often comes later.
That approach starts to weaken when agents move into real business operations. A production agent needs purpose, ownership, measurable outcomes, defined consumers, access rules, quality expectations, lifecycle management, and clear relationships to the data and services it depends on. These are also core concerns of ODPS, which makes the connection between AI agents and data-product thinking increasingly direct.
The Boundary Is Getting Thinner
A simple agent might still be treated as an application feature. It receives a request, calls a model, retrieves information, and returns an answer.
A production agent often goes much further. It might expose an API or MCP interface, serve several user groups, depend on multiple governed data sources, operate under availability targets, carry cost constraints, and follow security policies. Its behavior might change between versions. Someone has to own it, fund it, support it, and measure whether it creates value.
When those characteristics appear together, the agent starts to resemble a managed product rather than an isolated piece of AI functionality.
The original article makes this connection from the AI side. The same shift is visible from the data-product side. Data products are becoming more active. They are no longer limited to exposing tables, files, dashboards, or APIs. A product might expose an AI interface that interprets data, performs reasoning, generates recommendations, or completes tasks for the consumer.
This makes the distinction between "the data product" and "the intelligent application using the data product" less useful in practice. In many cases, both are parts of the same product experience and need to be managed through the same business and governance context.
ODPS Already Describes Much of What an Agent Needs
ODPS was designed to describe a data product as a managed product rather than as a technical asset. The specification covers areas such as product identity, ownership, purpose, access, quality, service levels, support, licensing, pricing, governance, and product strategy. ODPS 4.1 also strengthens the connection between a product and its business objectives.
These same concepts apply naturally to AI agents. An agent needs an owner, a purpose, and defined consumers. It exposes one or more interfaces. It operates under service expectations. It depends on governed resources. It needs measurable performance and business outcomes. It may also need constraints around where it runs, what it can access, and how its outputs are reviewed.
This does not mean every agent should simply be renamed a data product. Agent implementation introduces concerns that traditional data products do not always have, including model configuration, tool use, prompts, memory, reasoning patterns, and execution controls.
The product management layer is still strikingly similar. That matters because organizations do not need a separate management model for every new AI architecture. A shared product model gives teams a common way to describe what is being delivered, who it serves, what it depends on, and why it exists.
The ODPS Family Makes the Connection Stronger
The connection becomes more useful when we move beyond ODPS itself. The Open Data Products standards family separates several forms of context.
ODPS defines the product. ODPC organizes products into catalogs and portfolios. ODPG connects products to use cases, objectives, KPIs, signals, and other relationships. ODPV provides shared terminology. Draft ODPR adds repeatable workflow contracts for people, platforms, and AI agents.
Together, these standards provide a useful structure for enterprise AI. An agent does not exist alone. It belongs to a portfolio, serves particular use cases, contributes to objectives, depends on other products, reacts to signals, uses organizational vocabulary, and participates in workflows.
Those relationships often matter more than the internal model configuration because they explain what the agent is for and how it fits into the wider organization.
Consider a financial risk agent. The model name tells us little about the value of the product. We need to know which decisions it supports, which risk objectives it contributes to, which data products it consumes, who owns those products, what quality levels apply, what key terms mean, which policies constrain its operation, and how performance is measured.
That context is product context. It is also exactly the kind of context AI agents need when operating inside an enterprise.
Two Directions of Agent Readiness
Much of our recent ODPS work has focused on making data products understandable to AI agents. The underlying idea is that AI-ready data alone is not enough. Agents need to understand what a product represents, who owns it, how it should be accessed, what quality expectations apply, which use cases it supports, and which business objectives it contributes to.
This creates one direction of agent readiness: data products become structured so AI agents can understand them.
The Medium article points toward the other direction: AI agents themselves become structured products with ownership, interfaces, governance, lifecycle, quality expectations, and measurable value.
These two directions meet naturally. An AI agent consumes products described through structured product context, while the agent itself also needs enough product context to be understood, governed, measured, and managed. That is why AI increases the relevance of product standards rather than reducing it.
The Agent Is Part of a Product System
The useful question is not whether every agent should be classified as a data product. The more useful question is whether agents should be managed with the same product discipline.
For many production agents, the answer is increasingly yes. Their value rarely comes from the model alone. It comes from the combination of trusted data, business context, interfaces, workflows, governance, and measurable outcomes. If those parts are managed separately, the result becomes difficult to understand and even harder to scale.
A product-oriented standards model gives those parts a common structure.
ODPS describes the product. ODPC places it in a catalog. ODPG explains its relationships and business context. ODPV keeps terminology aligned. ODPR describes repeatable execution patterns.
Together, they provide a way to represent both the products that agents consume and the environment in which those agents operate.
A Practical Learning Path
If you want to explore this from a practical angle, my Udemy masterclass "Scalable Data Product Value Management with Agent-Ready SDK" goes into the same territory.
The course focuses on how data products move from documentation into machine-readable, agent-ready assets. It also shows how the Open Data Products SDK supports portfolio building, context graphs, workflows, validation, and AI-assisted product operations.
It is designed for people who want to understand both the product-management side and the technical structures needed when AI agents start consuming and operating around data products.
AI Increases the Need for Product Thinking
AI has made technical experimentation easier, but production readiness has not become easier at the same pace. Organizations still need to answer questions about ownership, quality, provenance, access, risk, cost, support, and value. They often need to answer them earlier than before.
This is why the question raised in the original article is timely. We might not need to call every AI agent a data product. But once an agent has consumers, ownership, dependencies, service expectations, governance, and measurable outcomes, treating it as a product becomes difficult to avoid.
From that perspective, the connection to ODPS is direct. ODPS and the wider Open Data Products family give teams a practical way to describe agents and data products through shared product context, instead of managing each new AI capability as an isolated technical experiment.
