Here is a question that sounds pedantic until you try to answer it in production: what is your AI application?
Not what does it do. What is it, as an object your organization can point at? Most platforms will happily host your code and give you a URL. That is hosting. It is not the same as having an application the enterprise owns.
The endpoint answer, and why it runs out
On many platforms the honest answer is: your application is some code, behind an endpoint, in a project, in a subscription. That works fine for one application. Then you have a dozen, and the questions start arriving.
- Which version of the customer-support assistant is running in production right now?
- Which of these seventeen endpoints belong to it?
- Who owns it, now that the team that built it has been reorganised?
- What does it cost, as a business capability rather than as a sum of resource line items?
- How do we retire it without breaking the three things quietly calling it?
None of these can be answered by an endpoint, because an endpoint is a network address, not a lifecycle object. Teams end up answering them in spreadsheets, wikis, and naming conventions -- which is to say, not answering them.
Making the application a first-class object
We recently landed a coordinated change across the platform to fix exactly this: the application became a managed object rather than a deployment convention. That work touched the admin service, the entity service, the API gateway, the CLI, the SDK, and the Helm layer, because making something first-class means every layer has to agree it exists.
Concretely, an application now has:
Its own identity
Projected consistently across services, so telemetry, entitlements, data access, and audit records can all name the same thing. This is what makes "what did the support assistant cost last month" a question with an answer, rather than a reconciliation exercise.
A durable lifecycle
Created, deployed, promoted, and retired as a unit, through the CLI or the Console. Not a folder of manifests that happen to be applied together.
Reconciled endpoints
The gateway resolves an application's endpoints from its declared state, rather than each team wiring routes by hand and hoping the staging config matches production.
Environments as first-class too
Development, staging, and production are properties of the application, so promotion is a supported operation rather than a careful re-run of the deployment steps with different values.
Why this is a governance feature, not a convenience
It is tempting to file this under developer experience. It is really an ownership feature.
Every governance question ultimately needs a subject and an object. "Who may use this?" needs a this. "What did this cost?" needs a this. "Who approved the change to this?" needs a this. If your application exists only as a scattering of cloud resources that a team knows how to interpret, then the enterprise cannot express policy about it, cannot attribute cost to it, and cannot hold anyone accountable for it in a way that survives the team.
A prototyping platform does not need this, and it is not a criticism to say so. A platform whose job is to get you to a working demo quickly is right to treat the application as "whatever you deployed." The requirement appears at the point where the enterprise, rather than the team, has to own the result.
The test
When evaluating any AI platform, ask what an application is in its model, and listen for whether the answer is a noun in the product or a convention in your team's head. If it is the second, that convention is now something you maintain.
This is one of five questions we think separate an operating environment from a development platform. The others are in What Each Enterprise AI Product Is Actually Selling.