Skip to content

Managed vs Self-Hosted Agent Harness

Choose between a managed agent service and a self-hosted harness across five signals: compliance, memory ownership, observability ownership, model routing, and ops capacity.

The decision

Managed agent services — Claude Managed Agents (platform docs) — provide a pre-built harness, sandboxed execution, and hosted infrastructure in exchange for vendor coupling. Self-hosted open-source harnesses — LangChain Deep Agents Deploy, Cursor's self-hosted cloud agents — trade ops burden for control over data, model selection, and accumulated agent memory.

The choice mirrors the classic SaaS vs on-prem decision but with a compounding factor: agents accumulate memory over time. Locking memory behind a proprietary API raises migration cost with every session.

Compliance and memory-ownership signals

1. Compliance and data residency

Hard regulatory constraints that mandate data never leave your network force self-hosted execution, regardless of other factors. As the hybrid pattern below shows, that need not mean a fully self-hosted harness. Cursor's self-hosted cloud agents (March 2026) address this directly: "your codebase, build outputs, and secrets all stay on internal machines running in your infrastructure" with "tool calls handled locally" — capability-equivalent to hosted, but with no data crossing Cursor's boundary (Cursor changelog).

Managed services run workloads on vendor infrastructure by default. If your threat model includes vendor access to execution artifacts, the fully-hosted variant is out — though the managed/self-hosted line is blurrier than it first appears (see the hybrid pattern).

2. Memory ownership

Harnesses are coupled to memory management. An agent harness "is intimately tied to memory — a key role of the harness is to manage context" (LangChain, April 2026). When an agent learns from interactions — adapting to user preferences, accumulating domain knowledge, building an internal model of your codebase — that memory accumulates inside the harness.

With a managed service, that memory sits behind the provider's API; migration means resetting learned state — a cost that grows with every session. With a self-hosted harness, memory lives in your own databases and persists through vendor changes. This is the strongest argument for self-hosting when agents are long-lived or customer-facing, not just for batch tasks — memory is a property of the harness, not a pluggable module.

Observability, routing, and ops signals

3. Observability ownership

Managed services emit verdict-labeled traces only through their dashboards. Self-hosted lets you wire OpenTelemetry into the pipeline that already covers the rest of your services. If agent traces must flow into your existing stack — same backend, retention policy, and correlation IDs — that constraint is observability-shaped, not compliance-shaped. You cannot debug what you do not own; see Agent Observability with OpenTelemetry for the OTel instrumentation contract that decides whether a managed surface can plug in at all.

4. Model routing flexibility

Managed services vary: Claude Managed Agents uses Anthropic models exclusively; Amazon Bedrock AgentCore supports multiple providers including OpenAI and Gemini (AWS, 2026). The pattern holds at the platform layer — each managed service binds you to its approved roster, even one spanning providers. Self-hosted harnesses drop the roster and route across any provider: Deep Agents Deploy supports OpenAI, Google, Anthropic, Azure, Bedrock, Fireworks, Baseten, Open Router, and Ollama, switchable per deployment or task (LangChain, April 2026).

If you need multi-model routing, cost-based routing across providers, or model migration without re-platforming, self-hosted gives you that. If one provider's flagship model covers your workload, managed removes the routing overhead.

5. Ops capacity

Self-hosted means deploying and operating the harness, orchestration layer, sandboxes, and memory stores. Deep Agents Deploy cuts this to a single deepagents deploy command that provisions a multi-tenant, horizontally scalable server with 30+ endpoints — but you still own the infrastructure (LangChain, April 2026). Managed services — Claude Managed Agents in particular — handle all of it: "no need to build your own agent loop, sandbox, or tool execution layer" (Anthropic, 2026). The trade-off is losing the ability to customize those layers.

Decision flow

graph TD
    A[Start] --> B{Hard compliance or<br>data residency requirement?}
    B -->|Yes| C[Self-hosted]
    B -->|No| D{Long-lived agents<br>with accumulating memory?}
    D -->|Yes| E{Memory migration<br>cost acceptable?}
    E -->|No| C
    E -->|Yes| OBS{Agent traces must flow<br>into your OTel stack?}
    D -->|No| OBS
    OBS -->|Yes| C
    OBS -->|No| F{Multi-provider model<br>routing required?}
    F -->|Yes| C
    F -->|No| G{Ops team to run<br>harness infrastructure?}
    G -->|No| H[Managed]
    G -->|Yes| I[Either — evaluate<br>lock-in tolerance]

The hybrid pattern

Cursor's self-hosted cloud agents (March 2026) demonstrate a hybrid: managed orchestration and agent definitions hosted by Cursor; execution and tool calls running on customer infrastructure. You get the managed control plane without placing code, secrets, or build artifacts on vendor machines.

This is the pattern to consider when compliance concerns are about execution artifacts specifically, not orchestration metadata.

The hybrid is not Cursor-specific. Managed providers increasingly offer self-hosted execution as a first-class mode: Claude Managed Agents supports self-hosted sandboxes where "the agent's code, filesystem, and network egress never leave your environment," positioned for "your organization's own compliance and audit controls" (Anthropic). So the data-residency signal alone rarely forces a fully self-hosted harness. What stays genuinely managed-only is narrower: in that case, accumulated memory is unsupported with self-hosted sandboxes, and managed sessions remain ineligible for Zero Data Retention and HIPAA BAA (Anthropic). Weigh those residual constraints, not the deployment label.

Key Takeaways

  • Compliance and data residency are hard constraints — evaluate them first; other factors only matter if you have a choice
  • Memory accumulation behind a proprietary API compounds lock-in over time — this is the structural difference from classic SaaS vs on-prem
  • Multi-model routing flexibility requires self-hosted; managed services bind you to their provider's model set
  • The hybrid model (managed control plane, self-hosted execution) reduces ops burden while keeping execution artifacts on your infrastructure
Established — multiple independent sources Last reviewed: 2026-06-16
Feedback