Platform or Framework? The Strategic Fork Every Agent Builder Hits

Table of Contents

• The Distinction That Actually Matters
• What You Get From a Framework
• What You Get From a Platform
• The Decision Framework I Actually Use
• Where Does Your Defensibility Live?
• The Reliability Tax
• The Economics Under Per-Outcome Pricing
• The Lock-In Question Nobody Asks Early Enough
• Why Most GaaS Companies End Up Hybrid
• A Migration Path That Doesn't Hurt
• Insights Most People Overlook
• References

The Distinction That Actually Matters

People throw "platform" and "framework" around as if they're interchangeable marketing words. They aren't, and the difference determines who owns the pager at 3 a.m.

A framework is code you import. LangGraph, the OpenAI Agents SDK, CrewAI, Google's ADK, Pydantic AI, these give you primitives for defining agent loops, tool calls, state graphs, and handoffs. You assemble them, you deploy them somewhere, and you own everything downstream: the servers, the retries, the queue when an agent runs for nine minutes, the dashboard when a customer asks why their task failed.

A platform is a managed service you deploy into. Think LangGraph Platform, Vertex AI Agent Engine, Bedrock AgentCore, or the growing tier of agent-runtime startups. You hand over an agent definition and the platform handles execution, scaling, persistence, observability, and often human-in-the-loop checkpoints. You trade control for not having to build the boring, hard 70% that has nothing to do with your agent's actual intelligence.

The trap is treating this as a binary. In practice almost every platform is built on a framework, and almost every serious framework deployment eventually grows platform-like scaffolding around it. The strategic question isn't "which religion," it's "which layer do I want to own, and why."

What You Get From a Framework

Control, mostly. When the agent's reasoning logic is the thing customers pay for, a vertical agent that does medical prior-authorization, or a coding agent with a proprietary planning loop, you do not want a managed runtime quietly truncating your context window or imposing its own retry semantics on a tool call that charges a customer's card.

Frameworks also give you portability in principle. Your LangGraph state machine doesn't care whether it runs on your own Kubernetes cluster, a Lambda, or a durable-execution engine. That decoupling is real and valuable, and it's the main reason teams with strong infra muscle start here.

The cost is everything that isn't the agent. You'll build or buy: a durable execution layer so a crashed worker doesn't lose a half-finished task, an observability stack so you can see why an agent looped, state persistence so a conversation survives a redeploy, rate-limiting and policy at the gateway, and sandboxing so a tool-using agent can't rm -rf its way through your environment. None of that is glamorous. All of it is required before you can charge money. Anthropic's own guidance on building effective agents is blunt about this: the wins come from simple, composable patterns plus relentless operational discipline, not from a clever framework abstraction.

What You Get From a Platform

Speed to revenue, and somebody else's on-call rotation.

A platform collapses the unglamorous 70% into a config file. Durable execution, autoscaling, tracing, checkpointing, identity, handled. For a team of four trying to ship a per-task agent before their runway expires, that's not a convenience, it's survival. The managed-vs-self-hosted tradeoff has a long history in cloud, and the agent layer is rerunning it at speed.

You also get reliability primitives you'd otherwise spend a quarter building. Retries with backoff, fallbacks across models, circuit breakers when a downstream tool degrades, mature platforms ship these by default. If your team has never run a stateful, long-running distributed system before (and most agent teams haven't), inheriting battle-tested infrastructure is a genuine de-risking move, not a cop-out.

What you give up: depth of control and a clean exit. Platforms make opinionated choices about how state is stored, how context is managed, and how observability data is exposed. When those opinions collide with your product needs, say, you need sub-200ms tool-calling latency and the platform's orchestration adds 400ms of overhead, you're stuck negotiating with someone else's roadmap. McKinsey's work on why agentic AI stalls before it reaches production keeps landing on the same culprit: the gap between a demo and a reliable production system is operational, and platforms are most attractive precisely because they pre-pay that operational cost.

The Decision Framework I Actually Use

Skip the feature-matrix spreadsheet. Three questions get you most of the way.

Where Does Your Defensibility Live?

If your moat is the agent's logic, a hard-won planning loop, proprietary tools, domain-specific evaluation, you want a framework, because you can't differentiate on something you've outsourced to a managed black box. If your moat is the workflow around the agent (distribution, data, brand, an integration nobody else has), then the agent is plumbing and a platform lets you stop caring about plumbing. Builders who get this backwards waste months hand-rolling infrastructure to support a commodity agent, or wrapping a managed platform around logic so distinctive it deserved bespoke handling.

The Reliability Tax

Per-task and per-outcome GaaS pricing changes the reliability math entirely. When you bill per resolved ticket rather than per seat, a flaky agent doesn't just annoy the customer, it directly torches your margin, because you eat the cost of every retry, every escalation, every wrong answer that triggers a refund. Frameworks make you build reliability; platforms rent it to you. Ask honestly: does your team have the SRE depth to build retries, fallbacks, and circuit breakers correctly under load? If the answer is "we'll figure it out," that uncertainty has a price, and a platform is often cheaper than paying it in outages.

The Economics Under Per-Outcome Pricing

Run the unit economics at scale, not at demo volume. Frameworks have near-zero marginal licensing cost but high fixed engineering cost and whatever your raw infra bill is. Platforms invert that: low fixed cost, but a per-execution or per-seat fee that compounds with usage. There's a crossover point. Below it, the platform is obviously cheaper. Above it, and high-volume GaaS gets there fast, the platform's per-execution fee can quietly become your largest line item after inference itself. Andreessen Horowitz's analysis of how AI agents are reshaping software economics is a useful frame here: the value is migrating from the application to the agent layer, which means whoever controls that layer captures the margin. A platform fee is you renting margin you might want to own.

The Lock-In Question Nobody Asks Early Enough

Every platform pitch undersells switching costs, so price them yourself before you sign.

Framework lock-in is real but soft. Migrating from CrewAI to LangGraph is annoying, you rewrite orchestration glue, but your prompts, tools, and evals largely survive, and emerging interoperability standards like the Model Context Protocol are making tool definitions increasingly portable across stacks. Platform lock-in is harder, because the platform owns your runtime state, your traces, your checkpoints, and your operational habits. The day you want to leave, you're not just porting code, you're rebuilding everything the platform did silently on your behalf, and your team has atrophied the muscle to do it.

The pragmatic hedge: keep your agent logic in a framework even when you run it on a platform. Many platforms support exactly this, bring your LangGraph or ADK graph, let the platform host it. That arrangement keeps the portable thing portable and rents only the infrastructure, which is the part you actually wanted to outsource. It's the closest thing to having it both ways.

Why Most GaaS Companies End Up Hybrid

Watch what mature agent companies do, not what they say in keynotes, and a consistent pattern emerges.

They prototype on a platform or a high-level framework to find product-market fit fast. Then, as volume grows and unit economics start to bite, they pull the highest-cost or most-differentiated paths down to a framework they control, usually the hot path that runs millions of times, while leaving the long tail of low-volume, low-stakes agents on the managed platform where convenience outweighs cost. It's the same arc as compute: start on managed, repatriate the expensive predictable workloads, keep the bursty unpredictable ones in the managed tier.

This is the answer the platform-vs-framework framing obscures. It's rarely either/or at the company level. It's a portfolio decision made path-by-path, and the teams that win treat their orchestration layer as something they tune over time rather than a one-time religious commitment.

A Migration Path That Doesn't Hurt

If you start on a platform and suspect you'll outgrow it, architect for the exit on day one. Keep agent definitions in framework code, not platform-proprietary config. Log your traces to a standard sink you also control, not just the platform's dashboard. Treat the platform as a runtime host, not as the place your business logic lives.

If you start on a framework and the operational load is crushing your small team, the cheapest move is rarely a full platform migration, it's adopting a managed durable-execution engine or a managed observability layer for just the parts that hurt, keeping your orchestration where it is. You don't have to swallow a whole platform to get one capability from it. The market has unbundled enough that you can buy reliability, or state, or tracing as discrete pieces, which is exactly what the hybrid winners do.

The strategic choice, then, isn't a fork you take once. It's a dial you set per workload and adjust as your volume, margin, and team evolve. The builders who treat it that way ship faster early and pay less later. The ones who treat it as identity, "we're a framework company" or "we're all-in on the platform", end up defending a decision long after the economics stopped agreeing with it.

Insights Most People Overlook

• The platform fee is a tax on your own success. Per-execution pricing feels cheap at demo volume and becomes your second-largest cost line after inference at scale. The crossover point arrives faster in per-outcome GaaS than founders expect, because outcome-based billing pushes you toward high volume by design. Model the bill at 100x current load before you commit.

• Framework portability is mostly a myth in practice, but for the wrong reason. The code ports fine. What doesn't port is the accumulated operational knowledge, the specific failure modes, the tuned retry budgets, the eval harness shaped around one framework's quirks. Switching frameworks is less a code migration than a relearning tax, and nobody puts that on the slide.

• Choosing a platform too early can hide that your agent doesn't actually work. Managed reliability primitives paper over a flaky agent, so you ship, bill per outcome, and quietly eat retries instead of fixing root-cause unreliability. A framework's rawness is sometimes a feature: it forces you to confront your agent's real success rate before customers do.

• The "build vs buy" framing is a decade behind reality. It's not build or buy, it's which layer you build and which you buy. The winners buy durable execution and observability (genuinely hard, undifferentiated) and build orchestration and evals (where their moat actually lives). Teams that buy the moat and build the plumbing have it exactly inverted.

• Your framework choice silently dictates your hiring. A self-hosted framework stack demands SRE and distributed-systems talent that competes directly with infra-heavy companies for scarce engineers. A platform lets you hire applied-AI and product people instead. In a tight market, the framework decision is partly a recruiting decision, and almost nobody prices it that way.

References

• Building Effective Agents, Anthropic
• Seizing the Agentic AI Advantage, McKinsey & Company
• AI Agents: The New Application Layer, Andreessen Horowitz (a16z)
• Model Context Protocol, Official Documentation