Build-vs-Buy 2.0 — The Market Is Splitting in Two, and You Need to Pick a Side

Estimated reading time: 7 min

Six months ago, Publigent published a decision framework for teams choosing between open-source agent frameworks and managed platforms. The conclusion was honest: there is no universal right answer, but there is a right process. Pick based on where you are and where you need to be in a year, and plan for the migration you will probably do anyway.

The six months since have produced a clearer picture than the framework could offer. The market is not converging on one model. It is bifurcating. Early adopters who started on managed platforms are migrating to open-source frameworks. Late adopters, the teams just now starting their agent journey, are buying managed platforms. Both moves are rational. Both have implications for where the market is going.

The Bifurcation, in Numbers

The pattern is consistent enough to state as a rule of thumb. Organizations that deployed their first agent before mid-2025 are, by and large, migrating away from managed platforms. They hit the platform's limits (customization ceilings, cost at scale, vendor lock-in concerns) and they're rebuilding on open-source frameworks. The teams that started deploying in 2026 are choosing managed platforms. They watched the early adopters struggle, they want the paved path, and they have less tolerance for engineering overhead.

The build-versus-buy dynamic shifted in an unexpected direction, as we noted in the Mid-Year Check. Early adopters who bought managed platforms are migrating to open-source frameworks. Later adopters are doing the opposite. Experienced teams that know what they need are building their own infrastructure. Inexperienced teams that want to get started quickly are buying platforms. Neither path is wrong. But the idea that the market would converge on one model was wrong.

Why Early Adopters Leave

The migration from managed to open-source follows a consistent arc. A team needs a working agent quickly. They pick a managed platform (Dify, Flowise, LangGraph Cloud, n8n) and have something running in two weeks. Stakeholders are happy. Then the requirements grow.

The customization ceiling is the first wall they hit. The agent needs a custom integration the platform does not support. A non-standard handoff protocol. A specific authentication flow. A memory retention strategy that doesn't match the platform's defaults. At first, teams work around it. They add a middleware layer. They hack together a script that bridges the gap. Then the workarounds accumulate, and the platform that was supposed to save engineering time ends up consuming it.

The cost curve flips at medium scale. The per-agent or per-execution pricing that made sense at 5 agents becomes untenable at 50. One team I spoke with reported that their LangGraph Cloud bill crossed $4,000/month at roughly 15,000 executions per month. At that point, the cost of building and maintaining their own infrastructure (a small Kubernetes cluster, an open-source orchestrator, a self-hosted vector store) was less than the platform fee. The crossover point varies by platform and use case, but it typically lands between 50-100 agents or 10,000-15,000 executions per month. Below that threshold, managed is cheaper. Above it, the math flips.

Vendor lock-in becomes a concrete problem instead of a theoretical one. A pricing change, a deprecation, or a shift in product direction can each break the operational model you built around the platform. Platform teams have different incentives than your team. They optimize for their bottom line, not your architecture. When those incentives diverge, you bear the cost. Not because anyone is malicious. Because that is how platform dependencies work.

Why Late Adopters Buy

The late adopters, organizations deploying their first agent in 2026, have a different perspective. They watched the early adopters go first. They saw the mistakes. And they are making a deliberate choice to buy rather than build.

Time-to-value is the dominant factor. A team using Dify or Flowise can have a working agent in days, not weeks. For organizations that are still proving to their leadership that agents are worth investing in, speed matters more than long-term control. Getting a win on the board in two weeks is worth more than an architecture optimized for year three.

Engineering bandwidth is the binding constraint. Most organizations deploying their first agents in 2026 do not have spare infrastructure engineers. Their engineering teams are already fully allocated. Building an agent deployment pipeline, observability stack, and credential management system from scratch requires dedicated headcount. A managed platform trades dollars for engineering time, and for organizations that have SaaS budget but limited engineering capacity, that trade is rational.

Managed platforms have improved. The reliability and compliance features available today are significantly better than what existed in 2024 or early 2025. Dify now offers SOC 2 compliance. LangSmith provides production-grade tracing and evaluation. Flowise has enterprise deployment options. The early platforms were tools for experimentation. The current generation is built for production. The gap between what a managed platform offers and what a team would build themselves has narrowed.

The paved path is valuable. Late adopters don't want to make the mistakes the early adopters already made. They want to follow a known-good pattern. Managed platforms provide that: recommended architectures, pre-built integrations, documented failover patterns, and support teams that have debugged similar issues before. The open-source path requires making every mistake yourself. For organizations that can afford to pay for someone else's experience, that is a worthwhile trade.

The Hybrid Reality

Most teams are not purely on one side of this divide. The build-vs-buy decision is rarely one decision. It is a portfolio of choices across the stack.

The most common pattern I see: open-source for core orchestration, managed for specific capabilities. A team runs LangGraph or CrewAI for agent coordination and workflow logic, but uses LangSmith for observability and monitoring. They manage their own vector database for memory but use a managed service for model inference. They build custom tool integrations for their core workflows but use an MCP server for standard connections.

The migration from managed to open-source is rarely a clean cut. Teams that describe themselves as "migrated" are not fully off managed platforms. They have moved the core orchestration layer in-house, but they still rely on managed services for evaluation pipelines, monitoring, or specific tool integrations. The build-vs-buy decision is becoming a build-vs-buy portfolio, with each layer assessed independently.

I have seen teams deploy a managed platform for customer-facing agents where speed and reliability matter most, while building custom open-source agents for internal operational workflows that require deep integration with proprietary systems. Both choices were right. Treating the decision as monolithic would have been wrong for both.

What This Means for the Market

Platform companies are being squeezed from two directions. From below, open-source frameworks are getting easier. LangGraph's stateful workflow model, CrewAI's role-based delegation, and AutoGen's conversational patterns have matured significantly. The frameworks handle more of the production burden than they did a year ago. From above, cloud providers are adding agent capabilities natively. AWS Bedrock's agent builder, GCP's Vertex AI Agent Builder, and Azure AI Agent Service all offer managed agent orchestration with deep integration into their respective clouds.

The squeeze means the standalone managed platform (a company whose entire product is an agent orchestration platform) faces a difficult position in the next 12 months. The survivors will be the ones that have specialized in a vertical (healthcare agents, financial services agents) or built a real platform moat (evaluation infrastructure, observability, compliance tooling) that neither open-source frameworks nor cloud providers can easily replicate.

The vertical specialists already have an edge. Healthcare back-office platforms understand prior authorization workflows, HIPAA compliance, and EHR integrations in a way that a general-purpose agent platform does not. Financial services platforms understand trade reconciliation, MiFID II reporting, and KYC document processing. These vertical platforms are harder to commoditize because their value comes from domain knowledge, not orchestration technology.

How to Think About Your Decision

If you are deploying agents now and this is your first time: start managed and plan your migration path. Pick a platform that gives you an escape hatch: exportable data, standard formats, documented APIs. Know what your crossover point looks like (roughly 50 agents or 10,000 executions per month) and start planning the migration when you hit 60% of that threshold. The worst outcome is being past the crossover point with no path off the platform.

If you deployed on a managed platform in 2024 or early 2025: you are probably already planning your migration. The question is not whether, but how. Start with the core orchestration layer: that is where platform constraints bite hardest. Move it to an open-source framework (LangGraph for stateful workflows, CrewAI for role-based delegation). Keep managed services for anything that is not core to your differentiation: observability, evaluation, model access. The hybrid model is not a compromise. It is the durable architecture.

If you are an enterprise deciding right now: make a two-speed choice. Use a managed platform for low-risk, high-velocity experiments: prove value to stakeholders, build organizational confidence. Invest in open-source infrastructure for the workflows that will become core to your business. The experiments teach you what you need. The open-source infrastructure gives you control over what matters.

Either way, the decision isn't permanent. It is a phase. The teams that do this well treat the build-vs-buy choice as something they reassess every quarter. Requirements change. Scale changes. The available options change. The question is not whether you will make the right choice today, but whether you will notice when the right choice changes.

---

This article builds on findings from Article 010 (Build-vs-Buy Decision Framework), Article 020 (Mid-Year Agent Deployments), Article 023 (H1 Retrospective), and Article 026 (Agent TCO Economics). Platform pricing and deployment data drawn from public documentation, engineering blogs, and conversations with teams managing production agent deployments through May 2026.