Related: sources · notes · metadata · Published Pieces

The Managed-Agent Trap

If agents are a feature, rent the platform. If agents are the company, build the substrate.

Managed-agent platforms are useful. They are also dangerous.

This is not a contradiction. It is the nature of platforms. A platform becomes useful by absorbing complexity. It becomes dangerous when the complexity it absorbs is the place where your product’s value lives.

The managed-agent pitch is straightforward: most companies do not want to own agent infrastructure. They do not want to run sandboxes, store traces, manage credentials, preserve transcript state, build memory systems, handle long-running jobs, debug tool calls, route to web browsers, support Slack or email or Teams, or figure out how to resume an agent after a VM dies. They want to supply an outcome and a budget, then let someone else make the machinery go.

For many companies, that is rational. If a legal team wants a first-pass marketing-copy reviewer, it does not want to build an agent runtime. If a sales organization wants account research, it does not want to build model routers and sandbox lifecycle management. If a large enterprise wants a supported way to deploy agents inside controlled workflows, a managed-agent platform may be the right choice. It turns an infrastructure problem into procurement.

But that is exactly why the category matters. Managed agents are not merely “tools.” They are an attempt to own the operational layer of agentic work: memory, state, tool access, credentials, sandboxes, event traces, workflow history, and evaluation loops. These are not neutral conveniences. They are the workflow substrate.

If your company’s core competency is not agents, buy the substrate. If your company’s core competency is agents, owning the substrate is the company.

This is the managed-agent trap.

Claude Code, Codex, OpenClaw, Hermes, and related systems expose different futures of AI work. Claude Code and Codex are strong coding surfaces: files, diffs, tests, terminals, tasks, PRs. OpenClaw and Hermes are rougher, but they explore the actual surface of the automatic computer: messaging ingress, local shell, browser use, skills, cron, plugins, memory, email, and long-running loops. They are chaotic probes into the right substrate.

Managed agents are the enterprise-safe version of that impulse. The lab says: do not assemble this yourself. Do not run a Mac Mini in a closet. Do not stitch together shell scripts, files, browser automation, and cron jobs. Use our platform. We have the model, sandboxes, memory, traces, safe defaults, and the runtime designed around how the model wants to work.

That is convenient. It is also lock-in.

The lock-in is not just pricing. The real lock-in is ontological. If you build on a managed-agent platform, your agents learn that platform’s primitives. Your memory takes that platform’s shape. Your tools conform to that platform’s interfaces. Your traces live in that platform’s observability model. Your evals reflect that platform’s assumptions. Your team’s habits become platform-shaped. Your product road map starts to ask what the lab will support next.

At first, this feels like acceleration. Later, it becomes jurisdiction.

The laboratory explanation is that model and harness are increasingly paired. Claude may perform best in a Claude-shaped environment. OpenAI models may thrive in a different environment. Gemini may want another. A model lab can plausibly say: if you want the best outcomes, use the runtime designed around our model.

This is partly true. It is also the logic of capture.

The more model and harness pair, the more the lab can claim that portability is a downgrade. The more memory, tools, sandboxes, and traces live inside the lab’s runtime, the harder it becomes to compose multiple models. The more the managed platform handles orchestration, the less your team learns to own orchestration. Eventually, the customer thinks they are buying capability, but they are renting their own nervous system.

For enterprises, this may be acceptable. Their goal is to automate known workflows under support contracts. For serious AI-native companies, the tradeoff is different. If your advantage lives in agentic runtime, memory, provenance, model routing, verification, artifact state, and orchestration, then outsourcing the substrate is strategically incoherent.

No single lab will own every capability. One model may be better at coding, another at long-context synthesis, another at cheap high-throughput inference, another at speech, another at video, another at local private inference. The future is heterogeneous.

A serious runtime must route across these systems without surrendering canonical state. It must own the artifact graph, memory layer, credentials, events, traces, rollback, verifiers, and cost controls. Models should be powerful suppliers. They should not be sovereigns.

There is nothing wrong with buying convenience. There is something wrong with mistaking convenience for architecture.

The managed-agent trap is not that managed agents are bad. It is that they are good enough to make teams forget what they are giving up.

A company that uses agents as an add-on should consider managed agents. A company whose future depends on agentic systems should own the runtime.

If agents are a feature, rent the platform.

If agents are the company, build the substrate.