When software can be generated for a person, a task, or a moment, the durable architecture must move out of the application and into the interface to data and action.
A wealth advisor finishes a client call and asks an agent to build a small application.
The application should assemble the household’s accounts, identify securities that could raise $75,000, preserve the client’s income targets, avoid restricted positions, estimate tax consequences, and prepare an explanation for the client. It is not intended to become the next enterprise advisor platform. It may only be needed for the next hour.
The software could be generated almost immediately. That is the appealing part.
The dangerous part is everything the software must touch.
It needs market information, client preferences, account positions, tax lots, suitability rules, firm policies, trading restrictions, approval thresholds, and access to an order-management system. It must know which information belongs to the client, which belongs to the firm, and which comes from public or commercial sources. It must distinguish between calculating a proposed trade and submitting one. It must preserve evidence of what it read, why it made a recommendation, who approved it, and what eventually changed.
The application may be disposable. Its authority cannot be.
This is the architectural problem hiding underneath intent-driven computing and enterprise vibe coding. As software becomes easier to generate, more of the burden moves onto the interfaces through which that software reaches data, policy, and operational systems. We cannot make every dynamically generated application trustworthy in the same way that we certify a major enterprise platform. We can, however, force every application to operate through trustworthy products.
That is the purpose of the Action-Oriented Data Product, or AODP.
An AODP is a reusable, domain-owned product that exposes governed data and governed actions through a secure, discoverable, contract-driven interface. AODPs can exist in public, private, and personal spaces. Connected through a mesh, they provide the durable substrate underneath people, agents, and software assembled for individual tasks.
The internet built around pages and applications does not disappear. It gains another layer: an internet of governed data and action.
Software Is Becoming Temporary. Interfaces Cannot Be.
We have consistently treated a data product as something more substantial than a table, dashboard, or shared folder. A data product is a reusable and trustworthy capability with an owner, a purpose, a contract, and a stable interface. More recently, I described the product as the operator rather than the artifact: the governed transformation, policy, quality, lineage, and promises that continue to exist even when a particular storage or presentation technology changes. See What Is a Data Product?.
AODPs extend that definition from data consumption into controlled action.
A traditional data product might publish account positions, claims history, merchant activity, or loan exposure. An Action-Oriented Data Product can also expose bounded verbs:
- Query the current state.
- Analyze or explain it.
- Simulate a proposed change.
- Draft an action.
- Submit that action for approval.
- Commit an authorized change.
Those verbs do not all carry the same authority. A product may permit hundreds of users and agents to analyze a position while allowing only one tightly controlled interface to change it.
That distinction becomes essential when the software calling the interface may have been generated five minutes ago.
There is a clear historical progression here.
Object-oriented programming placed state and the behavior that manipulates it behind an interface. The internal representation could change without requiring every consumer to change with it. Microservices carried a related idea across a network, organizing independently deployable services around business capabilities and exposing those capabilities through lightweight interfaces. Data mesh then applied domain ownership and product thinking to analytical data, combining decentralized ownership with self-service infrastructure and federated computational governance. See Martin Fowler’s discussion of self encapsulation and the principles of data mesh.
AODPs do not replace any of these patterns. They carry their most useful lesson into an agentic environment:
Consumers should depend on a governed interface, not on the internal implementation or unrestricted access to its state.
The difference is that the consumer may now be a human, an agent, or an application written by an agent for one specific task.
Three Kinds of AODP Form the Next Internet
Public, private, and personal AODPs are not three deployment tiers. They represent three different kinds of ownership, authority, and trust.
Together, they create a mesh in which an agent can discover what information and actions exist without assuming that everything belongs to the same organization—or that access to one product implies access to another.
Public AODPs
Public AODPs expose data or capabilities intended for broad discovery and use under published rules.
They might provide public records, regulatory filings, reference data, standards, geographic information, market calendars, weather, transportation schedules, or economic statistics. Commercial providers could also publish broadly discoverable AODPs whose use requires a subscription, license, or transactional payment.
“Public” does not have to mean anonymous, unrestricted, or free. It means that the product is designed to be discovered outside a private organizational boundary.
A public market-reference AODP, for example, could expose security identifiers, exchange calendars, corporate actions, and reference prices. Its contract would define permitted uses, timeliness, licensing requirements, data quality, and the actions available through the product. An agent could discover it and understand its capabilities before receiving permission to invoke it.
Private AODPs
Private AODPs form the governed operating surface of a company, government agency, school system, nonprofit, or other institution.
In financial services, these products would naturally align to domains and subdomains:
- Customer, household, identity, and consent
- Account, position, transaction, and ledger
- Loan, collateral, covenant, and servicing
- Policy, coverage, claim, reserve, and payment
- Merchant, authorization, clearing, and dispute
- Counterparty, exposure, limit, and settlement
The AODP does not necessarily replace the operational system behind it. A customer AODP may sit in front of a CRM, customer master, document platform, identity provider, and several legacy databases. A claims AODP may connect to policy administration, claims processing, payment, repair-network, and fraud systems.
The AODP gives those systems a stable product boundary. Consumers do not need to know which mainframe transaction, database procedure, SaaS API, or file exchange performs the work. They need to know what the product owns, what it can do, what contract it offers, and under what authority it operates.
Personal AODPs
Personal AODPs establish a similar boundary around the individual.
A personal product could represent identity, credentials, preferences, consent, documents, communication choices, delegated authority, financial objectives, or other information the person controls. It could run on a device, through a trusted provider, in a personal cloud, or across several services. The architectural point is not where every byte is stored. It is that the person has a defined product boundary through which access and action are negotiated.
This idea has precedents. The Solid project uses personal online data stores that allow people to control which applications and agents can read or edit their information through interoperable standards. A personal AODP goes further by adding declared actions, skills, policies, authority, and audit to that personal data boundary.
A personal AODP might tell an advisor’s agent:
- The client has authorized access to selected tax documents for this task.
- The client prefers to preserve municipal-bond income.
- The client has not authorized the firm to share the documents with an external model.
- The permission expires when the proposed plan is delivered.
- Any transaction still requires explicit client confirmation.
That is much more useful than copying personal information into another application and hoping the application handles it correctly.
What Must Live Inside an Action-Oriented Data Product
An AODP cannot be an ordinary API with a better catalog description. Its interface has to carry enough information and control to support software that was not known when the product was designed.
That requires several layers.
The Product Interface
The visible surface of the product exposes its data and capabilities.
This may include governed tables, semantic entities, documents, metrics, events, streams, query endpoints, action endpoints, and native domain agents. The product contract describes schemas, meaning, freshness, ownership, quality expectations, versioning, service levels, and dependencies.
Machine-readable interface standards already demonstrate part of this pattern. OpenAPI allows humans and software to understand the capabilities of an HTTP service without reading its source code or reverse-engineering network traffic. An AODP product card needs to do the same for data, action, authority, and policy.
The AAA Layer
Every AODP needs built-in authentication, authorization, and accounting.
Authentication establishes who or what is calling. That identity may represent a person, an enterprise agent, an agentically generated application, a service account, or a delegated combination of them.
Authorization determines what that caller can do. It should consider more than a static role. The decision may depend on the represented person, business purpose, requested action, product state, jurisdiction, time, device, risk level, and whether human approval has been supplied.
Accounting records what was requested, what was allowed, what was attempted, and what changed. In this context, accounting is not a financial ledger. It is the nonrepudiable operating record required to reconstruct the action.
MCP provides a useful current reference point. Its authorization model treats a protected server as a resource server, uses structured authorization metadata, and allows clients to discover the authorization services and scopes associated with protected resources. AODPs need that kind of discoverable authorization, extended to business purpose, domain authority, and action-level controls. See the Model Context Protocol authorization specification.
Policy, Skills, and Guardrails
Policies cannot remain documents that developers are expected to remember while generating an application.
They need to become executable inputs to the task.
AODPs should declare the skills required to use particular data or actions. A skill might represent a business concept, policy, operating practice, calculation, evidence standard, or control procedure. Some skills are mandatory. Others are optional enhancements.
A cash-raising action might require suitability, account-restriction, tax-lot, trading-authority, and best-execution skills. A narrative-explanation skill may be optional. A reserve-adjustment action may require coverage interpretation, payment-authority, fraud-screening, and supervisory-approval skills.
Current Agent Skills work describes skills as portable instruction sets that provide agents with specialized domain knowledge and workflows. The AODP model extends that idea into an enterprise registry where skills are versioned, owned, tested, and declared as required or optional dependencies of product actions. See Build with Agent Skills.
Auditing and Control
AAA identifies and authorizes the transaction. The auditing and control plane governs its complete lifecycle.
That includes lineage, quality evidence, policy evaluations, approvals, generated artifacts, execution logs, changes to systems of record, monitoring, anomaly detection, retention, legal hold, and rollback or compensating actions.
Auditing answers, “What happened, and can we prove it?”
Control answers, “What is allowed to happen, and how do we constrain it before or while it happens?”
Both belong with the product. A temporary application cannot be allowed to invent its own interpretation of either.
This is also where zero-trust architecture becomes directly applicable. NIST’s Zero Trust Architecture moves trust away from network location and toward individual users, assets, services, workflows, and resources. In an AODP estate, the generated application receives no implicit trust simply because it runs inside the company or was produced by an approved agent. Every product evaluates every material request against identity, purpose, authority, and context.
The Authority Map
The most important metadata in an AODP may be its authority map.
The authority map states:
- Which facts the product is authoritative for
- Which information is derived from upstream products
- Which actions it may simulate or recommend
- Which actions it may submit
- Which systems it may update
- Which product owns the final commit
- Which approvals or skills are required
This produces a simple operating rule:
Read, analyze, simulate, and draft through any authorized AODP. Commit a change only through the AODP authoritative for that change.
A derived household-exposure product may recommend a portfolio adjustment. It should not directly rewrite custody positions. A claims analytics product may recommend a reserve change. It should not bypass the claims product that owns reserve authority. A merchant-risk product may propose a hold. It should not directly alter settlement status unless that action is part of its declared authority.
From Search Engines to Intent Brokers
The existing internet helps users find documents, pages, and applications.
The AODP internet must help agents find trustworthy capabilities.
An agent receiving a task should be able to ask:
- Which products understand the requested business concepts?
- Which product is authoritative for the requested information?
- Which products expose relevant actions?
- Which skills are required?
- What authorization and consent must be obtained?
- Which product can simulate the outcome?
- Which product can commit the final change?
That requires registries.
There may be public registries for broadly available products, private registries for enterprise and partner products, and personal registries or wallets for products controlled by an individual. Registries should describe products but should not become a universal security bypass. Discovery tells the agent that a capability exists. The AODP still decides whether that particular caller may use it.
The official MCP Registry demonstrates the basic discovery pattern by providing a searchable registry of AI-facing servers. The broader MCP architecture also shows how agents can connect to external resources, tools, and workflows through a common protocol. AODP registries would carry a richer product card: domain, ownership, data, actions, native agents, contracts, skill dependencies, authority, authorization metadata, policy requirements, and audit expectations.
This is what makes the model loosely coupled.
The generated application depends on the product card and contract. It does not depend on a particular database, vendor platform, user interface, or implementation. A private AODP can replace a legacy claims system, change its storage engine, or move a process from a mainframe to a service without requiring every agentically created task application to be rebuilt.
The interface endures. The implementation evolves.
What an Ordinary Task Could Look Like
Return to the wealth advisor who needs to raise $75,000 for a client.
The advisor states the intent in ordinary language. The system turns that request into a structured intent envelope containing the user, represented client, purpose, desired outcome, constraints, requested autonomy, and time limit.
The orchestrator discovers several products.
A personal AODP provides the client’s consent, objectives, document permissions, and communication preferences. Public AODPs provide market reference data, trading calendars, and other licensed external information. Private household, account, position, tax-lot, restriction, and suitability AODPs provide the firm’s governed view of the client relationship.
The action requires several skills. Suitability, restricted-position, trading-authority, and tax-lot skills are mandatory. A narrative-composition skill is optional. The orchestrator loads the current approved versions and records them against the task.
Agentically written software assembles the user experience for this particular case. It queries the products, tests several cash-raising strategies, and asks the private portfolio product to simulate the outcomes. The software does not receive direct database credentials. It does not copy every source into an ungoverned workspace. It does not invent its own definition of the household or its own interpretation of trading authority.
The advisor reviews the recommendation. The client approves the selected plan. The authoritative order product submits the trades under its own policy and authorization controls.
The temporary application may then disappear.
The intent, inputs, product versions, skill versions, simulations, approvals, committed actions, and resulting system changes remain fully traceable.
That is what safe daily vibe coding looks like. The application can be improvised because the authority is not.
Computing Changes When Intent Becomes the Interface
The AODP model changes more than application development.
| App-centric computing | Intent-driven AODP computing |
|---|---|
| Find and open the correct application | State the outcome or task |
| Navigate a predetermined workflow | Assemble a workflow around intent |
| Integrations are embedded in the application | Products and actions are discovered through registries |
| Trust is granted to the application | Trust is evaluated at each product interface |
| Permissions are often role- and application-based | Authority is identity-, purpose-, action-, and context-based |
| Data is copied into the application’s working model | Products are invoked through governed contracts |
| Application logs provide partial evidence | End-to-end intent, policy, lineage, and action are recorded |
| The application is the durable asset | The product contract and authority boundary are the durable assets |
Search becomes product discovery. Software becomes thinner and more disposable. Orchestration becomes a first-class computing function rather than integration plumbing.
Security moves from the screen to the interface. A polished enterprise user interface is no longer evidence that an operation is safe, and an improvised interface is no longer automatically unsafe. Safety comes from the AODPs through which the software must operate.
Personal data also becomes an active participant in computing. Instead of repeatedly copying identity, preferences, consent, and credentials into every provider’s application, a personal AODP can participate directly in the transaction and disclose only what the task requires.
Most importantly, the single source of truth becomes an active authority rather than merely the preferred place to run a query. An authoritative product does not just contain the accepted answer. It owns the controlled method for changing that answer.
This Is Not a Universal Agent Free-for-All
An AODP internet does not mean exposing every database to every model.
It does not mean that every API qualifies as a product. A product needs ownership, purpose, quality, a contract, policy, support expectations, and an explicit authority boundary.
It does not mean centralizing all enterprise and personal data in one enormous platform. The point of the mesh is to allow products to remain domain-owned while still being interoperable.
It also does not eliminate systems of record. It gives them a safer and more adaptable operating boundary. A core banking platform, policy administration system, claims engine, card processor, or custody platform can remain authoritative while an AODP provides the product interface through which new agents and applications interact with it.
Finally, it does not make governance optional. It makes governance executable.
The user experience may be fluid. Underneath it, the architecture must be highly structured. That is the same principle behind policy-driven computing: intent should guide the task, but policy, entitlement, evidence, and approval must govern execution. See From Programs to Purpose: The Policy-Driven Future of Computing.
The Durable Internet Underneath Disposable Software
The first internet connected computers.
The web connected documents and applications.
An intent-driven internet will need to connect people, agents, data, policy, and action.
Public AODPs can expose broadly discoverable resources. Private AODPs can provide the governed operating boundaries of institutions. Personal AODPs can let individuals bring identity, preferences, consent, and authority into the interaction without surrendering them to every application involved.
The software between those products may be generated for one employee, one customer, one task, or one moment. That does not have to make computing less safe. It only becomes less safe when the generated software is allowed to carry authority that should belong to a durable interface.
That is the central argument of the AODP model:
Software can be disposable when data products are trustworthy.
The practical place to begin is not with a universal registry or an enterprise-wide rewrite. Start with one recurring task that crosses several systems. Identify the authoritative products. Define their data and action surfaces. Publish their contracts. Encode the required skills. Put AAA, policy, auditing, and control at the product boundary. Then allow an agent to assemble the final mile.
When the interface can be trusted, daily work can be vibe coded without turning the enterprise into a collection of unauditable experiments.
