Buy, build, or borrow.

Three numbers from analyst firms in the first quarter of 2026 frame the decision your CIO is currently making. Gartner: more than 40% of agentic AI projects will be cancelled by the end of 2027.¹ Forrester: 75% of companies attempting to build their own agentic systems will fail.² Anthropic, in their 2026 State of AI Agents report: 47% of enterprises are already running a hybrid of off-the-shelf and custom-built agents, but almost none arrived there deliberately.³

The buy-versus-build debate is producing those failure rates because it's the wrong frame. It treats the decision as binary, evaluates each agent in isolation, and ignores the largest source of failure: the seam between what you bought and what you built. That's where governance debt accumulates, where shadow AI spend hides, and where the vendor's customization ceiling sneaks up on you twelve months after the contract is irreversible.

The frame that produces better outcomes is three-way: buy, build, or borrow. Borrowing, in this context, means renting senior capacity to ship a specific outcome, in production, with knowledge transfer to your team. It's the option most enterprises haven't sized correctly because it doesn't fit either of the procurement playbooks (software or staff aug) that they're used to running.

The three options, honestly

Buy

You purchase a platform-native agent or a vendor-built agent for a specific workflow. Salesforce Agentforce. Microsoft Copilot. ServiceNow AI. Decagon for support, Sierra for customer service, Ada for the same. The agent comes pre-trained, pre-integrated to its native platform, and shipped on a contract.

Strengths: time to deployment is the shortest of the three options, typically four to eight weeks. The vendor absorbs the infrastructure complexity, the model maintenance, the regulatory updates. For commodity workflows where your enterprise isn't particularly different from anyone else's, this is usually the right call.

Failure modes: vendor lock-in compounds at every layer. Customization ceilings show up late. The platform's permission model becomes your authorization model by default. And per-ticket or per-seat pricing on agents that are genuinely doing work scales unpleasantly when the volume is high.

Build

Your engineering team writes the agent in-house, on top of foundation models and orchestration frameworks like LangGraph, CrewAI, or the OpenAI Agents SDK. Full control over architecture, data handling, and behavior.

Strengths: maximum customization. The agent fits your workflow exactly, including the edge cases that no vendor is going to support. If the agent is core to your differentiation, this is the only option that doesn't externalize your IP.

Failure modes: this is where the 75% number comes from. Building production-grade agents requires a stack of capabilities most enterprise engineering teams don't have in steady-state: prompt engineers who understand evaluation and regression testing, ML platform engineers who can build and operate inference infrastructure, and reliability engineers experienced in non-deterministic failure modes. Time to production runs 6 to 18 months. Total cost of ownership over three years runs $680K to $1.59M for a single agent in the public benchmarks, with 65% of total cost arriving after initial deployment.⁴ The infrastructure also keeps shifting. What you build on this quarter will likely need rearchitecting within twelve months as the framework ecosystem keeps churning.

Borrow

You hire a senior team for a fixed scope to ship a specific agent into production, with knowledge transfer to your team baked into the engagement. Not staff augmentation (you're not renting bodies, you're renting an outcome). Not a Big 4 transformation engagement (you're not paying for a six-month strategy phase). The borrow option, done well, is a 10 to 80 day engagement that ends with an agent in production and your team trained to run it.

Strengths: time to production is shorter than build (because the senior team has done this before), customization is higher than buy (because you own the IP at the end), and total cost is meaningfully lower than build because you're not absorbing the long tail of maintenance during the steep part of the learning curve. The third number, learning, is the one most enterprises don't price correctly. Borrowing brings in operators who have shipped this exact pattern before, which means your team learns by doing alongside someone who's already made the mistakes.

Failure modes: the borrow option produces bad outcomes when the engagement isn't outcome-tied (you end up paying for time, not work shipped), when there's no senior accountability (you end up with junior contractors and a partner who reviews quarterly), or when knowledge transfer isn't built into the SOW (you end up with a working agent and zero internal capability to extend it).

The decision frame

The framework below is what we'd use ourselves. It produces a default answer for each agent in your portfolio. It's deliberately not a scorecard with weighted columns, because those produce false precision. It's four questions that, answered honestly, point you at the right option most of the time.

The decision matrix

Run those four questions and you usually land somewhere predictable.

• Commodity workflow + no internal capability + time pressure: buy. The vendor absorbs everything you're not equipped to absorb.
• Differentiating workflow + strong internal capability + no time pressure: build. This is the legitimate build case.
• Differentiating workflow + capability gap + time pressure: borrow. Bring in the senior team, ship the agent, transfer the skills, then run it yourselves.
• Differentiating workflow + strong capability + time pressure: build, but with borrowed senior capacity for the first sprint to compress the learning curve. This is the hybrid borrow case and it's the most under-priced option in the market.
• Multiple agents, mix of differentiating and commodity: hybrid by design. Buy the commodity, build or borrow the differentiating, and own the seam yourself.

The Gartner cancellation wave isn't going to claim the enterprises that found the best vendor or built the cleverest custom system. It will claim the ones who accumulated technical and governance debt at the seam.

What to actually do this week

If you're a CIO or COO walking into this decision, here's the sequence that produces the fewest regrets.

Inventory. List every agent in production, in pilot, and in the proposal stage. For each one, write down which of the three options it's currently following, and which of the four questions argues for that choice. You'll find at least one agent in the wrong column. That's the first thing to fix.

Identify the seam. Whatever the answer to question 4 is for your portfolio, name the team that owns it. If no team owns it, that's the second thing to fix. The seam is your authorization model, your audit trail, your observability, and your fallback when an agent breaks. It belongs to you, not your vendor.

Test borrow on something specific. If your default has been buy or build, take one agent that's stalled and run a small borrow engagement against it. Outcome-tied, time-boxed, with knowledge transfer in the SOW. Use it as a calibration exercise. Most enterprises that try borrow once add it to their default mix because the time-to-production and team-uplift numbers are meaningfully better than what build produces.

Stop treating each agent as an isolated decision. The hybrid trap is accumulation. Each individual decision looks reasonable in isolation; the portfolio looks chaotic in aggregate. Run the four questions at the portfolio level too, not just per-agent. The right number of frameworks to govern your agents is one. The right number of authorization models is one. The right number of observability platforms is one. If you're running more than one of any of those, that's the seam debt that the cancellation wave is going to claim.

Closing thought

Build is the hardest of the three options to do well, and most enterprises overestimate their capacity for it. Buy is the safest if your workflows are commodity, but the lock-in compounds. Borrow is the option most leaders haven't sized because it doesn't fit either of the procurement playbooks they're used to. The teams that get the next two years right will run all three deliberately, with a clear policy for which goes where, and with the seam between them owned in-house.

The bad outcome isn't picking one option over another. It's drifting into a hybrid that nobody designed, governed, or priced. Most enterprises are already in that state. The work is to make it deliberate.