In enterprise agent deals, the first hard question is rarely about the model. It is about the virtual machine. Where does it run? Where do the snapshots persist? Does anything leave our VPC? If you sell agents to healthcare or financial services, deployment topology is not an ops detail. It is the product.
This surprises teams who think of agents as an API you call. But a background agent is not an API. It clones your repositories, reads your tickets, touches data that may include PHI or financial records. The moment an agent does real work, it inherits every data governance requirement the organization already lives under. A buyer in a regulated industry cannot waive that, and a vendor without a credible answer is disqualified before the evaluation begins.
There are two common failure modes. The first is SaaS-only, which simply exits the conversation. The second is more subtle: a self-hosted edition that is a lagging fork of the real product. On-prem customers end up running last quarter's agent while the SaaS users get the improvements, and the deployment quietly rots. The pattern that actually works is a one-to-one release cycle, where anything shipped to SaaS is instantly available self-hosted, with upgrades either scheduled or managed by the vendor. The customer gets one box to think about, not a distribution to maintain.
What buyers increasingly ask for is a hybrid: agent compute inside their own cloud account, control plane and everything else as SaaS. That is a harder engineering problem than either pure model, which is exactly why it is worth solving. Most of the market is still trying to get the demo past the deployment line, and compliance is one of the walls that line runs along. The vendors who treat operationalization as the real work will design for topology from day one instead of bolting it on when the first regulated buyer shows up.
If you are building agents for the enterprise, put deployment topology on the roadmap next to capabilities. The model decides whether the agent is smart. The topology decides whether anyone is allowed to use it.
Key takeaways
- Regulated buyers ask where the VM lives before they ask what the agent can do, and vendors without a real answer lose before the evaluation starts.
- Self-hosted only works when it ships in lockstep with SaaS, so on-prem customers are never running a stale fork of the product.
- Hybrid topologies, with compute in the customer's cloud and the control plane as SaaS, are becoming the default ask in healthcare and finance.
FAQ
Why can't regulated enterprises just use SaaS agent platforms?
Because background agents touch source code, tickets, and internal data, compliance regimes like HIPAA often require that this data never leaves the customer's VPC. A SaaS-only agent product is structurally disqualified from those deals no matter how capable the agent is.
What makes self-hosted agent deployments fail?
Version drift. When the self-hosted build lags the SaaS product, on-prem customers become second-class users running last quarter's agent. The fix is a one-to-one release cycle plus managed or scheduled upgrades so self-hosted never means stale.
Sources
Related Essays
Investing in the Wrong Part of the Harness Is the Real Mistake
Not every agent product needs a vector database and a custom retrieval pipeline. The hard part is knowing which layer of the harness deserves real investment.
Build the Infrastructure, Not the Harness
Startups cannot out-build frontier labs on models or harnesses. The durable position is the infrastructure layer that runs harnesses you do not own.
The Agent Harness Problem
Enterprise agents need layered interfaces, real software skills, and flexible platforms. The harness around the model matters more than the model.
Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.