Who Will Own the Agentic Stack? The Model Is Only One Control Point

I started with what sounded like a straightforward question: who is going to own the agent platform?

Would it be the companies that own the models? The cloud providers that already run enterprise software? Data platforms such as MongoDB? Or independent tools such as LangGraph?

Once I began comparing them, the question stopped being straightforward. I had grouped together companies that were not starting from the same place or trying to control the same part of the system.

AWS is not a database company in this comparison. It is a cloud platform with compute, identity, networking and operational control. MongoDB is approaching agents from operational data, retrieval and memory. LangGraph is an open-source framework, while LangSmith Deployment is the commercial runtime and management platform around it. Model providers can connect their models directly to tools and execution environments.

They increasingly use the same language: build, deploy, govern and improve agents. But the centre of gravity is different in each offer.

The battle is not simply to own the agent. It is to own the control point that becomes hardest to replace.

An agent platform is several products wearing one label

A production agent needs more than a model and a loop that calls tools. It may need a harness to manage context, an execution environment, durable state, memory, identity, permissions, tool connections, human approval, traces, evaluations and failure recovery.

That creates an immediate problem when comparing platforms. One vendor may call its orchestration library a platform. Another may be selling a managed runtime. A third may be describing a data layer with agent integrations. A feature checklist makes them look interchangeable even when moving between them would involve very different work.

The distinction matters because not every dependency becomes equally sticky. Changing a model endpoint can be relatively contained if the rest of the system is separated cleanly. Moving years of traces, evaluation cases, permissions, stored memories and operational procedures is harder.

This is the production version of an argument I made in keeping AI workflows model-agnostic. Portability does not mean avoiding every useful vendor feature. It means knowing which dependency you have accepted and what it would cost to replace.

Model providers can make their harness the default

Model providers have the shortest route from new model capability to a working agent experience. They can tune the model, tool interface, context management and execution loop together.

OpenAI made that direction explicit with its Agents API in September 2026. The public beta provides the harness used by Codex as a managed service. It handles long sessions, tool use and subagents, while letting developers choose an OpenAI-hosted environment, their own infrastructure or an integrated sandbox provider. The underlying Codex harness is open source, but OpenAI operates the managed service and evolves it alongside its models.

That integration can be a real advantage. When a model gains a new way to manage context or use tools, the provider can expose it without waiting for a general-purpose framework to catch up.

It also changes the lock-in calculation. Your application may call an API, but its behaviour can depend on a provider-specific harness, session model, tool semantics and managed execution environment. Replacing the model no longer means replacing one inference call.

Model-native performance and model portability will often pull in opposite directions.

That does not make model-provider platforms a bad choice. It means the dependency should earn its place through measured improvements on your work, not through the assumption that the model will remain the whole platform.

Cloud providers are competing for the production boundary

If model companies begin with intelligence, cloud providers begin with the environment in which software is already operated.

Amazon Bedrock AgentCore shows how broad that position can become. AWS describes services for a managed agent harness, serverless runtime, memory, tool gateways, identity, browser and code execution, observability, evaluations, policy and a registry. Its runtime supports multiple frameworks and models, including models outside Amazon Bedrock.

The important part is not that AWS has produced a long list of agent features. It is that identity, network access, policies, monitoring and deployment already meet inside the cloud account. For many enterprises, those boundaries decide where production software can run before the team compares agent frameworks.

A cloud provider can therefore be model-agnostic and still create deep platform gravity. The model may change while the runtime, permissions, gateways, traces and operational processes stay where they are.

The cloud's strongest advantage is not orchestration. It is becoming the governed place where every agent is allowed to act.

This is why I think cloud providers are the strongest candidates to own the enterprise agent control plane. That is a judgement about their starting position, not a claim that one cloud has already won. Teams may deliberately choose another control plane for portability, data residency or deployment flexibility.

Data platforms want to own context and memory

Data platforms are making a different argument: an agent is only as useful as the information it can retrieve, the state it can retain and the operational data it can act upon.

MongoDB's May 2026 agent platform announcement combined its operational database with full-text and vector search, persistent memory, embeddings and reranking. Some of the announced capabilities were in public preview, and the announcement is MongoDB's own account of its strategy. It should be read as evidence of where the company wants to compete, not independent proof that one data platform solves every production problem.

The position still makes architectural sense. Agents need current context, durable task state, conversation history and a reliable path to the systems they can change. Keeping those concerns close to operational data may reduce synchronisation work and the number of separate services a team must operate.

But data gravity is not the same as platform ownership. A database can store memory without deciding the agent's control flow. Search can retrieve context without operating the sandbox. A data platform may become essential to an agent while the cloud or model provider still owns its runtime.

My earlier exploration of what retrieval is really doing inside a RAG system led to the same boundary. The vector database matters, but retrieval quality also depends on chunking, ranking, freshness, deletion and evaluation. Calling the database the agent platform can hide those system decisions rather than remove them.

Data platforms have a credible claim on agent state and context, but not automatically on the whole agent lifecycle.

Independent platforms have to own the improvement loop

Independent frameworks initially offered something the model and cloud providers had not standardised: a practical way to express tool-calling loops, stateful graphs and multi-agent workflows across different models.

That layer is now under pressure. Model providers ship their own SDKs and harnesses. Clouds offer managed runtimes that accept popular frameworks. The orchestration primitives that once justified a separate platform are becoming available in several places.

LangChain's own product boundary illustrates the response. LangGraph remains the open-source framework, while LangSmith Deployment supplies managed infrastructure for durable execution, state, streaming, registries and production deployment. LangGraph Platform was renamed LangSmith Deployment in October 2025, and the managed service can deploy agents built with frameworks other than LangGraph.

This is more than a naming detail. It shows where an independent vendor can remain valuable as basic orchestration becomes common. The defensible layer is not merely drawing a graph. It is helping teams trace behaviour across providers, evaluate changes, manage versions, recover failures and improve agents without surrendering the whole system to one model or cloud.

Independent platforms become durable when they make the rest of the stack replaceable.

If they depend entirely on one framework's syntax, the hyperscalers can absorb much of their value. If they become the trusted record of what an agent did and whether a new version is better, they control a much more consequential part of production engineering.

Open protocols make the edges portable, not the system

Open standards complicate every vendor's attempt to own the whole stack.

The Model Context Protocol is standardising how agents connect to tools and data. Its maintainers reported that the July 2026 MCP specification removed protocol-level sessions and the initialisation handshake, making remote servers easier to operate as horizontally scaled HTTP workloads. The roadmap also focuses on agent identity, enterprise security and longer-running agent interactions.

The A2A 1.0 specification addresses a different boundary: discovery and communication between independent agents built with different frameworks or by different vendors.

These standards can reduce the cost of reconnecting tools or allowing agents to collaborate across platforms. They do not make an architecture portable by themselves.

Your state schema may still be proprietary. Your permissions may be expressed in one cloud's identity system. Your evaluation history may live in a vendor dashboard. Your recovery procedures may assume one runtime. Two platforms can support the same protocol while leaving very different migration work.

Interoperable connections do not guarantee replaceable control planes.

There will be winners at different control points

I no longer think the useful prediction is that model companies, clouds, databases or independent frameworks will own the agentic future outright.

Control point	Who starts with an advantage	What makes it sticky
Model and harness	Model providers	Model-native tools, context handling and rapid access to new capabilities
Runtime and governance	Cloud providers	Identity, networking, policy, deployment and existing enterprise operations
Context and memory	Data platforms	Operational data, retrieval, stored state and data residency
Evaluation and observability	Independent platforms and clouds	Historical traces, test cases, release decisions and incident knowledge
Business workflow	Application owners	User relationships, permissions and the process in which the agent acts

My current view is that model providers will own the easiest default path, especially when their harness materially improves their own models. Cloud providers are best placed to own the enterprise control plane. Data platforms can own a large part of context and memory. Independent platforms can remain important where organisations need a neutral evaluation and operations layer across all three.

There is also a contender that infrastructure discussions often miss: the company that owns the business workflow. An agent inside a CRM, development platform or service-management product may reach users and governed actions without asking them to assemble an agent stack at all.

That is another reason a single winner is unlikely. The valuable boundary changes with the product being built.

Choose the dependency you can explain

When I first compared these platforms, I was looking for the category winner. I now think that is the wrong decision to optimise.

Before choosing an agent platform, I would ask:

• Which models, tools and execution environments can we replace without rewriting the workflow?
• Where do durable state, memory and evaluation cases live, and can we export them in a useful form?
• Which system enforces identity, permissions and human approval before an agent acts?
• Can we inspect a complete run when the agent fails halfway through a task?
• What provider-specific feature are we accepting, and what measured improvement justifies it?
• If this vendor disappeared, which part of the system would we struggle to reconstruct?

The answer does not have to be “none”. Avoiding every dependency can leave a team maintaining undifferentiated infrastructure while competitors ship better products. A deliberate dependency is different from an invisible one.

Do not choose the platform that claims to own the entire stack. Choose which part of your stack you are prepared to let it own.