The Build-Buy-Agent Decision: A New Framework for Capability Sourcing

The Framework That No Longer Works

For decades, enterprise technology decisions followed a familiar pattern. Need a new capability? Evaluate whether to build it internally or buy it from a vendor. The calculus was straightforward: building offered customization and control but required time and talent. Buying offered speed and proven solutions but meant compromises on fit and ongoing licensing costs.

This binary served us well. Then agents arrived and broke the model.

In 2024, 47% of enterprise GenAI spend went to internal builds while 53% went to purchased solutions. By 2025, that ratio had inverted dramatically: 76% purchased, only 24% built. According to Menlo Ventures, this represents the fastest shift in enterprise software sourcing patterns ever recorded.

But the real story isn't the shift from build to buy. It's the emergence of a third category that fits neither: agent-based capabilities that you configure rather than build, deploy rather than purchase, and orchestrate rather than maintain.

Why The Old Framework Fails

The traditional build-buy framework assumed certain constants that no longer hold.

Building assumed scarce implementation capacity. When implementation was the bottleneck, building meant competing for limited developer time against every other initiative in the portfolio. The opportunity cost was real and measurable. AI coding assistants have fundamentally changed this equation. A senior engineer with modern AI tools now produces what took a team of five in 2023. Building is no longer as expensive as it was, which makes the "buy to save time" argument weaker.

Buying assumed capabilities came packaged. Enterprise software traditionally arrived as finished products with defined feature sets. You evaluated against requirements, negotiated terms, and implemented. The vendor handled the capability; you handled the integration. But modern AI capabilities don't arrive packaged. They arrive as platforms, models, and primitives that require substantial configuration, fine-tuning, and orchestration to deliver business value.

Both assumed stable requirements. Build-buy decisions were made against a requirements document that, while imperfect, represented a reasonable approximation of what you needed. In the AI era, requirements emerge through experimentation. You don't know what the capability should do until you've tried several approaches. The waterfall logic embedded in traditional build-buy analysis struggles with this reality.

Enter the Third Option

The third option isn't really new. It's the recognition that "configure" has become a legitimate alternative to both build and buy. But calling it configuration undersells its significance. What we're actually talking about is capability assembly from modular, intelligent components.

Consider what's available today:

Platform agents like Salesforce Agentforce offer full lifecycle management for AI agents with both low-code and pro-code options. You're not buying a finished product. You're subscribing to an agent platform that you configure for your specific workflows. Pricing models reflect this: flexible credits, per-conversation fees, or per-user licensing.

Cloud primitives like Amazon Bedrock Agents provide building blocks for autonomous task completion. Multi-agent collaboration, RAG integration, code interpretation, and memory retention come as services. You're not building from scratch. You're assembling capabilities from pre-built components with your business logic layered on top.

Open frameworks like LangGraph offer MIT-licensed foundations for custom agent architectures. You're not buying vendor lock-in. You're adopting a pattern library that accelerates your build without constraining your options.

None of these fit cleanly into build or buy. They're something in between, with different economics, different risks, and different organizational implications.

A New Framework: Build, Buy, or Agent

I propose a new framework that explicitly recognizes agent-based capability sourcing as a distinct category with its own decision criteria.

Option 1: Build

When it makes sense:

• The capability represents core competitive differentiation
• Requirements are well understood and stable
• You have deep domain expertise that's difficult to externalize
• Data sensitivity or regulatory constraints preclude external solutions
• Long-term total cost of ownership favors internal development

What's changed: Building is faster and cheaper than it was. AI-assisted development has compressed timelines by 30-50% in many organizations. The "building takes too long" objection carries less weight than it used to. However, building still requires maintaining what you create, and AI-generated code may create new forms of technical debt if verification processes aren't robust.

Watch out for: The build instinct is strong in engineering cultures. Teams often underestimate the ongoing maintenance burden and overestimate their ability to keep pace with rapidly evolving AI capabilities. Building made sense when capabilities were stable. In a field moving this fast, today's custom build is tomorrow's legacy system.

Option 2: Buy

When it makes sense:

• The capability is commodity functionality without differentiation value
• You need proven, production-grade solutions with vendor support
• Compliance requirements favor established vendors with audit histories
• Time-to-value matters more than customization
• The total addressable market is large enough to sustain vendor investment

What's changed: The buy landscape has bifurcated. Traditional enterprise software vendors are bolting AI capabilities onto existing products with mixed results. Meanwhile, AI-native vendors are building products that assume AI from the ground up. The gap between these two categories is widening. Buying from the first category gives you incremental improvement. Buying from the second gives you architectural transformation.

Watch out for: Vendor claims about AI capabilities often outpace reality. Deloitte's research found widespread "agent washing" where simple automation gets marketed as agentic AI. Due diligence now requires technical depth that many procurement processes lack. Additionally, buying AI capabilities creates new dependencies. Model availability, API stability, and pricing changes all become business risks.

Option 3: Agent

When it makes sense:

• The capability requires flexibility and rapid iteration
• Requirements are emergent and will evolve through experimentation
• You need to combine AI reasoning with your proprietary data and systems
• The task involves complex workflows that benefit from orchestration
• You want optionality to swap underlying models or components

What's different: Agent-based sourcing combines elements of both building and buying while introducing new characteristics. You're not writing all the code, but you're not buying a finished product either. You're configuring intelligent components, connecting them to your systems, and orchestrating their behavior to achieve business outcomes.

The closest analogy might be cloud infrastructure. When AWS launched, enterprises faced a similar build-buy confusion. Should we build our own data centers or buy hosting services? The answer was neither: adopt infrastructure-as-a-service and configure it for your needs. Agents represent capability-as-a-service, with similar implications for how organizations source and manage functionality.

The Decision Matrix

Here's a practical framework for navigating the decision:

Evaluate differentiation value. If the capability is a source of competitive advantage, bias toward build or agent configurations that you control. If it's commodity functionality, bias toward buy.

Assess requirement stability. If you know exactly what you need and it's unlikely to change, traditional build or buy works fine. If requirements are emergent or will evolve rapidly, agent-based approaches offer more flexibility.

Consider integration complexity. Agent-based solutions require connecting to your systems, data, and workflows. If your enterprise architecture is modern with good APIs, this is straightforward. If you're running legacy systems without real-time integration capability, Gartner estimates over 40% of agentic AI projects fail for exactly this reason.

Factor in organizational readiness. Agent-based capabilities require new skills: prompt engineering, orchestration design, verification processes, and ongoing tuning. If your organization lacks these capabilities and isn't prepared to develop them, buying packaged solutions may be more realistic.

Calculate total cost of ownership. This is where the math gets interesting.

The Economics of Agent-Based Sourcing

Traditional TCO models don't capture agent economics well. Here's what changes:

Upfront costs are lower. You're not licensing a full product or funding a complete build. You're paying for platform access and per-use consumption. Initial investment is often a fraction of traditional approaches.

Variable costs replace fixed costs. Agent platforms typically charge per conversation, per task, or per credit consumed. This creates usage-based economics that scale with value delivered. If adoption is low, costs are low. If adoption explodes, so do costs.

Hidden costs emerge differently. With traditional software, hidden costs live in implementation, integration, and change management. With agents, hidden costs live in context engineering, verification, and ongoing refinement. The skill sets required are different, which means the organizational investments are different.

Model costs matter. Anthropic now leads enterprise usage at 40% market share. But model economics are in flux. Prices are dropping while capabilities are increasing. Any TCO calculation needs to account for the likelihood that model costs will be materially different in two years.

Here's a rough framework for comparison:

Cost Category	Build	Buy	Agent
Upfront	High	Medium	Low
Ongoing maintenance	High	Low	Medium
Integration	Medium	High	Medium
Flexibility/changes	Low	Low	High
Scaling costs	Fixed	Licensed	Variable
Skill requirements	Engineering	Procurement	Orchestration

The agent column represents a different risk profile, not necessarily a better or worse one. Variable costs that scale with usage can be either an advantage or a liability depending on how adoption unfolds.

Organizational Implications

Choosing agent-based capability sourcing has implications beyond the immediate project.

Skills and roles shift. Agent-based work requires what I call context engineering: the ability to translate ambiguous business intent into specifications that agents can execute reliably. This is neither traditional software development nor traditional business analysis. It's a new discipline that combines elements of both.

Governance changes. You're not governing a static system anymore. You're governing an adaptive system that behaves differently based on context. This requires new approaches to testing, monitoring, and oversight. Deloitte found that 78% of CIOs cite governance as a primary barrier to scaling AI. Agent-based approaches amplify this challenge.

Vendor relationships evolve. With traditional software, you had a vendor relationship that centered on licensing, support, and periodic upgrades. With agent platforms, you have an ongoing partnership that involves model selection, prompt optimization, and continuous capability expansion. The relationship is more dynamic and requires more active management.

Architecture matters more. Agent-based capabilities depend on your data foundation, API infrastructure, and integration patterns. Organizations with modern, well-architected systems can adopt agents quickly. Organizations with legacy architectures face significant friction. Deloitte's research found that nearly half of organizations cite data searchability and reusability as significant barriers.

A Practical Approach

Given this complexity, how should enterprises approach the build-buy-agent decision?

Start with the business problem, not the technology. The question isn't "should we use agents?" The question is "what capability do we need and what's the best way to source it?" Agent-based approaches are one option, not the default option.

Experiment before committing. The agent option's low upfront cost is an advantage for experimentation. Stand up a proof of concept using a platform like Bedrock Agents or Salesforce Agentforce. Test against real workflows with real data. Learn what works before making sourcing decisions.

Build the foundation first. If your data architecture isn't agent-ready, fix that before investing in agent capabilities. No amount of clever orchestration will overcome garbage data or missing integrations. The foundation work isn't glamorous, but it's prerequisite.

Develop the skills in parallel. Context engineering, agent orchestration, and AI verification are skills your organization will need regardless of sourcing decisions. Start building these capabilities now, even if you're not sure exactly how you'll use them.

Plan for change. Whatever decision you make today will need to be revisited. The agent landscape is evolving rapidly. Build flexibility into your approach. Avoid lock-in where possible. Assume that the optimal sourcing strategy will be different in two years.

The Convergence Ahead

Looking forward, I expect the boundaries between build, buy, and agent to blur further.

Traditional software vendors are racing to embed agent capabilities into their products. Enterprise platforms are exposing agent-building tools to their customers. Open-source frameworks are making sophisticated agent architectures accessible to anyone willing to learn them.

The end state may not be three distinct categories but a spectrum of capability sourcing options with different mixtures of pre-built, configured, and custom components. The organizations that thrive will be those that can navigate this spectrum fluidly, selecting the right approach for each capability based on differentiation value, requirement stability, and organizational readiness.

The build-buy decision served us for decades. It's time for an upgrade.

What Leaders Should Do Now

If you're making capability sourcing decisions today, here's my advice:

1. Audit your current framework. Is your organization still applying pure build-buy logic? If so, you're missing options that might be better fits for AI-era capabilities.

2. Assess your foundation. Can your current architecture support agent-based approaches? If not, that's the first investment, regardless of sourcing strategy.

3. Build the skills. Context engineering and agent orchestration skills are valuable whether you build, buy, or configure. Start developing them now.

4. Experiment with low commitment. Use the agent option's low upfront costs to run experiments. Learn what works for your organization before making major commitments.

5. Stay flexible. The landscape is moving fast. Whatever sourcing strategy you choose, build in the ability to adapt as the technology evolves.

The organizations that master this new three-way decision will have significant advantages over those still trapped in binary thinking. Build versus buy was the question. Build, buy, or agent is the answer.