Build, buy, or build-with-you: the third path for AI agents

Last updated: May 2026

Most build-vs-buy frameworks for enterprise AI agents present a binary choice and quietly pick a side. Forrester says 75% of self-build attempts will fail. Buying a packaged platform locks the buyer to a vendor's roadmap and leaves no in-house capability behind. Neither outcome is what the CTO actually wants. This post is about the third option the market is moving to: build-with-you, the embedded-engineering model that ends with the buyer's team owning the system the partner shipped. It's the cluster pillar for our work on capability transfer and how it fits inside agentic AI workflow services.

Key takeaways

• Build alone fails most of the time. Forrester predicts 75% of enterprises attempting to build their own agentic systems will fail, citing complexity in retrieval, data architecture, and niche expertise.
• 78% of enterprises want AI in-house (Zapier, 2026) — 38% don't trust vendor security, 33% fear vendor lock-in. The destination is in-house ownership. The route is the question.
• Buying buys time, not capability. A packaged agent platform ships in weeks but leaves no proprietary IP, no in-house engineers who can extend it, and a recurring bill tied to a vendor's roadmap.
• Build-Operate-Transfer is older than agentic AI. BCG, Deloitte, and Indian outsourcers ran the BOT model for years in software delivery. Adapting it to AI delivery is the shape of the third path.
• Big 4 firms now deliver via the OpenAI Frontier Alliance — McKinsey, BCG, Deloitte, Accenture. That changes what a Big 4 engagement is, and creates a specific opening for boutique engineering partners that ship without the Alliance overhead.

Why the binary frame is wrong

The question "should we build AI agents in-house or buy a platform?" treats two endpoints as the only options. In practice every CTO we work with wants to end up at the same destination: a production AI capability they own, that their team can operate and extend. The disagreement is about the route.

Pure build assumes the team that will eventually own the agent can also be the team that designs it from scratch. That is rarely true at the start of an agentic programme. Hiring senior agent engineers in 2026 takes six months and the budget for a full team usually doesn't exist before a working system has shipped. Forrester's 75%-fail estimate isn't about engineering talent — it's about the structural impossibility of building production-grade retrieval, evaluation, governance, and integration in parallel while also hiring the team that knows how.

Pure buy assumes the standardised use cases vendors package will match the enterprise's actual workflow. Sometimes they do. For meeting summaries, support ticket routing, content moderation, document classification — packaged agents work. But the value-creating use cases inside a specific enterprise — the ones that justify a budget — usually don't fit a packaged shape, and configuring around the edges leaves both a vendor dependency and a system the in-house team can't fully control.

The third path resolves the contradiction: an external team builds, the in-house team learns by working alongside them, ownership transfers throughout the engagement, and the partner leaves when the buyer's team can run the system independently.

The build path: what it actually costs

The headline numbers for pure-build agentic systems in 2026 are widely reported across industry pricing surveys. A focused custom agent MVP runs $50K-$100K. A full multi-agent system runs $250K-$400K+ in initial build, plus recurring senior-engineer salaries, observability tooling, model inference costs, and infrastructure operations. Build also commits the buyer to an opportunity-cost path: every senior engineer working on the agent is not working on the core product.

The harder cost is structural. Building a production agent requires expertise in retrieval architecture, prompt and model evaluation, multiagent orchestration, observability, and agent governance — five specialisms that overlap on a CV in maybe one in fifty senior engineers. A team building its first agent will learn the hard parts by hitting them in production. Most stop hitting them at all, because the system gets shelved before it reaches that stage.

The cases where pure build is the right call are narrow: the use case is genuinely core IP, the team already has a senior agent engineer on staff, the use case is sensitive enough that no partner is acceptable. For most enterprises starting an agentic programme in 2026, none of these conditions hold.

The buy path: speed at a cost

Packaged agent platforms — Kore.ai, Sierra, Decagon, Aisera, Vertex AI Agent Builder, Amazon Bedrock Agents — solve the time-to-value problem. Configuration takes weeks. Compliance is inherited from the platform. Up-front engineering cost is near zero. For the 90% of use cases that fit a standardised shape, buy is the right answer.

The trade-offs are familiar but worth naming. Vendor lock-in — 33% of enterprise leaders cite this as a buying concern (Zapier, 2026). No IP — the prompts, models, and integrations are the vendor's, not the buyer's. No in-house capability — the team running the platform is running a vendor's product, not learning the engineering that would let them build the next agent themselves. Recurring cost tied to vendor roadmap — pricing rises as usage scales, and the vendor's priorities are not the buyer's priorities.

For meeting summaries and support routing the trade-offs are acceptable. For the agentic workflows that justify enterprise-scale budgets — the ones that read from and write back to core systems, that touch regulated decisions, that compound competitive differentiation — the trade-offs are not acceptable, and the buy path is the wrong shape.

The third option: build-with-you, defined

Build-with-you is what the Build-Operate-Transfer model from infrastructure outsourcing looks like when adapted for agentic AI delivery. The shape is the same: an external partner builds the capability, operates it through a transition period, transfers ownership to the buyer's team. The adaptation for AI is in what gets transferred — not just code and infrastructure, but the eval pipelines, the prompt versioning workflows, the agent registry, the observability dashboards, and the in-house team's ability to extend the system without the partner.

The three properties that distinguish build-with-you from build and from buy:

1. Senior engineering depth at the start. The first six to ten weeks are the partner's senior engineers doing the work, not training the in-house team. The system needs to ship before the team can learn from a working example.
2. Continuous capability transfer, not a handover at the end. Pair working, documented decisions, code reviews of the in-house team's first production changes. The transfer happens throughout the engagement, not in a one-week wrap-up.
3. A clear exit signal. The partner leaves when the in-house team has shipped their own production change without the partner's involvement. Not on a calendar date, not at a budget threshold — on the operational signal that the team can run the system.

The model is older than agentic AI. We have been running it at Datatalks since 2018 — eight years of embedded senior engineering on a customer data platform that the Datatalks team now operates and extends with us still alongside them when scope expands. We ran it more recently at Aralab, where a Claude Sonnet 4.5 invoice agent was built by our senior engineers and transferred to Aralab's finance and engineering teams across a six-month engagement. We have run it twice with SANA Hotels — once for an AI training platform, once for staff optimisation — with capability transfer to the SANA operations team built into each phase.

How build-with-you compares to the four options on the table

Most CTOs have four options to choose from when scoping an agentic engagement. The differences matter because each delivers a different thing at a different cost with a different exit state.

The comparison isn't a value judgment on any path. Each is right for a different question. Build-with-you is the right answer when (a) the use case is validated, (b) the destination is an in-house capability the team can run, and (c) the buyer wants the system fast without the vendor lock-in of buy or the failure rate of build.

What changed: the Big 4 are now Alliance delivery partners

In 2026 McKinsey, BCG, Deloitte, and Accenture became delivery partners in the OpenAI Frontier Alliance — getting early access to unreleased models, dedicated engineering support, and co-development pathways for enterprise clients. This is a real shift in what a Big 4 AI engagement contains. It also creates a specific opening for boutique engineering partners.

The Big 4 Alliance model fits enterprises whose primary need is enterprise-scale rollout — multi-business-unit programmes, change management at thousands of seats, governance at parent-company level. The cost matches: Big 4 enterprise AI engagements start at $50K-$500K+ and scale from there.

The boutique engineering shape — what build-with-you actually is — fits enterprises whose primary need is a working production system shipped quickly by senior engineers without the Alliance overhead. The cost is lower because the engagement is engineering-led rather than advisory-led. The exit state is the same as Big 4 in terms of a deployed system, with a clearer ownership transfer because the engagement was scoped that way from the start.

Enterprises increasingly choose both: a Big 4 firm for strategy and change management at the parent level, and a boutique build-with-you partner inside specific business units for the production engineering. We work directly with Big 4 partners on this pattern when the structure calls for it. It is not a competition. It is two different shapes of work that pair well.

When build-with-you is the wrong call

Naming the limits of the model is more useful than overselling it.

The use case isn't validated yet. If the buyer is still deciding whether agentic AI is the right answer for a specific workflow, the engagement should start with a strategy advisory or a discovery sprint, not a build-with-you engagement. Build-with-you assumes a validated use case to scope around.

The destination is permanent outsourcing. If the buyer's intention is to run the agentic system through an external operator forever, the build-with-you model is over-engineered for the goal. Pure managed services would deliver the same operational outcome at lower cost.

The buyer doesn't have or want an in-house engineering team. Build-with-you transfers capability to a team. If there is no team to transfer to, the engagement ends with a system nobody can operate. Better to use a managed-service partner.

The use case is genuinely commodity. If the workflow is meeting summaries, document classification, support ticket routing — a packaged platform configured by a vendor partner ships the same outcome in less time at lower cost. Build-with-you exists for the non-commodity case.

The handover signal: what tells the partner to leave

The cleanest answer to "when does the partner leave?" is also the most operationally honest: when the in-house team ships a production change without the partner's involvement. Not a date on a contract, not a milestone in a slide, not a budget threshold. The operational signal.

What that looks like in practice. The in-house team writes a new tool definition for an agent — an additional API the agent can call. They write the schema, they write the eval cases, they ship the change through CI, the agent uses it in production correctly. The partner reviewed the PR but didn't write the code. The next change after that, the partner doesn't review. The change after that, the in-house team has shipped three production changes without us.

That is the signal. It usually arrives between month four and month nine of the engagement, depending on the team's starting expertise and the complexity of the agent. When it arrives, the partner steps out. We have done this at Datatalks (eight years and counting because the scope keeps expanding, but the core CDP capability transferred years ago), at Aralab (transferred at month six, called back for an adjacent module a year later), and across two engagements with SANA Hotels (transferred phase by phase).

The exit is not the end of the relationship. Build-with-you partnerships often turn into multi-engagement relationships where the partner is called back for the next adjacent system. But the call is the buyer's, not a renewal of a managed-services contract. That difference is the whole point of the model.

What this means for the buyer scoping an engagement

Three questions clarify whether build-with-you is the right shape:

The first question is about destination: where does the buyer want the system to live in two years? If the answer is "operated by our team, extended by our engineers, using IP we own," build-with-you fits. If the answer is "operated by a vendor we pay forever" or "operated by an Alliance partner inside a strategic relationship," a different model fits.

The second question is about validation: is the use case validated, or is it still being scoped? Build-with-you is an engineering engagement, not a strategy engagement. It assumes the use case has been validated through a discovery sprint, a strategy advisory, or the buyer's own internal work.

The third question is about timeline urgency: how fast does the production pilot need to ship? Build-with-you delivers a production MVP in six to ten weeks. Big 4 engagements take six to twelve months. Pure build takes nine to eighteen months. If the buyer needs the working system in this quarter to justify the budget, the Big 4 path is too slow and pure build is too risky.

The buyers we work with answer all three questions in a way that points at build-with-you. We have not been the right answer for every CTO we have talked to. We have been the right answer often enough that the model is the operating spine of the agentic AI workflow services we deliver.