Managed Agent Platforms vs Self-Hosted Deployment Models

Enterprise buyers keep asking if an agent platform should be managed or self-hosted, but that question has the wrong shape for 2026. The binary between managed and self-hosted has collapsed, and enterprises now configure a spectrum of hybrid arrangements where "SaaS" and "self-hosted" describe who owns the control plane. Agentforce 360 for AWS runs fully on AWS global infrastructure through Salesforce's Hyperforce layer, with orchestration and data both held inside the Salesforce Trust Boundary on AWS, rather than split across a Salesforce control plane and a customer's own AWS account. Anthropic released public-beta sandboxes in May 2026 that push tool execution onto the customer's own environment, but orchestration stays on Anthropic's infrastructure, so the product is self-hosted in one dimension and fully managed in another. Every major SaaS vendor, including Agentforce 360, Microsoft Foundry, and SAP Joule, now ships some version of a managed control plane paired with a private data plane. Once a single product can be configured as "managed control plane plus customer data plane" or "customer-run execution plus vendor orchestration," asking whether it is managed or self-hosted stops producing a useful answer, and the rest of this piece works from the question that actually does.

What a control plane actually does and why ownership of it is the operative question

A control plane checks every agent action against identity policy before it runs, it records who did what on whose behalf against which system, and an organization can swap out the underlying model or orchestration layer without tearing apart the governed connections underneath it. Three functions define what it means to own this layer: authentication, checking each agent action against existing identity policy before execution; logging, keeping a single record of which agent acted, on whose behalf, and against which system, rather than scattering that information across infrastructure layers; and policy enforcement, applying rules about what agents can and cannot do at the moment of execution rather than after the fact. Whoever owns the control plane owns the governance of agent behavior, regardless of where the compute happens to sit. An agent can run entirely on a customer's own servers, but if it checks every action against a vendor's identity and policy service, that vendor holds the audit trail and the enforcement chokepoint, not the customer running the hardware.

This is why the market has started naming the layer directly rather than leaving it implicit. The Futurum Agent Control Plane Framework, published in April 2026, classifies what it calls Open Ecosystem design across runtime, control-plane, and state portability, and treats adoption of open standards (OpenTelemetry, MCP, and A2A) as a requirement rather than a nice-to-have. Boomi launched its own Agent Control Plane in September 2026, built specifically to give organizations control over how agents access business systems, use data, and consume compute, marketed as vendor- and model-neutral across public cloud, private cloud, and on-premise deployments. A named product category called "control plane" emerging in the same year that the managed-vs-self-hosted binary broke down is not a coincidence. Platforms like Oso operate at exactly this layer: they ship a managed-control-plane / private-data-plane hybrid mode to enforce policy at runtime and generate the audit trail that control-plane ownership requires.

The Three Tiers of Self-Hosting

Self-hosting is not one configuration, and regulated buyers and CISOs have already settled on a three-tier model that tracks how much of the control plane an organization genuinely owns. Tier A covers VPC or private cloud deployments: the vendor still manages the control plane, workloads run inside a customer-owned VPC, data stays on the customer's network, but authority over the control plane, the audit trail and the enforcement logic, stays with the vendor. Tier B means the platform runs entirely on customer-operated infrastructure, with the customer holding the runtime, the keys, and the audit trail, and no dependency on the vendor's cloud at all. Tier C adds a further restriction on top of Tier B: no network connectivity to vendor infrastructure whatsoever, with model weights and dependencies delivered by physical media or an isolated transfer process, a configuration generally reserved for security-classified and defense-adjacent work.

These tiers sort buyers by obligation more than by preference. DORA's Article 28 covers general principles for managing ICT third-party risk, including audit access, and Article 30 requires contractual guarantees on data location, audit rights, and subcontracting transparency, with obligations scaled to how critical the function is, though the regulation itself never names or prescribes a tier like "Tier B". EU public-sector buyers operating under national sovereignty guidance may be pushed to Tier C regardless of cost. Most commercial enterprises outside regulated categories can run comfortably at Tier A, and most hybrid SaaS products sold today are built to deliver exactly that. Marketing language does not always match the tier. A product sold as "self-hosted" that only offers a private VPC with the vendor still running the control plane is Tier A, full stop on capability, and the vendor retains the authoritative audit trail even though the compute sits on the customer's cloud account. If you actually need Tier B, you should read vendor contracts closely enough to catch this, because the label on the brochure and the tier in practice are not guaranteed to agree. At every tier, the control plane still has to authenticate, log, and enforce; organizations running Tier B or Tier C deployments need their own authorization and audit layer, owned and operated internally, rather than delegated back to the same vendor whose infrastructure they just left.

Compliance Obligations and Tier Requirements

For a meaningful share of enterprises, the tier decision is made before anyone gets to discuss cost, team size, or which vendor they'd rather work with. Three compliance events push an organization automatically from SaaS to Hybrid or further, according to the decision matrix used by regulated buyers: handling HIPAA-eligible data, carrying FedRAMP classification, or falling under EU AI Act Annex III as a high-risk use case. Crossing any one of these is a threshold event rather than one input among several in a weighted score.

High-risk obligations under Articles 6 through 15 became enforceable on August 2, 2026, subject to the Omnibus amendments agreed in trilogue on May 7, 2026, and penalties for violations reach three percent of global annual turnover, with a steeper seven percent tier reserved for prohibited practices under Article 5. The Act demands documentation, risk classification, human oversight, and audit trails; it does not mandate self-hosting outright, but once data-residency and audit-access requirements stack on top of those obligations, self-hosting is often the most direct path to compliance. A related exposure runs through the US CLOUD Act: an EU organization handling patient records, financial files, legal documents, or government information that sends prompts to a US-headquartered provider creates a third-country transfer, which raises open questions about how CLOUD Act obligations interact with GDPR.

FedRAMP adds its own wrinkle for government-adjacent work. Standard commercial licenses of tools like Copilot or Cursor do not satisfy FedRAMP High requirements for handling Controlled Unclassified Information; Copilot reaches that bar only through a separate government SKU, GCC High, while Cursor currently carries no FedRAMP accreditation at all. Defense contractors working inside an already-authorized FedRAMP boundary can self-host agentic tooling inside that boundary and use agent capabilities without breaching data-residency rules.

This pattern appears across deployments already running, visible in the three case organizations' Rasa deployments that illustrate how compliance removes optionality. N26 runs Rasa on its own secure cloud environment for regulated banking customer service, a setting where cloud-only tools are disqualified before the conversation about features even starts. Swisscom rebuilt its customer service agent on the CALM framework and moved from prototype to production quickly, doubling its automation rate and cutting costs in half. One objection deserves a direct answer here: managed platforms with strong data processing agreements satisfy most compliance requirements, and for a large share of commercial use cases that is true. But DORA's Article 28, national sovereignty rules, and sector-specific residency requirements demand contractual guarantees on data location and audit access that current Tier A managed platforms simply don't provide, and for buyers bound by those rules, the decision isn't a matter of preference at all.

Cost and Team Capability for Everyone Else

Most enterprises are not forced into a tier by regulation, and for them the decision runs through a plainer calculation: does the engineering cost of running a control plane in-house outweigh the governance and cost benefits of owning it. The two paths draw from different budgets entirely, and most organizations miscalculate by comparing infrastructure costs without including the engineering FTE cost of operating the self-hosted stack. Managed platforms charge ongoing subscription or usage fees that scale with how much an organization uses them, but self-hosted deployments demand upfront infrastructure spending plus continuous engineering time, so comparing the two on a single cost line misleads from the start.

Volume shifts the answer in a predictable direction. If you count engineering time honestly as a cost, managed platforms tend to come out cheaper below roughly two hundred requests a day. But at higher volumes, thousands of requests daily, self-hosted infrastructure on open-weight models can undercut a managed subscription by a wide margin.

That headcount is not small. A minimal self-hosted agentic platform needs at least one platform engineer for installation, configuration, and upkeep, and realistically two once production SLAs are in play, with somewhere between half and a full additional FTE committed on an ongoing basis to patching, upgrades, and incident response. Compliance work adds its own line item. Most managed platforms can hand a buyer a SOC 2 Type II report, but a self-hosted team has to produce that evidence itself or buy a compliance platform to do it, and that gap typically runs into six figures a year.

You should retire one assumption: managed platforms do not win automatically on model quality. Open-weight models including DeepSeek V4, GLM-5.2, and Qwen 3.5 now compete with proprietary models across most enterprise benchmarks, which has narrowed the case that paying for a managed platform buys meaningfully better model access. If you have the engineering bench to run your own stack, the model-quality argument for staying managed has mostly dissolved.

Vendor lock-in in 2026 is a control-plane problem, not a file-format problem

The old worry about lock-in was proprietary file formats and data you couldn't get back out. That worry has moved. Microsoft's Build 2026 governance analysis describes the new shape of lock-in as a business process that only functions because six platform services understand each other, not a format a competitor can't read. Lock-in concentrates in three layers: agent memory, model integration, and orchestration tooling, and switching costs peak when a single vendor's control plane owns all three at once.

That reframing changes what buyers should actually check during procurement. Open protocols are starting to blunt the problem at the integration layer: A2A and the Model Context Protocol let agents from different vendors talk to each other without custom glue code for every pairing. The Futurum framework from April 2026 treats OpenTelemetry, MCP, and A2A adoption as required rather than optional, and names open ecosystem design as the specific mechanism that prevents lock-in across runtime, control-plane, and state portability. As these standards mature, lock-in risk falls, but only for buyers who insist on MCP and A2A compatibility as a procurement requirement rather than treating it as a bonus feature.

The practical consequence cuts against intuition. An enterprise can run its compute entirely on self-hosted infrastructure and still be tightly locked in, if the control plane that infrastructure depends on is a proprietary vendor service. A managed platform that exposes open standards at the control-plane level can carry less lock-in risk than a self-hosted stack built on a closed, proprietary orchestration layer. The location of the compute was never the variable that mattered.

Pilot-to-Production Failure Is a Control-Plane Governance Gap

Gartner predicts that more than 40 percent of agentic AI projects will be canceled before 2027, and it cites unclear business value and inadequate risk controls as the drivers. The models powering these pilots are rarely the reason they stall. Projects stall because the deployment decision pushes control-plane governance, authentication, logging, policy enforcement, to the handoff point between pilot and production, and that is exactly where the gaps turn into blockers that a pilot never had to face.

A pilot can look successful in a sandbox with a handful of users without a complete audit trail or airtight policy enforcement. Production does, and by the time an organization reaches that point, retrofitting authentication and logging onto a system built without them costs far more than designing for governance from the start. Every tier discussed earlier, every compliance threshold, every lock-in risk, routes back to the same layer: whoever owns the control plane owns whether an agent's actions are governed and auditable, and that ownership question has to be answered before the pilot begins, not after it's declared a success.