Something important changes when intent becomes the front door to software. If a banker, underwriter, advisor, claims lead, or merchant-risk analyst can ask for a task-specific application and receive it in minutes, then bespoke software stops being rare. It becomes cheap. The expensive thing is no longer the application layer. The expensive thing is the interface to truth: the boundary where customer data, authorization, business policy, and systems of record meet.
That shift deserves a different architectural response. I like to frame a data product as reusable, trustworthy, contract-driven, loosely coupled asset with clear ownership, explicit promises about freshness and meaning, and a versioned surface consumers can rely on. The data mesh tradition adds domain ownership, self-serve platform capability, and federated computational governance. My ingest-transform-surface model sharpens the picture further: inputs are explicit, transformation is deliberate, and the published surface is the contract. All of that is right. It just is not enough once agents and intent-driven tools begin to mediate real work.
Domain APIs need to become the front door for fit-for-purpose apps, and the mesh becomes the process glue that turns operational data into analyzable insight and analytical insight into operational action. My argument is that we should now make that shift explicit. The next mesh should be built from Action-Oriented Data Products: domain-owned data products whose interfaces declare not only what can be read and analyzed, but what can be done, by whom, for what purpose, with which guardrails, and against which authoritative source.
This is not a new name for old API management. It is a claim about the next architectural quantum. Data mesh already argued that the data product is the quantum of the analytical estate. In an intent-mediated world, that quantum must become action-oriented. The mesh stays. The node changes. To make that case, I want to do three things: show why current data products stop short, explain the historical parallels to object orientation, microservices, and data mesh, and define the architecture that lets agents discover and manipulate data safely.
Why the historical parallels matter
The easiest way to justify the idea is to look backward.
Object-oriented programming made one important promise: internal state could be hidden behind public methods and interfaces. Consumers depended on the contract, not on the internal representation. That was powerful because it reduced coupling and made change survivable. Microservices took a related idea across network boundaries: small, independently deployable services organized around business capabilities, communicating through lightweight APIs rather than shared code or shared databases. And at scale, microservices learned another lesson: discovery logic does not belong in every consumer. It belongs in a service catalog that acts as a source of truth for what exists and where it lives.
Data mesh applied those lessons to data. Deghani’s original formulation is still the clearest: domain-oriented decentralized ownership, data as a product, self-serve platform, and federated computational governance. Just as important, the logical architecture already suggests a blended boundary, where a domain’s interface includes both operational capabilities and analytical data endpoints. That is the bridge to the next step. Action-Oriented Data Products do not reject data mesh. They finish an implication that was already there.
But the parallels only help if we understand their limits. OOP assumed a program boundary. Microservices assumed explicitly managed network contracts. Data mesh focused primarily on analytical usability. In an agentic estate, the volatile thing is not the domain product. The volatile thing is the generated assistant, the one-off workflow, the thin application spun up for a relationship review, a reserves exception, or a merchant dispute spike. When software becomes disposable, interfaces become institutional. That is why loose coupling matters more, not less. It is also why zero trust becomes the right mental model: protect users, assets, services, and workflows at the resource level rather than assuming trust because something lives inside the right network or inside a newly generated app.
What an Action-Oriented Data Product is
An Action-Oriented Data Product is a reusable, trustworthy, domain-owned data product that exposes both governed data and governed verbs through a stable, contract-driven interface.
That definition is doing more work than it first appears. Governed data means the familiar promises still apply: freshness, meaning, quality, lineage, access control, documentation, versioning, and ownership. Governed verbs means the product interface distinguishes between observing, analyzing, simulating, recommending, drafting, and committing. A generated tool may be allowed to simulate a portfolio rebalance or draft a claims reserve adjustment. That does not mean it may commit either one.
This is the central rule of the architecture: read through the mesh, write through authority.
In practice, that means a derived product can recommend an update, but only the authoritative product may commit one. A household exposure product may infer concentration risk across accounts. It may even propose a rebalance draft. But it should not directly overwrite custodian holdings, suitability records, or discretionary model assignments. Those mutations belong to the product that owns that truth. The registry must know that. The contract must know that. The agent must not guess. That is also consistent with data mesh’s own inversion of responsibility: accountability moves upstream, as close to the source as possible. In an action-oriented mesh, mutation authority should do the same.
That is where this idea goes beyond ordinary cataloging. Existing API-description and inventory patterns are good at discoverability. They are not designed to carry authority maps, skill requirements, or approval logic for agentic action. An Action-Oriented Data Product must tell you what is authoritative, what is derived, what may be proposed, what may be committed, what skills are mandatory, and what human intent is required. That is a materially richer interface.
The architecture the new mesh needs
Inside each domain node, our pattern still holds. Data is ingested through explicit boundaries, transformed deliberately, and surfaced through a versioned contract that people and systems can rely on. What changes is the surface itself. It now has three declared faces.
The first face is the resource face: the governed data surface. This is where entities, metrics, documents, schemas, features, and semantic views live. The second face is the tool face: invocable operations such as simulate, explain, reconcile, draft, submit, or commit. The third face is the prompt or workflow face: explicitly user-controlled interactions for sensitive tasks that should require direct human initiation. Today’s MCP primitives already provide a useful analogy here. Resources expose context, tools expose invocable actions, and prompts expose structured, user-selected workflows. That mapping is not the whole solution, but it is the right shape.
Around that surface sits a policy and skill envelope. This is where most enterprises are currently too hand-wavy. Business policy, good operating practice, guardrails, and even core concepts need to be built as skills, not left as PDFs, wiki pages, or half-remembered tribal rules. The current MCP ecosystem already uses skills as portable instruction sets for AI assistants. The enterprise version needs to go further: each skill should have an owner, a version, declared inputs and outputs, dependencies, tests, and an audit trail.
A simple taxonomy is enough. Concept skills define what business terms mean: household, exposure, beneficiary, written premium, chargeback velocity. Policy skills answer whether an action is permissible: consent, suitability, jurisdiction, retention, delegated authority, segregation of duties. Practice skills encode the right way to do the work: lineage checks, reconciliation, evidence assembly, exception routing, and fallback behavior. Guardrail skills define the limits: thresholds, masking, reason capture, four-eyes approval, and rollback requirements. Every action endpoint declares required skills that must pass before execution and optional skills that may enrich the result. A skill without versioning and enforcement is documentation. A skill with versioning, tests, and runtime invocation becomes architecture.
Above the products sits the registry plane. Here, the lesson from API management and service discovery is straightforward. Mature API programs separate design-time inventory and governance from runtime mediation. Azure API Center is explicitly about centralized discovery and governance, while runtime gateway concerns live elsewhere. OpenAPI exists because both humans and machines need a formal interface description that removes guesswork. Service discovery systems such as Consul centralize the record of what exists so applications do not hardcode their own discovery logic. The same separation is overdue for data products that agents can act through.
So each Action-Oriented Data Product should publish a machine-readable Product Card. Borrow the lesson from MCP’s registry model and Server Cards, not necessarily the whole protocol. The official MCP Registry, still in preview, is already a centralized metadata repository with discovery APIs and standardized metadata; its roadmap pushes further toward well-known server metadata that clients can discover before connecting. The public registry is for public servers, but the same interface pattern can be implemented privately, which is exactly what enterprises need for internal products. A Product Card should register the product’s owner, domain, version, entities, schemas, endpoints, native agents, freshness and availability promises, required and optional skills, auth scopes, approval modes, and—most importantly—its authority map: what it is authoritative for, what it derives from, where it may propose updates, and where it may commit them.
Then there is the trust plane. This is where many agent demos quietly become dangerous. Authorization cannot live as tribal configuration inside each assistant. Current MCP authorization guidance is useful precisely because it treats auth discovery as machine-readable metadata, grounded in OAuth 2.1, dynamic client registration, and protected resource metadata. Whether an enterprise uses MCP directly or not, the architectural principle is sound: clients should discover scopes, authorization servers, and resource requirements in a structured way rather than inherit ambient trust. Every sensitive operation should carry a structured intent envelope that records actor, business purpose, requested verb, target entity, requested autonomy level, and approval evidence. Intent should be captured as data, not left to inference from a chat transcript.
Finally, there is the execution and proof plane. Each product may expose native agents, but those agents should behave like domain stewards, not sovereign actors. Their job is to interpret local semantics, ask for missing information, and translate business intent into safe options under product-local policy. They can explain, simulate, recommend, and draft. They do not get to tunnel around the contract. This is also where the semantic layer matters. EduDataSci’s recent ontology work makes a sharp point: agents often fail not because data is absent, but because meaning is absent. Action-Oriented Data Products therefore need concept bindings and native semantics as much as they need endpoints.
How the flow works
In practice, the execution model is simple even if the platform underneath is not.
- A human or agent submits structured intent: purpose, target, requested action, and requested autonomy.
- The registry returns candidate products and their Product Cards.
- The orchestrator resolves required skills, authorization, and human-approval requirements.
- Non-authoritative products may enrich, explain, simulate, or draft; the authoritative product decides whether a commit path is available.
- The system records lineage, skill versions, approvals, outputs, and post-action events for audit and learning.
That sequence sounds obvious, which is exactly the point. The architecture should make the safe path the easy path.
Why this matters so much in financial services
Financial services is where the need becomes hardest to ignore, because the cost of a wrong action is rarely limited to a broken dashboard.
In wealth management, imagine a household exposure product that unifies accounts, legal entities, outside holdings, tax lots, and concentration logic. In today’s world, that product often stops at analysis. In the Action-Oriented version, it can also simulate a rebalance, explain the trade-off, draft an advisor note, and submit a proposed model change. But the commit does not happen there. The authoritative product is the portfolio management or advisory system-of-record interface. Required skills might include household resolution, suitability, restricted list checks, discretion status, and reason capture. Optional skills might add peer benchmarks or narrative explanation. The generated advisor workflow can change daily. The authority path cannot.
In lending, a covenant-monitoring product might detect a breach from borrower financials, payment behavior, and collateral refreshes. That product can assemble evidence, score materiality, and draft a watchlist recommendation. It should not directly update servicing status, risk rating, or legal notice state unless it is authoritative for those changes. Those writes must route through the product that owns the credit truth. A well-built Product Card makes that visible before an agent ever tries to act.
In credit card processing, the case is even sharper. A merchant-risk product might correlate chargebacks, settlement anomalies, device patterns, and velocity spikes to propose a step-up control, reserve hold, or review queue escalation. Because the action sits so close to money movement, the product’s action surface needs fine-grained approval modes, purpose restrictions, and short-lived authorizations. Similar patterns hold in life insurance, property and casualty, and reinsurance. A product may draft a beneficiary review, reserve adjustment, catastrophe-throttle recommendation, or delegated-authority escalation. Only the authoritative product should commit it.
This is not merely good engineering hygiene. In banking, BCBS 239 remains a foundational framework for data and risk management, and the Basel Committee’s recent implementation discussion explicitly calls out governance, data lineage, and the effect of emerging technology on risk data aggregation. The original principles are also strikingly relevant to this new world: strong governance, confidentiality, integrity, availability, integrated taxonomies, ownership roles, and accurate, reliable reporting. The Federal Reserve, OCC, and FDIC’s 2026 model risk guidance update makes the same broader point from a model perspective: advances in modeling change the operating context, and model risk management has to be adapted in a risk-based way. Action-Oriented Data Products are one practical way to embody that adaptation.
What makes this new
Existing enterprise controls are fragmented. API inventories and descriptions help teams discover and understand endpoints. Service registries help clients find running services. Those are important patterns, and they are mature ones. But none of them, on their own, tell an agent what is authoritative, what skills are mandatory, what human approval is required, or whether an operation may recommend versus commit.
That is why Action-Oriented Data Products are worth naming. They give us a new unit of architecture for a world where software is easy to synthesize and hard to trust. The durable artifact is no longer the screen or even the workflow. It is the domain-owned, policy-aware, authority-aware interface to data and action.
Conclusion
The best way to think about the next data mesh is not as a larger lake, a smarter catalog, or an API layer draped over existing systems. It is as a network of domain products that can be safely discovered, understood, analyzed, and acted through.
That means keeping the best of what EduDataSci has already argued: products over ponds, named ownership, explicit promises, ingest-transform-surface, and loose coupling. It means keeping the best of data mesh: domain ownership, data as product, self-serve platform, and computational governance. And it means adding what an agentic, intent-driven world now demands: Product Cards, skills registries, native agents, authority maps, structured intent, and a hard separation between recommendation and authoritative mutation.
Build products, not ponds. But in this next phase, build products that know how to act without breaking trust. Start with one high-value decision loop, one authoritative write-back path, and one skill chain you would be comfortable defending to a regulator, an auditor, and your own operations team. If the interface can survive that standard, it can probably survive the agentic future.
