From Prototype to Production at Agent Scale: What Managed Runtimes Actually Handle and What They Leave to You

Engineering teams that have built a working agent prototype face a decision that looks simpler than it is: adopt a managed runtime and move fast, or build a custom harness and retain control. The difficulty is that managed platforms market themselves on what they abstract, not on what they leave exposed. By the time a team discovers the gaps, they have already built workflows around the platform's assumptions. This piece maps the boundary between platform responsibility and team responsibility so that decision can be made with accurate inputs.

What Managed Runtimes Actually Own

Persistence and State Management

The most immediate value a managed runtime provides is durable state across agent steps. In a prototype, state typically lives in memory for the duration of a single execution. At production scale, agents run for minutes or hours, and any infrastructure interruption without durable checkpointing means restarting from scratch at cost.

Platforms like LangSmith's Deep Agents handle checkpoint serialisation and step-level replay natively. That removes a meaningful engineering burden, but it also means the team inherits the platform's state schema. If your agent produces domain-specific intermediate representations, you need to verify that the serialisation format accommodates them without data loss or type coercion.

Subagent Delegation and Orchestration

Managed runtimes typically provide primitives for spawning subagents, routing tasks between them, and aggregating results. This is where the abstraction is most attractive: multi-agent coordination is genuinely complex to implement correctly, particularly around failure propagation and partial completion.

The risk is that these orchestration primitives encode opinions about control flow. If your task decomposition logic does not map cleanly onto the platform's delegation model, you end up writing adapter logic that partially defeats the abstraction. Evaluate whether the platform's orchestration model is expressive enough for your specific task graph before committing.

Sandboxing and Tool Execution

Production agents that execute code, call external APIs, or write to datastores need execution environments with meaningful isolation. Most managed runtimes provide sandboxed tool execution with configurable permissions, and this is one area where building your own harness carries genuine operational overhead.

The relevant question is not whether sandboxing exists, but what the blast radius is when it fails. Review the platform's documentation on tool execution failures, permission escalation paths, and what happens when a tool call hangs. Platforms vary significantly in how they handle these edge cases, and the defaults are rarely production-appropriate without configuration.

What the Platform Leaves to You

Memory Architecture

Managed runtimes handle persistence, but they rarely make decisions about memory architecture on your behalf. The distinction between episodic memory, working context, and long-term semantic retrieval is a design decision that sits with your team. The platform provides storage primitives; your engineers decide what to store, when to retrieve it, and how to structure retrieval so that agents do not accumulate irrelevant context over long runs.

This is a more consequential decision than it appears. Poorly structured memory leads to agents that degrade in quality as task length increases, because the context window fills with low-signal history. The platform will faithfully persist whatever you give it.

Observability and Failure Attribution

Most managed platforms provide execution traces and basic logging. What they do not provide is the domain-specific instrumentation needed to distinguish between a model failure, a tool failure, a prompt design failure, and a data quality failure. Those categories require different responses, and conflating them produces debugging cycles that are expensive at production scale.

Your team needs to build attribution logic on top of whatever telemetry the platform exposes. That means defining what a meaningful agent failure looks like in your domain, not accepting the platform's generic error taxonomy as sufficient.

Trust Calibration and Human-in-the-Loop Design

Managed runtimes do not decide where human review should interrupt an agent's execution. That decision requires understanding the consequence profile of each action the agent can take, which is domain knowledge the platform cannot have. Teams that skip this design step typically discover the gap when an agent takes an irreversible action that a human would have caught.

We have written about this in more depth in the context of long-running agents. The organisational conditions that determine whether autonomous execution produces value or compounds errors are almost entirely outside the platform's scope.

Companion piece to our broader work on production agent deployment. See What Long-Running Agents Expose About Engineering Team Readiness for a practical analysis of the operational and workflow gaps that surface when teams move from short-context assistance to autonomous, long-horizon execution.

How to Benchmark Managed Infrastructure Against Build-Your-Own

The build-vs-buy decision should be evaluated across four dimensions: time to production, operational surface area, extensibility ceiling, and cost structure at your expected load.

Managed platforms compress time to production by providing solved infrastructure. The question is whether that compression is durable or whether it creates technical debt that surfaces six months in when you need behaviour the platform was not designed to support.

Operational surface area is where build-your-own harnesses are frequently underestimated. Maintaining a custom orchestration layer, durable state store, sandbox environment, and retry infrastructure is not a one-time engineering cost. It is an ongoing maintenance commitment that competes with feature work. Teams that understaff that commitment end up with fragile infrastructure that blocks the ML work it was supposed to support.

Extensibility ceiling matters most for teams with non-standard requirements: unusual tool execution environments, proprietary memory backends, or compliance constraints that affect data residency. Managed platforms have extension points, but those points have limits. Mapping your specific requirements against those limits before procurement is more reliable than assuming flexibility exists.

The Evaluation Process That Actually Works

Start by documenting the agent's full execution surface: every tool call, every state transition, every point where a human might need to intervene, and every failure mode with a non-trivial consequence. This document does not need to be exhaustive at prototype stage, but it needs to be honest about unknowns.

Run the platform against that surface in a time-boxed proof of concept, specifically targeting the edge cases rather than the happy path. Managed platforms perform well on happy-path demos by design. The useful signal comes from what happens when a tool call returns an unexpected type, when a subagent exceeds its context budget, or when a checkpoint fails mid-task.

Evaluate the platform's support model alongside the technical capability. At production scale, the time to resolution on a runtime incident is a business cost. Understand what the escalation path looks like and whether it is appropriate for your operational requirements before you depend on it.

Where the Decision Usually Goes Wrong

Teams that regret their managed runtime decisions typically made them at prototype scale, when the platform's abstractions felt comprehensive because the prototype's requirements were simple. The gaps become visible only when the production workload introduces the complexity the prototype was designed to avoid.

The inverse failure is also common: teams that decide to build a custom harness underestimate the maintenance cost and end up with a runtime that is less capable than a managed platform would have been, built and maintained by engineers who would rather be working on the agent logic itself.

The more disciplined framing is to treat the platform boundary as an explicit architectural decision with known trade-offs, not as a procurement question with a correct answer. Document what the platform owns, document what your team owns, and review that boundary as the agent's requirements evolve.