A database is responsible for durable storage, query execution, integrity, and availability. It is not responsible for deciding which business users may approve a particular workflow. Nobody finds that surprising, and nobody buys a database expecting otherwise.
Every technology draws a boundary like that. The boundary is not a limitation; it is the product definition. What is unusual about enterprise AI right now is how few buyers read the boundary before signing, and how much work turns out to be sitting just outside it.
Where the lines currently fall
A cloud platform is responsible for infrastructure, managed services, identity controls, networking, policy, and operational tooling. It is not responsible for understanding your organizational model, or for knowing what an application-level action means in your business.
A developer framework is responsible for helping developers compose models, tools, memory, and workflows. Modern ones add deployment, evaluation, and tracing. Their organizing unit is still the application, the agent, or the graph.
A model gateway is responsible for the model call: routing, fallbacks, usage. Everything above the model layer is yours.
An observability product is responsible for the trace. What the trace means in terms of your cost centres and accountable owners is not part of the deal.
Each of these is a reasonable, well-drawn line. The problem is not any individual product. It is that the union of four well-drawn lines has gaps between them, and the gaps are where your team ends up living.
The gaps have names
In practice the space between products fills with work that nobody sold you and nobody supports:
- Reconciling one product's traces against another's identities
- Deciding which employees may invoke which agent, and enforcing it somewhere
- Working out who owns a knowledge base after its author changes teams
- Attributing spend to a business capability rather than a subscription
- Establishing what happens when the failure crosses a vendor boundary
Every one of those is real engineering, and none of it differentiates your business. It is also the work that gets discovered last, usually at the first production incident, audit, or cost dispute.
Moving the boundary deliberately
The interesting question for any capability is not can this be solved with existing services -- it almost always can. It is should every enterprise have to solve this independently?
Take model access. A provider exposes an endpoint and reports consumption for a deployment. That is a well-drawn line. An operating environment can add the enterprise layer above it: routing across approved models, budget-aware quotas, quality-of-service tiers, failover behaviour, application-level cost attribution, and policy expressed in terms of agents and business units. The provider remains essential. What changed is who is responsible for the layer above.
Or observability. Infrastructure monitoring reports resource health; agent observability traces model calls. Neither connects a signal to the business context of the request -- which application initiated it, which agent acted, whether the cost came from the original request or from error recovery, which organizational owner is accountable. Connecting those is a responsibility somebody has to take.
The question to bring to an evaluation
Not "does this product have feature X." Features move; every comparison ages. Ask instead:
Which recurring responsibilities does this product intentionally bring inside its boundary, and which does it leave with me?
Then count what is left with you, honestly, including the parts that feel small. Integration between two products is a responsibility. Deciding a convention that ten teams will follow is a responsibility. Being the escalation path when the failure spans three vendors is a responsibility.
You may well conclude that you want those. Plenty of organizations have the engineering depth to own an operating environment, and a deliberate build is a legitimate strategy. What does not work is inheriting the responsibilities without noticing, then discovering them one incident at a time.