Build vs. Buy AI Agents — What the Enterprise Data Actually Says

We spend a significant portion of our delivery work with organisations that are in the middle of this decision. The framing is almost always the same: “Should we use a vendor platform like Copilot Studio or Agentforce, or build our own orchestration?” That framing misses the actual question.

The actual question is: what does it take to get an AI agent from pilot to production inside a regulated organisation — and which path gets you there?

The data on this is now specific enough to work from.

The Production Gap Is the Real Problem

Adoption statistics for AI agents look impressive on the surface. OutSystems’ 2026 State of AI Development Report, drawing on 1,900 IT leaders, found that 96% of enterprises report some level of AI agent deployment. McKinsey’s mid-2025 global survey found that 23% of organisations are actively scaling an agentic AI system, with another 39% in active experimentation.

But production deployment tells a different story. IDC research places the pilot-to-production failure rate at 88% — meaning the substantial majority of AI agent pilots never reach production. Of enterprises that have “adopted” AI agents, McKinsey estimates only 11% are running them in live production environments.

There is a meaningful gap between “we have AI agents” and “our AI agents are running in production with real credentials, real customer data, real compliance requirements, and real consequences.” Everything between those two points is where implementations fail. Understanding that gap is what determines whether you should build or buy.

What You Are Actually Deciding

When organisations frame this as build vs. buy, they usually mean: vendor platform (Copilot Studio, Salesforce Agentforce, OpenAI Agent Builder) or custom orchestration (LangGraph, CrewAI, AutoGen). The more accurate framing is: which path reaches governed, production-grade deployment in our specific regulatory and data environment — and at what cost?

Four variables determine the answer:

Data access. Vendor platforms work well with the data sources they were designed for. Agents that need real-time access to transactional systems, proprietary APIs, legacy databases, or multi-system data flows hit the edge of vendor capability quickly.

Governance and audit requirements. In regulated industries, every agent action needs to be traceable: which agent accessed which data, under which permissions, at what time, producing which output. This is non-optional in healthcare, financial services, and legal contexts.

Vendor lock-in risk. Vendor agents are built on specific LLMs. Switching models — whether for cost, capability, or compliance reasons — typically requires re-architecture.

Deployment timeline. Vendor platforms deliver faster time-to-PoC. Custom orchestration takes longer to stand up but typically delivers more reliable production performance.

The Case for Vendor Platforms

Vendor platforms have earned their adoption share. More than 160,000 organisations have deployed over 400,000 agents on Microsoft Copilot Studio alone, with Microsoft reporting active agent deployment across over 80% of the Fortune 500. Salesforce closed 29,000 Agentforce deals since launch.

The research broadly supports vendor adoption for simpler use cases. Organisations using external vendors and platforms show 2× higher success rates in scaling AI deployments compared to organisations relying solely on internal builds. Vendor-deployed agents show 2.4× faster payback than custom-built implementations.

For well-defined, single-system workflows — internal HR queries, CRM data retrieval, customer support routing — vendor platforms deliver exactly what they promise: low barrier to entry, fast deployment, and usable output within weeks.

The question is not whether vendor platforms work for this. They do. The question is what happens when you try to extend them into production environments with more demanding requirements.

Where Vendor Platforms Break Down

The governance gap is where vendor platforms most consistently fail at enterprise scale.

IBM’s 2026 Think survey of enterprise technology leaders found that 70% of executives say the AI governance they have in place is not fit for purpose. Only 18% of organisations maintain a current, complete inventory of the AI agents running inside their organisation. Only 12% have a centralised platform to manage agent sprawl. And 94% are concerned about that sprawl growing.

Salesforce’s 2026 Connectivity Benchmark, surveying 1,050 IT leaders, found that 50% of enterprise AI agents operate in isolated silos with no shared context or unified governance — and 27% of API connections between agents are completely ungoverned.

The security consequence is significant. 88% of organisations report confirmed or suspected AI agent security or privacy incidents within the last year.

The pattern behind these numbers is consistent. Vendor platforms make it easy to deploy agents quickly. They make it significantly harder to govern them thoroughly. When the compliance team or a security review catches up to a deployment — and in regulated industries, it always does — architecture that was never designed for explainability, audit trail, or controlled data access becomes prohibitively expensive to retrofit.

Deloitte’s 2026 State of AI in the Enterprise report found that only 1 in 5 companies has a mature governance model for autonomous AI agents — despite the vast majority having agents in some form of deployment.

The Case for Custom Orchestration

For organisations with complex data environments, compliance requirements, or multi-system integration needs, the build path is not a preference — it is a requirement for reaching production.

The framework landscape in 2026 has matured enough to make this tractable. Three orchestration approaches cover most enterprise use cases:

LangGraph suits graph-based, compliance-driven processes. Its explicit workflow definition makes every decision step inspectable and auditable. Financial services, insurance, and healthcare teams operating under explainability requirements typically land here.

CrewAI suits role-based, collaborative agent structures where multiple agents operate on open-ended tasks in parallel. It is better suited for research, content, and analytical workflows than for transactional or compliance-critical paths.

AutoGen suits conversational, human-in-the-loop architectures — particularly IT operations and incident response contexts where a human needs to remain in the decision chain.

In practice, production-grade systems for complex environments frequently combine paradigms: LangGraph for the compliance-critical decision path, with other agents handling retrieval or supporting tasks — all operating under unified governance.

The governance layer is where the build path creates durable advantage. IBM research on organisations implementing orchestration-led, centrally governed AI architectures shows measurable production differences: 13× faster scaling than ungoverned equivalents, 30% fewer operational irregularities, 20% greater ROI from AI investments, and 169% greater transparency into agent decisions.

These numbers reflect something straightforward: agents that cannot be governed cannot be trusted in production. Agents that cannot be trusted in production either get cancelled or cause incidents.

What “governed” means concretely is also maturing. Beyond audit logging and human review queues, the mechanisms now emerging in serious agent deployments include sandboxing — letting an agent make decisions in a simulated environment with no real-world consequence before it touches production; governance agents that monitor working agents for drift and pull them out of service when behaviour degrades; agent-to-agent interaction monitoring with explicit conflict-resolution rules for multi-agent systems; and an emergency stop that genuinely halts the workflow, paired with containment procedures so a malfunctioning agent cannot escalate before a human intervenes. Custom orchestration is what makes these controls implementable; vendor platforms expose only the subset the vendor chose to build.

Our automated lending risk platform illustrates what custom orchestration in a regulated environment looks like in practice. The system processes real-time application signals, bureau data, and cash flow patterns under a governance layer that maintains full auditability for the lender’s compliance function. A vendor agent kit could not have delivered it — the real-time data access requirements, the explainability requirements, and the integration architecture ruled that path out at discovery.

The Decision Framework

The build vs. buy decision is less binary in practice than it appears in vendor marketing. Most mature implementations use vendor platforms where they work and build custom orchestration where they must.

Use vendor platforms when:

• The use case is well-defined and single-system
• Governance requirements are light — internal tools, low-stakes automation
• Speed to PoC matters more than production depth
• You are evaluating AI agent feasibility before committing to architecture

Build custom orchestration when:

• The agent needs real-time access to transactional, proprietary, or multi-system data
• Explainability and audit trail are required by compliance or regulation
• You need to own the model choice — for cost, capability, or data sovereignty
• You are building for production scale in a regulated industry
• An ungoverned agent failure would produce a compliance event, not a UX complaint

The most common failure pattern we see is organisations using vendor platform economics to justify production deployment in environments that require custom governance architecture. The 88% pilot failure rate reflects exactly this: the PoC worked under controlled conditions; the production environment did not.

Questions to Settle Before You Choose

Before committing to either path, three questions determine which decision is correct for your organisation.

What data does this agent actually need? If the answer involves real-time transactional systems, proprietary APIs, or data outside the vendor’s integration surface, vendor platforms will hit a ceiling in production.

Who is responsible for governing this agent after deployment? Governance ownership needs to be assigned before the architecture is chosen — not retrofitted afterward. The 70% governance gap is not a technology failure; it is a decision made at architecture stage, or not made at all.

What happens when the agent is wrong? Define the failure mode and the containment before the system ships. An ungoverned agent producing a wrong output at scale is a regulatory event in financial services and a liability event in healthcare. Both containment designs need to exist before production.

How we approach this at Insoftex

The pattern from the research cited in this article matches what we observe consistently: vendor platforms work for what they were designed for and create governance debt faster than value when pushed beyond that scope. The organisations we see most often come to us after the vendor platform phase — they have a working PoC on Copilot Studio or Agentforce, the compliance team has reviewed it, and the audit trail or data access requirement the vendor platform cannot meet has surfaced. At that point they are deciding between retrofitting governance into an architecture that was not designed for it or starting the custom build.

For regulated-industry builds specifically — the lending risk platform, the healthcare documentation systems, the EU AI Act-governed deployments — the path is almost always custom orchestration from the first production architecture decision. The audit trail requirement alone determines this. LangGraph with LangSmith provides the decision traceability that regulated deployments require; vendor platforms provide governance tooling that is improving but not yet at the compliance depth that financial services and healthcare auditors expect.

The governance question we ask before any architecture decision: who is responsible for this agent when it produces a wrong output at scale? If the answer is “we will review it after launch,” the governance design is not done. The containment for wrong outputs — confidence thresholds, human review queues, rollback procedures — needs to exist at architecture design time. For organisations where an ungoverned agent output would produce a regulatory event rather than a UX complaint, the cost of that design is always less than the cost of the alternative.

AI agent pilot stalled before production? Our Product Pilot audits your data infrastructure, governance posture, and integration constraints — and delivers a prioritised roadmap with effort estimates written by the engineers who would build it. Fixed scope, three weeks, senior engineers from day one.

Frequently Asked Questions