Three levels of keeping it close
"We want to keep it in-house" hides three very different requirements, and confusing them is why a lot of enterprise agent deals stall.
- Sovereign or residency hosting: your data sits in a Swiss or EU region, but still inside a provider's cloud. Good for data residency rules, weakest on control.
- BYOC or VPC peering: the agents run inside the AWS or Azure account you already operate, wired to your control plane. This is what most cloud-native enterprises ask for today.
- True on-premise: the whole system runs in your own datacenter, on your own metal, and can be cut off from the internet entirely. Maximum control, and the bar the most regulated players hold.
Why the biggest players go all the way
A systemic insurer or a tier-one bank does not do VPC peering with a startup. Their security function will not accept a third party operating a control plane inside a cloud account they do not fully own, and their regulators reinforce it.
For those organizations, autonomous agents touch policy data, claims, trades, customer records: exactly the data that cannot leave the building. So the requirement is not "host it in Europe," it is "run it on our metal, under our identity provider, ideally air-gapped, with nothing phoning home." That is true on-premise, and it filters the market hard: most agent platforms are SaaS that cannot run disconnected from their own cloud.
One agent
Easy to babysit.
A fleet, by hand
What true on-premise actually requires
Running an agent fleet on a customer's own hardware is only possible if the architecture was built to be portable, not to phone home. That means the source of truth, the recovery logic, the density controls and the integration layer all run locally, as a self-contained cluster, with no hard dependency on a vendor cloud.
It also means meeting the enterprise where they are: integrating with their identity provider for single sign-on, their provisioning pipeline, their internal object storage, and their compliance posture. Sovereignty is table stakes; the real work is being operable inside someone else's tightly controlled environment without a constant link back to yours.
On-premise flips the economics
The usual objection to always-on autonomous agents is idle cost: paying for a machine that sits mostly idle between bursts of work. On-premise, that objection disappears.
Your datacenter already runs 24/7. The servers are powered, cooled and paid for regardless. So an always-on agent adds no marginal idle cost at all, you are using capacity you already own. The economics that make cloud agents look expensive invert the moment the hardware is yours. The only real cost left is operating the fleet, and that is the part to outsource, not the compute.
The runtime is not the moat, the operating layer is
Whether the enterprise runs OpenClaw or Hermes barely matters: both are open runtimes, and a good platform is runtime-agnostic, running either on the same control plane with the same recovery and versioning. The hard, valuable part is not the agent, it is keeping a fleet of them alive, recovered, integrated and governed at scale, on infrastructure you may not control day to day.
That is the layer worth buying. A managed control plane that deploys onto the enterprise's own metal gives them the operating model of a cloud platform with the control of on-premise: their data, their identity, their hardware, someone else's on-call.
The honest catch
None of this closes fast. On-premise enterprise deals run 12 to 24 months, through security review, procurement and compliance, and they will demand SOC 2, ISO 27001, air-gap support and real SLAs. A blog post does not win Allianz.
What it does is make sure you are in the room as a credible on-premise option when the evaluation starts, and that your internal champion has the argument ready. The thesis is simple and, we think, correct: as the largest regulated enterprises adopt autonomous agents, the demand moves toward their own metal, and the winners are whoever can run a managed agent fleet there without the data ever leaving.