Figure 1. Managed Agent Platforms remove different barriers between an idea and an operating agent. Segments overlap; placement is not a ranking of vendors, maturity, or market share.*
The new software factory and the enterprise governance challenge
An executive market analysis for CISOs, Chief AI Officers, and AI product leaders. September 2026.
The next wave of enterprise AI is not going to arrive through one centrally approved platform. It is coming through many teams, many builders, and many ways of putting agents to work.
A developer is going to deploy a coding agent on their own cloud computer. A product team is going to embed an agent in an application. An operations team is going to assemble a managed agent with access to internal systems. Agent-assisted development is making these capabilities accessible to people who could not build them before.
The platforms enabling this shift are removing real obstacles: provisioning infrastructure, maintaining state, orchestrating work, connecting tools, and keeping agents running.
That is the opportunity. It is also the beginning of a much harder control problem.
The new software factory produces more than agents. It produces new infrastructure, new connections, and new paths through which autonomous software can exercise business authority.
As agent creation becomes easier and more distributed, enterprises need consistent, centralized governance across diverse agent fleets. The goal is not to slow the factory. It is to keep control of what leaves it.
1. Why builders are choosing Managed Agent Platforms
Application platforms like Heroku established a bargain: focus on your application while the platform handles running it. Managed Agent Platforms extend that bargain. You focus on what the agent should accomplish, not the machinery it needs to operate.
Their appeal comes from a few specific traits:
- A home beyond the laptop. Agents can work independently of the builder’s device, with isolated execution and persistent workspaces.
- Continuity. State, memory, retries, and approval pauses help agents continue across interruptions.
- Ready-made machinery. Managed harnesses reduce the need to assemble reasoning loops, tool execution, and context management.
- Application integration. Workflow services and connectors bring agents into existing products and business processes.
- Less operational burden. Platforms provide capabilities like scaling, authentication, credential handling, and observability.
- Choice of abstraction. Builders can adopt a computer, a workflow engine, a managed harness, or a runtime for their own code.
These capabilities appear in different combinations across Fly.io, Render, Vercel, LangChain, and AWS AgentCore.
The attraction is a shorter path from an agent that works once to an agent that can be put to work repeatedly.
2. One emerging market, four customer problems
Managed Agent Platforms is a useful umbrella for offerings that manage different portions of the agent operating environment.
At the harness end of the market, a managed agent is a managed execution harness running a customer’s configuration and business logic. Other offerings manage the computer or workflow underneath that harness.
The most useful way to understand this market is to start with the problem the customer is trying to solve.
My agent needs somewhere to work
An agent tied to a laptop is tied to that laptop’s availability. Code execution needs an isolated workspace, and files and installed tools may need to persist between sessions.
Managed agent computers and sandboxes address this problem. Representative offerings include Fly.io Sprites and Vercel Sandbox.
Fly’s Sprites illustrate the computer-first approach: persistent environments designed around how agents work. The founder’s post describes durable storage, cloning, and connectors intended to support authenticated access without exposing useful credentials to agent code. Vercel also documents persistent filesystem state for its sandboxes. Fly’s platform direction, Vercel Sandbox persistence
The customer gains a managed working environment. That does not mean the provider also manages the agent’s reasoning loop or business logic.
My agent must work inside a real application
A successful demo is not a reliable service. An agent embedded in a product or business process needs coordination, recovery from failures, and connections to applications and data.
Application and workflow platforms address this problem. Render and Vercel extend familiar application-development environments with services for long-running and distributed work.
Render Workflows handles task queuing, execution instances, and configured retries for developer-defined tasks. Vercel’s WorkflowAgent supports durable tool execution and human-approval pauses. Render Workflows, Vercel WorkflowAgent
A related development is agents operating the application platform itself. Render’s MCP and CLI capabilities let agents trigger deployments and manage resources. An agent can be both a workload on a platform and an actor with authority over that platform. Agents operating Render
I don’t want to build the agent machinery
A model call alone is not an operating agent. Builders must assemble the reasoning loop, tool execution, context management, memory, and other capabilities around it.
Managed execution harnesses reduce that assembly and operating burden.
LangChain Managed Deep Agents packages deployment and operational services around its extensible Deep Agents harness. Developers retain control over models, instructions, tools, middleware, and subagents, while the platform manages capabilities including persistence, memory mounts, and sandbox lifecycle. The documented offering is in public beta. Managed Deep Agents
AWS also has a managed AgentCore harness, powered by Strands, that supplies the orchestration loop through configuration. AgentCore harness and Runtime
The customer focuses on the agent’s purpose and behavior, and less on rebuilding its operating machinery.
I need to operate agents at enterprise scale
Deploying agent code is only the beginning. Teams need scaling, session management, authentication, operational visibility, and connections to their wider infrastructure.
Managed agent runtimes and cloud platforms address this operating problem.
Amazon Bedrock AgentCore Runtime hosts customer-owned agent code, distinct from AWS’s managed harness. Google’s Gemini Enterprise Agent Platform includes a managed runtime for deploying and operating agentic applications. LangSmith Deployment supplies runtime and deployment infrastructure with multiple hosting models. AWS Runtime, Google Agent Runtime, LangSmith Deployment
These offerings let customers retain different degrees of control over agent code while delegating operational responsibilities.
How to read the market
These segments are not mutually exclusive. A customer may need several of them, and a provider may participate in more than one.
Vercel’s integration with Claude Managed Agents demonstrates this directly: one provider manages the harness while another supplies the execution environment. Vercel’s managed-agent integration
The useful buying question is not simply “Fly, Render, LangChain, or AWS?” It is: Which operating problems do we want the platform to solve, and which responsibilities do we want to retain?
3. Agent sprawl becomes policy sprawl
As teams adopt different Managed Agent Platforms, enterprise policy risks becoming a collection of platform-specific implementations. Rules governing tools, data, environments, approvals, and delegation are distributed across harnesses, gateways, infrastructure settings, and application code.
The enterprise has one set of obligations, but many competing versions of how to enforce them.
Without a single authoritative record, security and IT teams must reconstruct which policies apply, who approved an agent’s purpose, what access it was granted, and whether those controls are still effective. The platform chosen by a builder can end up shaping how enterprise policy is expressed and which parts can be enforced.
The pressure lands on several teams at once:
- Security must reconcile controls and verify enforcement across platforms and execution paths.
- IT and platform teams must onboard agents, provision access, maintain configurations, and revoke authority consistently.
- Business, system, and data owners must approve the agent’s purpose, permitted actions, and use of critical systems and information.
Without a shared process to review, approve, verify, onboard, and authorize agents, each deployment becomes another negotiation across these teams. Changes to tools, data access, or operating scope trigger the same work again.
Approving an agent’s stated intent is not enough. That purpose must be translated into enforceable limits on its actions, not left as an instruction the agent is expected to follow.
The challenge is not merely managing more agents. It is maintaining one enterprise policy across many platforms, owners, and critical business systems.
4. The second expansion: AI infrastructure sprawl
Agent choices also introduce infrastructure choices.
Depending on the architecture, a team may adopt a model gateway, a harness-specific gateway, an MCP gateway, local or remote MCP servers, a memory store, a credential broker, and additional connectors.
Some arrive bundled. Some are optional. Others are introduced by builders or inherited from templates. Not every agent needs every component.
But across an enterprise, independently reasonable choices can accumulate into a fragmented AI infrastructure estate.
This matters because each component can create another path for data or authority:
- A model may be reached through the enterprise gateway, a platform gateway, or a direct connection.
- A business system may be reached through a remote MCP server, a local tool, an API client, or a command.
- Information may move from retrieval into context, persistent memory, or another agent’s workspace.
- Credentials may represent an individual user, an agent identity, or a shared service account.
A control on one route does not necessarily cover the others. The enterprise can have functioning security controls and still have incomplete governance coverage.
That is the hidden consequence of infrastructure sprawl: not just more systems to administer, but more places where enterprise policy can be interpreted differently or never evaluated.
5. Model sprawl keeps changing the operating stack
The expanding choice of open-source, open-weight, and fine-tuned models gives builders more ways to optimize agents for capability, cost, latency, and deployment control. One workflow may use a frontier model for planning, a specialized model for coding, and a smaller model for classification. Subagents can introduce still more model choices.
Teams will replace models, revise agent logic, and adapt harnesses as better-fit options emerge. Model choice will be a recurring engineering decision rather than a one-time platform selection.
That flexibility also brings infrastructure. Deploying model weights may require inference platforms, serving engines, accelerators, endpoints, and routing configurations. Managed services make this easier: Hugging Face, for example, has dedicated, autoscaling infrastructure for deploying supported models. Inference Endpoints
A model change can be a behavior change, a data-path change, and an infrastructure change, not merely a swap behind an API.
For security, IT, and agent owners, that creates recurring questions:
- Is this model version and deployment approved for the task and the data it receives?
- Do existing evaluations, tool-use assumptions, and safeguards still hold after the change?
- Which inference endpoint, region, credentials, and provider now process the data?
- Can the enterprise identify the model and policy configuration used by each agent and subagent?
The issue is not that open-weight models are inherently less safe. It is that a growing, changing set of models multiplies the configurations the enterprise must understand, verify, and govern.
Builders should be able to change models without silently changing the enterprise’s rules or invalidating the evidence that those rules hold.
6. The real unit of risk is the agent action surface
The defining risk is not simply that an agent has access. It is that a model-driven system can choose consequential actions without following a fully predetermined path.
High-agency agents select tools, arguments, and sequences dynamically. The same business request can produce different action paths as context, memory, model versions, and tool responses change. Nondeterministic action selection becomes an enterprise risk when those choices can alter critical systems or expose sensitive data. Agent architecture
An agent’s action surface comprises its available tools, the operations those tools expose, and the systems and data those operations can affect. A CRM connector, for example, may enable reading customer records, changing account details, exporting information, or deleting records. Approving the connector does not automatically authorize every operation it exposes.
The enterprise must approve both the action surface made available to the agent and the data surfaced into its reasoning context. Authorization must account for the operation, its parameters, the affected resource, and the circumstances in which it is attempted.
Permissions can constrain reach, including specific operations, but they do not prescribe the agent’s entire behavior within that boundary. An allowed tool can still be used on the wrong record, with inappropriate parameters, or in an unauthorized sequence. The underlying API may execute predictably; the agent’s decision to invoke it is the variable the enterprise must govern.
Agents may misinterpret or fail to follow instructions. Adversarial content in documents, websites, or tool responses can also redirect their behavior. Prompt-based constraints and model-level guardrails are not guarantees against such manipulation. Prompt-injection risks and defenses
Governance needs two connected decisions:
- Before use. Approve the agent’s purpose, tools, operations, and data scope; verify the required controls.
- At runtime. Enforce whether a proposed action is authorized for this resource, recipient, amount, or workflow state and require approval where policy demands it.
An agent allowed to inspect a customer account should not gain authority to export its contents or issue an unrestricted refund. Likewise, data approved for one task is not automatically approved for another model, recipient, or persistent memory store.
Agent decisions may be nondeterministic. The enterprise controls governing their execution must not depend on the agent choosing to obey. Approve the surface. Authorize the action.
7. Six questions enterprise leaders must be able to answer
Figure 2. Agent and infrastructure proliferation make six enterprise governance questions harder to answer. Risks are potential consequences of governance gaps, not inevitable outcomes of platform adoption.
What do we actually have?
Teams can create agents and supporting infrastructure independently. Ownership, dependencies, and access paths become difficult to track. Unknown or unowned activity can remain outside review and accountability.
What are they allowed to do?
Access to a system does not establish permission for every business action. Authority may depend on the affected record, the initiating user, a prior action, or an approval. Delegation adds another boundary to govern.
The risk is unauthorized use of legitimate access, not necessarily a security breach or sandbox escape.
Do our rules apply everywhere?
Different platforms, harnesses, and gateways implement controls differently. Local tools, direct APIs, commands, and browser actions can create alternative routes to the same outcome.
A prohibition is incomplete if an agent can perform the same operation through an uncovered route.
Where can our data go?
Data moves through retrieval, models, tools, subagents, and persistent memory. Permission to read does not automatically authorize disclosure, delegation, retention, or later reuse.
Governance must follow the information across those transitions, not stop at the original access check.
Can we keep control as things change?
Models, tools, credentials, and permissions change. Agents delegate, retry, and resume. An approval that was valid at the start of a workflow may no longer be valid when an action finally executes.
Revoking authority or stopping activity must account for related agents and execution paths, not just the original process.
Can we prove control was exercised?
A trace showing what happened is valuable. It is not necessarily evidence of which policy authorized an action, what context was considered, or whether approval was valid.
Scattered logs make it harder to reconstruct responsibility, demonstrate controls, and investigate incidents confidently.
The hard problem is not writing a policy once. It is making that policy hold across a changing fleet and proving that it did.
LangGuard’s perspective: governing the agent factory
The agent factory will not stand still. Builders will change models, adopt new harnesses, connect more tools, and introduce new inference infrastructure. Enterprise governance cannot depend on freezing those choices or rebuilding policy every time they change.
Governing this factory requires an AI-native, platform- and model-independent runtime layer for consistently enforcing enterprise policy.
AI-native means governing the connected agent system: the data entering reasoning, the tools and actions available, the authority passed to subagents, and the information retained in memory. Identity and access controls remain essential, but they do not alone determine whether each proposed action serves an authorized purpose.
Platform- and model-independent means the enterprise remains the source of policy. Its rules should not be redefined by the managed platform, execution harness, frontier model, open-weight model, or inference provider a team selects. Centralized policy must translate into consistent enforcement across supported environments.
Runtime means controls operate when they matter: before data enters a model’s context and before consequential actions execute. Model-driven decisions may be nondeterministic; authorization must be enforced outside the model’s discretion, using explicit policy and relevant enterprise context.
This is LangGuard’s role as an independent governance harness. It complements execution harnesses, platform guardrails, and enterprise identity and access systems, bringing a consistent policy framework to a fragmented agent estate. Named integrations, explicit coverage, and demonstrated enforcement are the proof.
The aim is to make agents governed by design without making the enterprise dependent on one way of building them.
The factory can keep changing. Enterprise policy must hold.
Research note: This is a qualitative market analysis grounded in provider documentation and announcements reviewed as of September 2, 2026. The taxonomy and projections are analytical judgments, not market-share estimates. Vendor inclusion does not imply a LangGuard partnership or a tested integration. Product availability and enforcement coverage should be verified for the specific deployment. Illustrations are editorial representations, not literal deployment architectures.