Managed Agent Platform vs. Build Your Own Stack: How to Decide in 2026

Why this is suddenly the central question

The decision matters now because agents have moved from experiment to line item. McKinsey's State of AI survey for 2026, based on 1,719 respondents, found that 62% of organisations are at least experimenting with AI agents, and that among companies with more than $1 billion in revenue, 40% now say they are scaling agents, up from 27% a year earlier. Yet the same survey is sobering about results: only about 39% report enterprise-level EBIT impact from AI, and just 6% qualify as "AI high performers." In other words, plenty of teams can stand up an agent; far fewer can run one that pays for itself.

That gap is almost never a model problem. The models are good enough. The gap is the surrounding work — integration, permissions, memory, monitoring, audit — and this is exactly the work that a managed platform does for you and that a self-built stack leaves on your plate. So "managed or build" is not really a technology question. It is a question about who does the unglamorous 80% of the job, how fast you need it done, and how much control you are willing to trade for speed. Our companion piece on where your AI agent should live in 2026 looks at the hosting side of the same decision.

What each option actually is

A managed agent platform is a single vendor product that bundles the pieces of an agent so you configure rather than build. Google's Gemini Enterprise Agent Platform is a clear example: it offers an Agent Runtime where agents can run asynchronously for up to seven days, a Memory Bank for persistent context, access to more than 200 models through Model Garden (including Google's own Gemini models, open-weight Gemma, and third-party models such as Anthropic's Claude), and a native Agent Identity system. Salesforce Agentforce is another, tightly wired into CRM data. You bring your use case and your data; the platform brings the plumbing.

A self-built stack means assembling those layers yourself. In practice that is a model API from one or more providers, an orchestration layer (a framework, a workflow tool such as n8n, or your own code), a set of tool and data connections — increasingly standardised on MCP — plus everything you add for identity, secrets, logging and evaluation. You own the architecture and can shape it exactly to your needs, and you also own every pager alert at 3 a.m. The two are not moral opposites; they are different points on a build-versus-buy curve, and most teams end up somewhere in between.

The comparison at a glance

The table below summarises the trade-offs that matter most when teams choose between the two. Read it as a set of dials, not a verdict: the right position on each dial depends on your volume, your team and your risk tolerance.

Notice that almost every row that favours the managed platform is about effort and safety, and almost every row that favours the build is about control and unit economics. That pattern is the whole decision in miniature.

Cost: read the whole bill, not the headline

Pricing is where managed platforms look cheapest and can end up most expensive. Agentforce is a useful worked example because its numbers are public. In 2026 it lists roughly $2 per conversation, Flex Credits at about $500 per 100,000 credits, and per-user licences from about $125 per month. Those figures sound approachable. The catch is what surrounds them: meaningful production use generally requires a Data Cloud subscription that starts around $108,000 per year, plus implementation services and knowledge-base setup before an agent does anything useful. The sticker is per-conversation; the real bill is a platform commitment.

A self-built stack inverts the shape of the cost. There is little to no platform fee, and at scale you pay close to wholesale for model tokens and infrastructure, which makes the marginal cost per run low and predictable. But you pay upfront and continuously in salaries: the engineers who build the orchestration, the identity and secrets handling, the evaluation harness, and the on-call rotation that keeps it alive. For a rough mental model, a managed platform is mostly variable cost with a big minimum; a self-built stack is mostly fixed cost with a low variable rate. The crossover point is volume.

The practical takeaway is to estimate total cost of ownership over a realistic horizon rather than comparing sticker prices. Our breakdown of AI agent total cost of ownership walks through the line items teams routinely forget, including evaluation, retries, human review and the cost of a bad answer reaching a customer.

Governance and identity: the part buyers underrate

If there is one capability that has separated 2026's managed platforms from a weekend project, it is identity. An agent that can act across your systems needs to be a first-class security principal, not a shared API key. Google's Agent Identity makes this concrete: each agent receives a unique, strongly attested cryptographic identity built on the open SPIFFE standard, delivered as a native IAM type, so you can grant least-privilege access and attribute every action to a specific agent. AccuKnox's AgentZ takes a similar posture from a different angle, bundling sandboxes, role-based access, runtime credential injection and audit traces so agents can be promoted from experiment to production — including on-prem and air-gapped deployments.

On a self-built stack, none of this arrives for free. You have to design scoped credentials, rotate secrets, log every tool call, and produce an audit trail that a security reviewer will accept. It is entirely doable, and open standards help, but it is a real project with a real owner — and it is precisely the work most pilots skip, which is why so many stall on the way to production. If your industry carries compliance weight, weigh this row heavily; a managed platform's built-in governance can be the deciding factor even when the raw compute is pricier.

How MCP changed the build side of the ledger

The case for building your own stack is stronger in 2026 than it was in 2025, largely because of the Model Context Protocol. What started as an Anthropic open-source project in late 2024 is now the common language agents use to reach tools and data: every major model provider supports it, there are thousands of public MCP servers, and in December 2025 the protocol was donated to a vendor-neutral foundation under the Linux Foundation, so it is governed as a community standard rather than one company's feature. The 2026 specification even moved toward a stateless architecture aimed squarely at deploying agent workloads at enterprise scale.

For a builder, that means the integration layer — historically the most tedious part of a DIY stack — is now largely a matter of pointing your agent at existing MCP servers instead of writing bespoke connectors. That genuinely lowers the cost and risk of building. But it is important to be precise about what MCP does and does not give you: it standardises tool access, not identity, memory, orchestration, evaluation or governance. Those layers are still yours to build and run. MCP narrows the gap between "buy" and "build"; it does not erase it. Our primer on what MCP is and why it matters covers the mechanics if you are new to it.

Lock-in: the cost you pay later

Lock-in is the row that looks free until you try to leave. A managed platform concentrates your agents, your prompts, your memory, your governance configuration and often your data inside one vendor's ecosystem. That concentration is exactly what makes it convenient — and exactly what makes migration expensive if pricing changes or the roadmap drifts away from your needs. The more of your workflow lives in proprietary constructs, the higher the wall around it grows.

A self-built stack has structurally lower lock-in: you can swap the model, move hosting, or replace a component without rebuilding the whole thing, especially if your tool layer speaks MCP. The price of that freedom is that you carry every upgrade and outage yourself. The pragmatic goal is not zero lock-in — that usually means zero leverage from anyone else's engineering — but bounded lock-in: keep the parts that define your business (data, prompts, evaluation, tool contracts) portable, and let the commodity parts be someone else's problem. If you want a deeper treatment, see our guide on how to avoid automation vendor lock-in.

A decision framework you can apply this week

Rather than a universal winner, use a short set of questions to place yourself on the curve. The more "yes" answers you have in a column, the more that column suits you.

Lean toward a managed platform when:

• You have no dedicated platform or MLOps team, and you do not want to build one for this.
• You need one or two agents in production in weeks, not quarters.
• Your volume is modest or spiky, so per-conversation pricing stays predictable.
• Governance, identity and audit are hard requirements you would rather buy than build.
• Your data already lives inside the vendor's ecosystem (for example, Agentforce on Salesforce data).

Lean toward building your own stack when:

• Your run volume is high and steady, so low marginal cost compounds into real savings.
• You have unusual requirements — bespoke tools, custom routing, specific models — that a platform constrains.
• Data residency, on-prem or air-gapped operation is a non-negotiable constraint.
• You have the engineering capacity to own identity, monitoring and evaluation properly.
• Avoiding lock-in is a strategic priority you are willing to pay for in effort.

1. Estimate volume first. Roughly how many agent runs per month at steady state? This single number moves the cost crossover more than anything else.
2. Cost both options over 18–24 months, including platform floors, model tokens, and the salaries a build would require. Compare totals, not stickers.
3. List your hard constraints — compliance, residency, existing data gravity — and mark any that a managed platform cannot meet.
4. Score the effort you can actually staff. A build you cannot operate is more expensive than any subscription.
5. Prefer the middle path when unsure: managed components on open standards, so today's choice does not become a five-year cage.

Common mistakes on both sides

The failure modes are predictable, and most are avoidable once you name them.

• Buying on the per-conversation number alone. The platform floor — data subscriptions, licences, implementation — often dwarfs the usage fee. Always price the whole commitment.
• Building the plumbing you could have rented. Reimplementing identity, memory and audit from scratch when a managed component would do is a classic way to burn a quarter for no product value.
• Treating a pilot as production. McKinsey's data shows the chasm between experimenting and scaling is wide; a demo that works once is not an agent that is integrated, permissioned, monitored and governed.
• Ignoring lock-in until renewal. The time to bound switching costs is at design time, not when the price list changes.
• Choosing by prestige, not fit. The biggest launch is not automatically the right platform for a five-person team or an air-gapped environment.

Where this is heading

The two paths are converging. Managed platforms are adopting the open standards that once made building attractive — MCP for tools, SPIFFE-style identity for security — which makes them less of a walled garden than they were. At the same time, self-built stacks increasingly lean on managed components for the hard parts, so a "build" today often means assembling rented pieces rather than writing everything from first principles. The result is that the decision is becoming less binary and more about which layers you own versus rent, and how portable you keep the layers that matter. That is good news: it means you can start on a managed platform to move fast, and migrate the parts that justify ownership as your volume and requirements grow, without repainting the whole picture.

Whatever you choose, the discipline is the same one that separates the 6% of high performers from everyone else in the survey data: treat the model as the easy part, and put your effort into integration, permissions, evaluation and governance. That is where agents earn their keep — or quietly fail to.

FAQ

What is the difference between a managed agent platform and building your own stack?

A managed agent platform is a single vendor product that bundles the model, runtime, memory, identity, permissions and audit logging for you, such as Google's Gemini Enterprise Agent Platform or Salesforce Agentforce. Building your own stack means assembling those pieces yourself from a model provider, an orchestration framework and tool connections, usually over MCP, so you own the architecture and the operational burden.

Is it cheaper to build your own AI agent stack or buy a managed platform?

At low volume a managed platform is usually cheaper because you pay per conversation or per credit and avoid engineering time. At high, predictable volume a self-built stack can be cheaper per run because you pay wholesale model tokens and infrastructure, but you take on the salaries and on-call time to run it. The crossover depends on volume, so estimate total cost of ownership, not just the sticker price.

How much does Salesforce Agentforce cost in 2026?

Agentforce in 2026 offers about $2 per conversation, Flex Credits at roughly $500 per 100,000 credits, and per-user licences from about $125 per month. The headline number is misleading on its own because production use generally requires a Data Cloud subscription that starts around $108,000 per year, plus implementation and knowledge-base setup.

What is agent identity and why does it matter for this decision?

Agent identity gives each agent its own cryptographic credential so it can be granted least-privilege access and every action it takes is attributable and auditable. Google's Gemini Enterprise Agent Platform issues these identities natively using the SPIFFE standard. If you build your own stack you must implement equivalent scoped credentials and audit trails yourself, which is one of the most underestimated parts of a DIY build.

Does MCP make building your own agent stack easier?

Yes. The Model Context Protocol has become the common way to connect agents to tools and data, with native support from every major model provider and thousands of public servers, and it is now governed as a vendor-neutral standard under the Linux Foundation. That lowers the integration cost of a self-built stack, but MCP does not give you identity, memory, orchestration or governance, so a build is still substantially more work than buying.

Which option has less vendor lock-in?

A self-built stack has less lock-in because you can swap models and hosting, but you own all the maintenance. A managed platform lowers effort at the cost of tying your agents, data and governance to one vendor's roadmap and pricing. A middle path is to build on open standards like MCP while using managed components you could replace, which keeps switching costs bounded.

When should a small business choose a managed platform?

A small business should usually choose a managed platform when it has no dedicated platform team, needs to ship one or two agents quickly, and its volume is modest enough that per-conversation pricing stays predictable. Building your own stack pays off later, when volume is high, requirements are unusual, or data residency and control are hard constraints.

Why do so many agent projects stall between pilot and production?

McKinsey's 2026 survey found most organisations are experimenting with agents but far fewer are scaling them, and only a minority report enterprise-level financial impact. The gap is rarely the model; it is the surrounding work of integration, permissions, monitoring and governance. Choosing between managed and self-built is really a choice about who does that work and how fast you need it done.