The Next Era of Cloud Agents: Enterprise AI Sovereignty

The first era of AI resulted in two very different approaches to AI agents for the enterprise.

One is the vertical cloud agent: products from companies like Sierra and Glean, or AI capabilities embedded in incumbent SaaS platforms like Datadog and Salesforce. These agents have capabilities for specific use cases out of the box. They connect to your data, adapt to your workflows, and improve over time. But they are black boxes. You cannot fully inspect how they work, you cannot repurpose what they learn, and you have promises rather than direct control over what they do with your data. You are renting the AI; you don’t own the asset.

The other is the local coding agent: tools like Claude Code or OpenAI Codex that run on a developer’s machine, connected to a codebase, operated by a single engineer on a project-by-project basis. These are more transparent and controllable. But they are more generalised, and designed for interaction with one user-operator.

I believe that for most business use cases, vertical cloud agents will rapidly become outdated. The catalyst for their replacement is the maturation of coding agents and the tooling surrounding them. Coding agents are now crossing a threshold where they can run in shared environments, support multiple operators, serve many end users, and be composed from transparent and interchangeable parts. That architecture is now capable enough to meet or exceed vertical cloud agents on performance while dramatically outcompeting them on economics and strategic ownership.

These capabilities mean a new era for cloud agents is beginning, one where the value that accrues from usage of agents is retained by the customer, not their vendor.

The problem with vertical cloud agents

The case against first-era vertical agents is not that they fail to work. It is that the terms of the deal are worse than they appear.

Data risk is concentrated outside your control. Sharing a single data source with a SaaS vendor is a familiar risk that most security teams know how to manage. Sharing everything an AI agent needs to be high performing is different in kind. The strongest agents need access to code repositories, production databases, communication tools, financial systems, customer records. Either you withhold data sources and limit agent impact, or you take on an enormous source of risk.

They are intelligence black boxes. Every vertical agent is built from the same ingredients: general-purpose LLMs, a set of system instructions, API connections to your tools, and some form of workflow memory. The quality of the product reflects how well that combination has been assembled. But the assembly lives inside the vendor’s system, opaque to you. You cannot audit the reasoning, adapt the logic, or extract what the system has learned and apply it elsewhere.

The intelligence they build from your data stays theirs. This is the most under-appreciated problem. Agent performance improves materially with use. As an agent handles more support tickets or more incidents, it accumulates context: which data are most useful, which paths from intent to action are correct, which errors are noise and which matter. That accumulated intelligence is a valuable AI asset — and in a vertical agent architecture, it remains locked inside the vendor. If you ever want to change providers, you lose it and have to start over.

The economics do not hold up. The frontier model is providing most of the intelligence. Your data is providing most of the rest. The vertical vendor is providing scaffolding around both. As frontier model providers have added generalised agentic capabilities (memory and retry behaviour) the incremental value of that scaffolding looks thin. Datadog’s BitsAI product charges $30 per SRE investigation, but you can now achieve better results for about $3 using Claude Code and integrations to your own data. That is not an edge case. Across customer support, software development, sales operations, security, and every other function where agents are being deployed, the value proposition of first-era vertical agents is eroding to token cost.

What AI sovereignty means for a company

You may have encountered the concept of AI sovereignty at the national level; the case for countries hosting and controlling their own infrastructure to maintain regulatory independence and strategic autonomy. An equivalent case can be made for sovereignty at the company level, driven by two motivations:

You retain control of data. When agents query data only within your infrastructure, under strong access controls and with full auditing, the improved security posture has an important second-order effect: you can connect more data sources. Agents become more capable because they have better context. The alternative is a continuous negotiation between what each agent needs and what you are willing to expose to a third party.

You retain ownership of derived intelligence. Every time an agent runs, it generates something more valuable than its output. It generates signal: about which data sources were useful, which query patterns work, which context helps the model reason correctly, which paths from goal to action are reliable. In aggregate, this is the derived intelligence of your organisation’s AI usage, and it is the primary source of agent improvement over time. In a sovereign architecture, this intelligence accumulates inside your infrastructure, is available across all your agents, and survives any vendor relationship, including switching model providers entirely.

The result is a compounding advantage. Sovereign agents improve faster because they can share context across deployments. They can be trusted with more sensitive data. They cost less to run. They can be audited, adapted, and replaced without starting over. And they grow more capable over time in ways that belong to the organisation, not to a vendor.

Why now? And how?

The economic argument for AI sovereignty has become undeniable. In-house agents can be 10x cheaper with similar performance and implementation times, while avoiding vendor lock-in risks. Four areas of change in agent infrastructure has made this possible:

1. General purpose agent harnesses have evolved and many are model-agnostic by design or can use a model-routing proxy. Agents originally designed for local coding (e.g. Claude Code, OpenCode, Pi) work well for other long-window tasks, are transparent and controllable, and can be deployed in a sandbox with multiple operators and access controls. For more complex workflows, orchestration frameworks like LangGraph, Pydantic and CrewAI have become more powerful and easier to use.

2. The infrastructure to run frontier or open weights models inside your own environment is more straightforward to implement at scale. Running agents inside your own cloud account — through Amazon Bedrock or Google Vertex AI — means inference never leaves your VPC and the model provider has no access to your context data.

3. The tooling around the agent harness has matured, making it easier than ever to avoid siloed dependencies on a single vendor. Dedicated memory layers like Mem0 and Zep store the context, preferences, and task state in a way that transfers across sessions and agents. Tool authentication providers like Auth0 and Composio centralise permission management for multi-agent systems.

4. Data retrieval across large scale sources can now be optimised more easily and shared across any combination of agent or tooling. Coral (built by our company) is an open source query runtime that improves retrieval performance by enabling agents to make fewer, more precise queries. It gives agents a single SQL interface across any API, file or object storage sources, handling data source calls, auth, pagination and caching with deterministic software.

AI assets that compound

In the new era, agents can be composed from transparent, interoperable parts and owned by the companies that deploy them. The agents are more capable, because they have access to more data — data that stays inside the organisation’s walls. The intelligence these agents accumulate will compound inside the organisation rather than inside a vendor’s platform. The future will be won by companies with proprietary AI capabilities, with a gap opening up between those who own their AI assets and those who merely rent.