The announcement cycle has shifted. A year ago, the new thing was a more capable chat model. Then it was tool use and function calling. Now it is managed agents — pre-built, vendor-hosted systems that take a goal, plan a sequence of steps, call tools, and report back with results. Anthropic’s Managed Agents, Google’s agent runtime, OpenAI’s Assistants and its successors, and a crowded long tail of startup offerings all promise the same thing: the productive part of an autonomous AI workflow, without the engineering cost of building one.
For enterprise leaders watching this wave, the question is the same one that surfaced with every prior category of enterprise software: build our own, buy a managed service, or orchestrate across both? We have written before about the framework for build versus buy in general software. Agents add a new dimension, because the decision is not only about cost and differentiation. It is also about where the intelligence lives — and therefore where the risk, the data, and the long-term leverage live.
What a managed agent actually is
Strip the marketing away and a managed agent offering usually includes four things: a hosted planning loop (the model that decides what to do next), a tool registry (the catalog of functions the agent can call), a memory and state layer (so the agent remembers what it did across steps), and a supervision and observability layer (so you can see what happened, intervene, and audit later).
Building these four things yourself is not impossible. Every serious AI platform team has built at least a rough version. But each of them is a non-trivial engineering commitment on its own, and together they are the difference between a demo that works in a notebook and a production system that runs reliably at three in the morning when a tool call times out halfway through a multi-step task.
This is why managed offerings are getting traction. They are not selling the model. They are selling the plumbing around the model.
The three postures
Build
You own the agent framework. You write the planning loop, you register the tools, you manage memory, you build observability. The model vendor becomes one component among several, and you can swap it without rewriting your agent layer.
Correct when the agent is core to how you deliver value and the workflow is specific enough that no off-the-shelf framework models it naturally. A fintech compliance engine that reviews transactions against internal policies, calls proprietary risk services, and files regulatory reports is probably a build. The specific tool graph and the data sensitivity do not map cleanly to a generic agent product, and the investment compounds because the framework gets reused across adjacent workflows.
Cost profile: high upfront, moderate ongoing, maximum flexibility. Realistic timeline for a first production deployment: three to six months with a capable platform team.
Buy (managed)
You use a vendor’s managed agent runtime. The planning loop, state, and observability come pre-built. You configure tools, connect data sources, and deploy. The vendor operates the system. You operate the configuration.
Correct when the workflow is general-purpose and not a source of competitive differentiation — internal research assistants, meeting-notes summarization with calendar and document access, internal support triage, developer productivity helpers. The value is in deploying quickly, not in owning the agent platform.
Cost profile: low upfront, usage-based ongoing, limited flexibility. Realistic timeline to first production deployment: weeks. The risk profile is not zero, though. You are pushing intermediate reasoning state — which often contains the sensitive parts of your queries — through a vendor’s infrastructure. And when the vendor updates the planning model, your agent’s behavior can shift in ways you only discover in production.
Orchestrate
You maintain a thin internal orchestration layer that can route individual workflows to either a managed agent service or to internal agents, depending on the workload. The layer owns identity, policy enforcement, logging, and cost accounting; the agents underneath can be a mix.
Correct at scale, once you have more than a handful of agent-based workflows in production and the cost of running everything on one vendor, or rebuilding everything in-house, has become visible. Orchestration gives you the ability to put sensitive workflows on internal agents while keeping general ones on a managed runtime, and to switch vendors behind the layer without asking the consuming teams to change anything.
Cost profile: moderate upfront on the layer, variable ongoing depending on where workloads land, maximum strategic flexibility. Realistic timeline: this is rarely a first step. It is the posture you migrate to once your first build or buy decision has run for a year and the constraints have become obvious.
The deciding questions
Before debating the three postures, answer four questions about the specific workflow you have in mind. The answers usually resolve the debate.
How sensitive is the data the agent will touch?
If an agent reasons over customer personal data, contracts, source code, or financial records, the intermediate reasoning traces are themselves sensitive. A managed agent often logs those traces on vendor infrastructure for a period of time. Some vendors offer zero-retention modes; many do not. If your compliance posture cannot accept vendor-side logging of reasoning state, the managed option narrows sharply, and build becomes the realistic path regardless of cost.
How bespoke is the tool graph?
Count the tools the agent needs to call. If most of them are generic — web search, calendar, document store, email — a managed agent is probably enough. If more than a third are internal services with non-standard interfaces, authentication requirements, or rate-limit behaviors that need careful handling, the managed option starts to creak. You end up writing and maintaining a large adapter layer, and at that point you have already paid most of the cost of building the agent yourself.
How critical is reproducibility?
Managed agents update their planning models on the vendor’s schedule. For an internal research helper, slight behavior drift between versions is tolerable. For an agent that makes customer-visible decisions, fills regulatory forms, or calculates anything downstream systems rely on, drift is a liability. Build gives you the ability to pin a model version and roll forward on your schedule. Buy means accepting that a model you never asked to change will get smarter, stranger, or simply different one day.
How likely is this workflow to proliferate?
One agent in production is a pilot. Ten agents in production is an operations problem. If the organization’s realistic two-year view includes many agent-based workflows, some sensitive and some not, the orchestration posture becomes attractive earlier than the cost curve alone would suggest. The decision is not per-workflow; it is about where the platform boundary lives across the whole portfolio.
A pragmatic sequence
For most mid-market and enterprise organizations we work with, the correct sequence is not “pick one of the three and commit.” It is a staged path that starts small, learns fast, and preserves optionality.
Start with buy for the first one or two workflows, on an uncontroversial internal use case. The goal is not to ship the flagship agent. The goal is to learn how agents fail, how they get measured, what they cost, and what your governance process actually needs to look like.
Build selectively for the second or third workflow, once a differentiation or compliance reason has made the case. By this point your team has operational scar tissue from the first deployments and knows what to build.
Orchestrate once you have three or more workflows in production across at least two sources. The orchestration layer pays for itself the moment the cost of maintaining separate governance per vendor exceeds the cost of maintaining one thin layer.
The organizations that get into trouble with agents are usually the ones that skipped stage one and tried to build their own platform before anyone had run a real production agent for six months. The ones that get stuck are usually the ones that stayed in stage one too long and ended up with a sprawl of agents on three different managed vendors with no common policy layer.
The broader point
Managed agents are a genuinely useful development. They compress the cost of getting a first agent into production from months to weeks. They are also not, by themselves, a strategy. The strategic decision is where the reasoning, the data, and the control plane live over the next three years — and that decision is the same one enterprises have made about every prior category of infrastructure: build the differentiating parts, buy the commodity parts, and be honest about which is which.
The build-versus-buy question does not get easier when intelligence becomes part of the stack. It gets more consequential. The companies that reason about it clearly now will spend the next three years shipping. The ones that let the vendor announcement cycle drive their architecture will spend the next three years migrating.
Top comments (0)