Managed vs Self-Hosted Agent Runtime: The Real Trade-offs

A managed agent runtime executes your agent's loop on vendor infrastructure: LLM calls, tool dispatch, retry logic, and state persistence between steps. Self-hosting means you run that loop on your own servers. The decision turns mostly on who is allowed to see your data and how much control you need over failure behavior, not on cost alone.

Most founders don't think about the runtime at all until something breaks. A tool call hangs, a retry storm triples the LLM bill overnight, or a customer asks where their conversation transcripts are stored. That's usually the first moment "managed vs self-hosted" becomes a real decision instead of a default.

What the managed agent runtime actually does

Strip away the marketing and any agent runtime handles four things:

• State management between steps, so the agent remembers what it already tried
• Tool execution: calling your APIs, databases, or external services
• Retry and timeout logic when a step fails or hangs
• Observability: logging what the agent did and why

A managed platform (LangGraph Cloud, CrewAI's hosted offering, various vertical agent platforms) gives you all four out of the box, usually with a dashboard. Self-hosting means you build or configure each piece yourself, typically on top of a queue (SQS, Redis) and a worker process you own.

What you give up either way

With a managed runtime, you lose visibility into how retries and timeouts are actually implemented. That matters when an agent silently retries a non-idempotent action: charging a card twice, sending a duplicate WhatsApp message, writing the same row to a database. You also lose data residency guarantees, because prompts and tool outputs transit the vendor's servers. For healthcare or government clients who require in-region processing, that's a contract problem, not just a technical preference. And pricing is less predictable: most managed platforms charge per execution or per token pass-through on top of your LLM bill.

With self-hosting, you lose time. Building reliable retry logic, dead-letter handling, and step-level observability is a multi-week engineering project, not a config flag. You also lose the vendor's SLA (if your worker falls over at 2 a.m., that's your on-call rotation) and the debugging tools vendors bake in, like step-by-step replay UIs.

Neither side is free. The question is which cost you can absorb right now.

Where this bites founders in practice

The tradeoff shows up most clearly in agent execution patterns, not just hosting location. When we built our own outreach engine, the first version chained multiple LLM calls together: one to extract facts about a prospect, another to draft the email, a third to refine tone. Running that chain through a managed orchestration layer worked, but every extra hop added latency and another point where a hung tool call could cascade into a stuck workflow the dashboard didn't explain clearly. Collapsing it into a single call that both extracted facts (via a self-hosted Firecrawl instance) and drafted the email in one pass cut both cost and failure surface, because there was simply less runtime state to manage or lose visibility into.

The lesson generalizes: the fewer moving parts in your agent's loop, the less the hosting question dominates. Once your workflow grows past two or three steps, it starts to matter a lot. That's a variant of the same tradeoff covered in single-call vs agent chains.

Serverless self-hosting has its own trap. If your agent's tool calls can run long (waiting on a slow third-party API, a document parse, a human-in-the-loop approval), AWS Lambda enforces a hard 15-minute execution ceiling per invocation, per AWS's documented limits. Teams that don't check this upfront discover it when an agent workflow that worked fine in testing starts silently truncating in production under real-world API latency.

A rough decision framework

Go managed if:

• You're validating whether the agent use case works before committing engineering time
• The data passing through isn't regulated or customer-sensitive
• You don't yet have someone who owns infrastructure reliability

Go self-hosted if:

• The agent touches health records, financial data, or anything with a data residency requirement (similar reasoning to why we recommend self-hosting an LLM over API calls once compliance is in scope)
• You're running enough volume that per-execution fees are a real line item, not a rounding error
• You need custom retry semantics because some tool calls aren't safe to retry blindly: payments, outbound messages, database writes

Either way, decouple your agent's logic (prompts, tool schemas, state definitions) from the runtime's specific SDK. If every tool function calls a vendor-specific orchestration API directly, migrating later means rewriting the agent, not just redeploying it. This is the same due-diligence question we walk through in our agent vendor evaluation checklist: ask the vendor upfront what happens to your logic if you leave.

The maintenance cost nobody quotes upfront

Whichever path you take, budget for ongoing maintenance. Managed runtimes still need someone watching cost per execution and updating prompts as the product changes. Self-hosted runtimes need someone patching the worker infrastructure and handling incidents. We break down what that ongoing cost typically looks like in AI agent maintenance cost, and it's rarely zero on either path.

If you're weighing this for a specific product and want a second opinion on where the line should sit for your data and volume, let's talk.