Most enterprise agent budgets are spent on the wrong layers. The pieces teams argue about for six weeks — which orchestration framework, which vector database — cost almost nothing and can be swapped in a sprint. The pieces they defer to phase two — agent identity, and a trace that survives the hop into a tool call — are where the money actually goes and where the incidents come from.
Gartner's June 2025 forecast that over 40% of agentic AI projects will be canceled by the end of 2027 names three causes: escalating costs, unclear business value, and inadequate risk controls. Two of those three are stack decisions. This is the map.
Every price below was read off the vendor's own pricing page on 23 August 2026, and normalised against one workload so the numbers are comparable: 200 production agents, 2 million agent steps per month, 50 engineers building them, 10 million embedded documents, one cloud region.
Rent One Layer, Own Two, Buy Two, Skip Three
| # | Layer | What it does | Leading options | Verdict | Cost at the baseline |
|---|---|---|---|---|---|
| 1 | Model + inference | Produces the reasoning and the tool calls | OpenAI, Anthropic, Google; Bedrock / Foundry / Vertex as the front door | Rent. Never the differentiator | Usage-based; the largest line by far |
| 2 | Orchestration + durable state | Runs the loop, holds state, retries, isolates code | LangGraph, Microsoft Agent Framework, Google ADK, CrewAI, Temporal, E2B | Own it. Open source, no licence | $0 framework; ~$400–700 for durable execution and sandboxing |
| 3 | Tool connectivity (MCP) | Lets the agent touch your systems | MCP + a gateway (Cloudflare, Kong, LiteLLM) | Own it. A protocol, not a purchase | ~$0 |
| 4 | Retrieval + memory | Supplies the context the model lacks | pgvector, Pinecone, Qdrant, Weaviate, Mem0 | Skip the product. Use pgvector | ~$20 storage if you buy; $0 if you don't |
| 5 | Identity + authorization | Decides what the agent is allowed to do | Auth0 / Okta, Entra Agent ID, Ping | Buy. The layer with no free tier that works | ~$1,200 |
| 6 | Runtime control (gateway + guardrails) | Filters, rate-limits, kills | Cloudflare AI Gateway, Kong, Bedrock Guardrails, NeMo Guardrails, Lakera | Skip the standalone vendor. Do it at the gateway | ~$0–500 |
| 7 | Evals + observability | Tells you what the fleet actually did | LangSmith, Langfuse, Braintrust, Arize | Buy — but read the meter | ~$250 to $1,950+, same workload, different meters |
| 8 | Control plane / registry | Inventories and governs the fleet | Microsoft Agent 365, ServiceNow AI Control Tower | Skip until ~50 agents | $30,000/mo at 2,000 sponsored users |
The three skips are layers 4, 6 and 8. None of them are bad products. All three are things you can defer at low cost and adopt later without a migration — which is exactly the test that matters when the technology underneath is changing every quarter.
Layer 1 and 2: You Rent the Model and Own the Loop
The model is a commodity input and the orchestrator is your actual codebase. Treat them the opposite way round and you will spend a quarter migrating a framework while your model bill triples unnoticed.
Three orchestration frameworks are credible for enterprise work in 2026, and the honest way to choose between them is by which cloud already has your data.
LangGraph is the default if you have no other constraint. It models an agent as an explicit graph with checkpointed state, which is the shape you want when a human has to approve step 7 of 12. It is also the safest default for hiring — though that is a judgement about the market, not a measured fact.
Microsoft Agent Framework is the answer for a .NET shop. Microsoft's own documentation describes it as "the direct successor" to Semantic Kernel and AutoGen, "created by the same teams," combining "AutoGen's simple abstractions" with Semantic Kernel's "session-based state management, type safety, filters, telemetry." That merge matters: if you built on either predecessor, you have a documented migration path rather than a rewrite. Note that the Go implementation is still in public preview, with declarative agents, RAG and functional workflows not yet available — so Go teams should read that as a 2027 option.
Google ADK covers the widest language surface — Python, TypeScript, Go, Java and Kotlin — and ADK's own documentation is explicit that it "can work with almost any generative AI model" and deploys to your own infrastructure or to Cloud Run and GKE, "all without requiring you to change a single line of your agent code." If you have Java services and a Google Cloud footprint, this is the least-friction path.
Who should not pick each: skip LangGraph if your engineering org is .NET-first and has no Python on-call rotation — you will be maintaining a language boundary for no benefit. Skip Microsoft Agent Framework if you are not on Azure; its value is the integration, and you are paying the coupling cost without the payoff. Skip Google ADK if you have one Python team and one use case — the multi-language surface is overhead you will not use. Skip CrewAI for anything with a compliance reviewer; role-playing crews are hard to explain to an auditor who wants to see the decision path. And skip Pydantic AI only if you do not care about typed tool signatures, which almost no enterprise team should admit to.
The layer people forget here is durable execution. An agent that runs for 40 minutes across 12 tool calls is a workflow, and workflows need to survive a pod restart. Temporal Cloud publishes Actions at "$50" per million for the first paid band, active storage at "$0.042 GBh," and plan minimums "Starting at $100/mo" for Essentials. At our baseline that is a few hundred dollars a month to stop losing half-finished agent runs. It is the cheapest reliability you can buy in this entire stack.
The other thing that belongs here and gets deferred is execution isolation. If your agents write and run code — and coding agents are the highest-value deployment most enterprises have — that code must not execute on a host with your production credentials in its environment. E2B publishes 2 vCPU at "$0.000028/s" and RAM at "$0.0000045/GiB/s" on a "$150 /mo" Pro plan, per its pricing page. Run the numbers at our baseline — say 400,000 code executions of 20 seconds each on 2 vCPU and 2 GiB — and it is roughly $300 a month of compute. Three hundred dollars to keep arbitrary generated code off your infrastructure is not a decision that needs a business case. Daytona and Modal are the same argument with different ergonomics.
Layer 3: MCP Is a Protocol, Not a Product
The Model Context Protocol is now the connective tissue of the stack, and it is free — which is why nobody budgets for the part of it that costs money. The current protocol revision is 2026-07-28, and MCP now uses per-request version negotiation rather than a session handshake, with a mandatory server/discover RPC that returns a server's supported versions and capabilities in one call.
Here is the fact that should change how you budget this layer. In that current revision, the authorization specification still opens with: "Authorization is OPTIONAL for MCP implementations." Servers on STDIO transport "SHOULD NOT" follow the spec at all and instead "retrieve credentials from the environment."
Read that again with your CISO's eyes. The protocol at the centre of your agent stack does not require authentication, and its most common local transport explicitly tells implementers to pull credentials from environment variables. When the spec is followed it is genuinely strong — OAuth 2.1, PKCE, mandatory RFC 8707 resource indicators, and an explicit ban on token passthrough — but "when followed" is doing all the work.
What you actually deploy at this layer is a gateway in front of your MCP servers: one place that terminates auth, enforces an allowlist of which servers exist, and logs every tool call. Cloudflare AI Gateway states its "core features available today are offered for free," including analytics, caching and rate limiting, with 10,000,000 logs per gateway on Workers Paid and Logpush at "10 million / month, +$0.05/million." Kong AI Gateway is the answer if you already run Kong for your APIs and want one policy plane. Either way this layer costs roughly nothing, which is the strongest possible argument for not skipping it.
Layer 4: Start With pgvector and Do Not Move Until You Can Name the Bottleneck
Skip the dedicated vector database. At 10 million documents, pgvector inside the Postgres you already run is not a compromise — it is the correct answer, and the reason has nothing to do with price.
The price argument actually cuts the other way, which is worth saying plainly. Ten million vectors at 1,536 dimensions is roughly 61 GB, and Pinecone's Standard tier charges "$0.33/GB/mo" for storage against a "$50/month min. usage," with reads at "$16–$18 per million" read units. That is about twenty dollars of storage. Nobody is skipping Pinecone to save twenty dollars.
You skip it because you now operate two databases that cannot join to each other, cannot participate in the same transaction, and drift the moment a row is deleted in one and not the other. Every enterprise RAG post-mortem eventually contains the sentence "the index was stale." A dedicated engine earns its operational surface somewhere in the low tens of millions of vectors, when HNSW index rebuild times start dominating your maintenance window — and at that point Qdrant or Pinecone's BYOC tier, which runs "in your cloud account" with "zero-access operations," is a clean migration, because embeddings are portable in a way that application state is not.
Who should not skip it: if you are doing multi-tenant retrieval with hard isolation per customer, or you need sub-50ms p95 at hundreds of QPS today, buy the dedicated engine now. Retrofitting isolation into a shared Postgres index is worse than the second database ever was.
The related trap is memory. Agent memory products like Mem0 solve a real problem, but most teams reaching for one have not yet written down what they want remembered. Conversation state belongs in your orchestrator's checkpointer. Buy a memory product when you can articulate a retention policy for it — not before, because "remember everything" is a data-subject-access-request problem wearing a feature's clothes.
Layer 5: Identity Is the Layer Nobody Owns and You Cannot Skip
This is where the budget should go, and it is the layer most stacks are still missing entirely. An agent is a non-human principal that acts continuously, holds long-lived credentials, and — unlike a service account — decides at runtime which systems to touch. Your existing IAM has no model for that.
The credible options are all extensions of identity platforms you already own. Okta's Cross App Access is "an OAuth extension that makes it easier to support secure, controlled integrations at scale," positioned as "the recommended way to connect to MCP servers in the enterprise," with "25+ early adopters including Anthropic, Zoom, and Slack." The problems it names are exactly the ones agent teams hit: "Over-permissioned agents can trigger unintended actions and data exposure" and "Shared credentials and embedded tokens lead to security and continuity risks."
Pricing here is unusually legible for once. Auth0's pricing page lists an AI Agents add-on that "Adds 50% to the base price (rounded up to the dollar)" — so a B2B Professional tenant at 500 MAUs goes from $800/month to $1,200 with agent identity included, and the add-on itself lists "Unlimited Token Vault" and "All forms of CIBA." Roughly $1,200 a month to stop your agents sharing a service account is the best-value line item in this entire document.
Who should not buy which: Okta for AI Agents is the wrong choice if your workforce identity already lives in Entra and your agents are Copilot Studio agents — you would be running two agent-identity systems to solve one problem. Conversely, Entra Agent ID is the wrong choice if a meaningful share of your agents run outside Microsoft's runtime, because the governance story is much thinner at the edges. Ping remains the answer for organisations with heavy on-premises federation that is not moving.
Layer 6: Do Guardrails at the Gateway, Not in a Separate Product
Skip the standalone guardrails SaaS. Not because guardrails are optional — they are not — but because the enforcement point you need already exists at layer 3, and a guardrail that sits somewhere other than the chokepoint is decoration.
A guardrail is a deterministic control that blocks a class of action outright, and it is a different thing from an evaluation, which scores quality after the fact. The minimum viable set is small: input PII detection, output filtering, a tool-call allowlist, and a kill switch that a duty manager can hit without a deploy. Every one of those is a gateway feature. Cloudflare bills its guardrails as Workers AI token-based inference on top of a free gateway; AWS offers Bedrock Guardrails inside the model runtime you are already calling; NVIDIA's NeMo Guardrails is open source.
The case for buying a specialist like Lakera is narrow and real: you want a dedicated prompt-injection classifier with a latency budget tight enough to sit inline on every request, and you want somebody else maintaining the detection models. That is a genuine reason. It is not a reason for the much larger group of teams who have not yet turned on the free controls sitting in the gateway they already pay for.
The loser in this layer is the compliance-dashboard product — the tools that generate a policy document and a risk register but sit outside the request path. They produce an artifact an auditor accepts and stop exactly zero agent actions. If a control cannot block a tool call, it is reporting, and you should buy it from your GRC budget rather than your platform budget.
Layer 7: Evals and Observability, Where the Meter Surprises You
This is the layer where identical workloads produce wildly different bills, because the three leading vendors meter three different things. At our baseline the same 2 million agent steps costs anywhere from a few hundred dollars to comfortably over $2,000 a month depending only on which pricing model you signed — and one of the three will not tell you its overage rate until you ask.
LangSmith meters seats plus traces. Its pricing page lists Plus at "$39 / seat per month" with "Up to 10k base traces / mo, then pay-as-you-go," and reserves hybrid and self-hosted deployment for Enterprise. At 50 engineers the seat line alone is $1,950/month before a single trace is stored — and the published page does not state the per-trace overage rate at all, only that usage is billed "then pay as you go thereafter." A pricing page that will not print its own overage rate is a procurement finding, not a footnote. Ask for it in writing before signing.
Langfuse meters ingestion units and includes unlimited users on every paid tier. Its pricing page lists Core at $29/month and Pro at $199/month with 100k units included, then graduated overage at "$8.00/100k (100k–1M), $7.00/100k (1M–10M), $6.50/100k (10M–50M)." Compare these carefully: a Langfuse "unit" is one ingested observation, not one agent run. A 10-step agent emits ten or more units, so 2 million agent steps is well over 20 million units — roughly $1,550/month all-in, for fifty engineers, against a $1,950 seat line that has not yet counted any data. And Langfuse is open source and self-hostable for free, which caps your downside.
Braintrust meters neither. Its pricing page shows Pro at "$249 / month" with "50k scores" and "5 GB processed data" included, overage at "$1.50/1k" scores and "$3/GB," and unlimited users on every tier including the free one. Your bill scales with how much you evaluate, not how much you run — which is the right shape if evals are the point and the wrong shape if you mostly need production tracing.
Who should not pick each: skip LangSmith if you have more engineers than you have traces, because you are buying seats to watch a system that is barely running. Skip Langfuse if you need a vendor to own your compliance posture and you do not want to operate ClickHouse — self-hosting is free until it is your on-call rotation. Skip Braintrust if your problem is "what did the agent do at 2am" rather than "is this prompt better than that one"; it is an evaluation platform that also traces, not the reverse.
One structural note that should shape a five-year decision: the OpenTelemetry GenAI semantic conventions are still marked Development, not Stable, and the GenAI conventions have been moved into a dedicated repository. Attribute names can still change. Instrument with OTel anyway — it is the only path that does not lock your traces inside one vendor — but budget for a rename pass, and do not let a vendor tell you their proprietary SDK is the safe choice because the standard is moving. The standard moving is precisely why you want to be on it.
Layer 8: Skip the Control Plane Until You Have Fifty Agents
A fleet control plane is the right product at the wrong time for almost everyone reading this. Microsoft Agent 365 went generally available on 1 May 2026 at "USD15 per user per month" or bundled into Microsoft 365 E7, and it is a genuinely coherent product — a unified registry, Entra network controls extended to Copilot Studio and local endpoint agents, and Defender and Intune integration for agent discovery.
Read the licensing unit carefully, because it is not what people assume. Microsoft states that "Each Agent 365 license covers an individual who manages or sponsors agents, or uses agents to do work on their behalf." That is per person, not per agent. If 2,000 of your employees have work done on their behalf by an agent — which is the entire point of deploying agents — that is $30,000 a month, $360,000 a year, to inventory a fleet of 200. Roughly $1,800 per agent per year for a registry.
At 200 agents that math is defensible. At the handful most enterprises actually have in production today, it is not, and the honest answer is a spreadsheet and a naming convention until the fleet outgrows them. Microsoft Agent 365 becomes correct when you can no longer answer "how many agents do we run and who owns each one" from memory — call it fifty. Buy it then, and buy it having already deployed layer 5, because a registry that inventories agents with no distinct identities is a list of names.
How the Layers Fail Together
Every layer above can be individually healthy while the system is broken, because agent failures happen at the seams. Four of them, in the order you will meet them.
The arithmetic is not on your side. Reliability compounds multiplicatively across steps: at 95% per-step success, a ten-step agent completes about 60% of the time; at 90%, 35% — assuming step failures are independent and nothing retries, which is precisely what the durable execution in layer 2 buys back. Your eval layer measures per-step accuracy and reports something reassuring. Your users experience per-task completion and report something else. A July 2026 decomposition of a production enterprise agent found the full system beat its frontier base model by "+11.0 percentage points on SpreadsheetBench (91.25% vs 80.25%, n=400, p<0.001)" and roughly 15 points on GAIA — but attributed most of that gain to scaffolding, routing and specialist models rather than to verification, whose isolated contribution was "+1.5 points." Take the interest into account: it is a non-peer-reviewed preprint from the team behind the commercial agent it measures, covering one system on two benchmarks. On that evidence — as a worked example, not a general law — the reliability you want comes mostly from layer 2, which you build, not from a product you can purchase.
Identity leaks through the tool layer. Your identity platform authenticates the human beautifully. Then the agent calls an MCP server that, per the spec, need not check anything at all — and which, on STDIO, is told to read credentials from the environment. The token in that environment is usually a developer's or a shared service account's, scoped to everything. So layer 6 is diligently filtering text while layer 3 holds full database credentials. This is the single most common gap in stacks that look complete on a slide.
Untrusted output reaches trusted tools. OWASP's write-up on MCP tool poisoning puts the mechanism exactly: "Tool descriptions are reviewed once, when the agent first connects to a server. Tool responses go straight into the LLM context with no equivalent check." And the consequence: "A response from an untrusted external server can trigger calls to trusted internal tools." Academic work published in March 2026 that threat-modelled seven major MCP clients found most had "significant security issues...due to insufficient static validation and parameter visibility." Your allowlist governs which servers connect. Nothing governs what those servers say once connected.
The trace breaks at every boundary. The gateway logs the model call. The orchestrator logs the graph. The MCP server logs nothing. Because the GenAI conventions are still Development-stage, none of those three share a correlation ID unless you made them. During an incident you will have three partial stories and no way to join them — which is how a two-hour investigation becomes a two-day one. Fix this before you need it: propagate one trace ID from the orchestrator through the gateway into every tool call, and make that a code-review requirement rather than a wish.
What Actually Predicts Regret
The criteria that separate a stack you keep from one you rip out are not the ones on the evaluation matrix.
This week: Pick the orchestration framework by which cloud holds your data, and stop the debate. Then write down, per agent, which credential it uses to reach production systems. If the answer for any agent is "a shared service account," you have found your first quarter's real project.
This month: Put a gateway in front of every MCP server and turn on the free controls — allowlist, rate limit, tool-call logging. Propagate one trace ID end to end. Instrument with OpenTelemetry even though the conventions are unstable, and accept the rename pass as the cost of not being locked in.
Before Q4 close: Buy the identity layer. Roughly $1,200 a month is the cheapest risk reduction available anywhere in this stack, and it is the one purchase here that gets harder, not easier, the longer you wait — because retrofitting distinct identities onto 200 agents already in production means touching 200 deployments.
What changes the answer: a hard multi-tenant isolation requirement moves you to a dedicated vector engine on day one. A .NET-only engineering org makes Microsoft Agent Framework correct regardless of everything else. A regulated workload with a named auditor makes durable execution and a full tool-call audit trail non-negotiable rather than nice. And a fleet past fifty agents flips the control plane from indulgence to necessity.
The Bottom Line
The agent stack in 2026 rhymes with the Kubernetes stack in 2017. The orchestrator became free and boring, exactly as it should have. The distribution vendors sold control planes to teams running six workloads. And the organisations that came through it well were the ones that got identity, policy and telemetry right early — while everyone else was still arguing about the scheduler.
The frameworks are commodities. The models are rented. What you own is the loop, the trace, and the answer to the question your auditor will eventually ask: which agent did this, under whose authority, and can you prove it?
Spend accordingly. The cheapest layer in this stack is the one that stops the incident.
Continue Reading
- The Build-to-Buy Spectrum: 5 Tiers for Enterprise AI Agents
- LangGraph vs Google ADK: Which Enterprise AI Framework Wins?
- Ping vs Okta vs Entra: Best AI Agent Identity in 2026?
- Why 88% of AI Agents Die in Production: The $14B Fix
- MCP vs LangChain vs OpenAI Functions: Which for Enterprise?
- AI Agent Harness Pricing: Hidden Infrastructure Costs
- Your AI Agents Need Identity Management Before They Need You