Build vs Buy Flipped. Keeping It Is the Hard Part.

Build vs buy flipped this year, and this week the industry finally started arguing about the right half of it. McKinsey’s numbers say roughly a third of organizations killed a software purchase because coding agents could build the thing instead. Salesforce previewed a governance layer for agents it doesn’t even sell. OpenAI turned its own agent harness into an API anyone can call. Four days, three announcements, one underlying admission: producing software stopped being the bottleneck, and nobody has a settled answer for what happens to it afterward.

Here’s the week, and what it actually changes for anyone whose AI is about to start building things in their CRM.

A Third of Companies Skipped the Purchase

The headline number comes out of McKinsey’s State of AI 2026 survey: 32% of organizations chose to build rather than buy, specifically because agentic coding tools made building viable. Among the firms McKinsey classifies as high performers — the small slice deriving meaningful EBIT from AI — that figure runs closer to half. Large enterprises above $1B in revenue report 40% now scaling agents across at least one function, up from 27%.

Read that as a procurement story and you’ll miss it. The interesting part isn’t that companies are building more. It’s what they’re building. Nobody is replacing their ERP with a coding agent. They’re killing the recurring-fee point solution that existed only because their CRM couldn’t do one specific thing — the routing tool, the rollup add-on, the alerting bolt-on. That layer of software was always a tax on a gap. The gap is now closeable in an afternoon.

If you’ve been reading this blog for a while, that’s the same argument as the AppExchange vs. custom build question, except now there’s survey data underneath it.

Salesforce Previewed a Control Plane for Agents It Doesn’t Own

On September 10, ahead of Dreamforce, Salesforce previewed its Trusted Enterprise AI Harness and an AI Control Plane for discovering, registering, and managing agents across an organization — including agents from other vendors, reached over APIs and MCP. The pitch, per VentureBeat’s coverage, rests on a finding that 85% of surveyed enterprises already run two or more agent orchestration platforms, averaging 3.1 apiece.

Two things about this are worth sitting with.

The first is that Salesforce has read the room correctly. The agent sprawl is real, most of it isn’t theirs, and whoever owns the registry owns the relationship. That’s a smart land grab.

The second is the timeline: general availability in early FY28. That’s February 2027. Pricing and packaging arrive “closer to GA.” So the governance story for multi-vendor agents is a preview with roughly two quarters of runway before it exists, and the agents are already in the building. This is the recurring shape of the Agentforce strategy — an answer that’s architecturally sound and calendar-distant — and it’s why the Agentforce alternative question keeps coming up in different clothes. Agentforce puts an agent inside your CRM — the same gap that shows up when you line it up against Microsoft’s copilots. It still doesn’t make your AI the developer of it.

OpenAI Made the Harness a Managed Service

The same day, OpenAI put its Agents API into public beta — the Codex harness as a managed service. Sessions that survive crashes. Automatic context compaction as a session approaches its limit. Tool search that loads definitions on demand instead of stuffing every schema into the prompt. Sandboxes either OpenAI-managed or from partners like Modal, Cloudflare, and E2B. No additional fee beyond tokens and tools.

Strip the marketing and this is an infrastructure concession: running an agent for long enough to finish real work is a systems problem, not a model problem. Context management, crash recovery, an isolated place to execute — those are the unglamorous parts, and OpenAI just decided they’re table stakes rather than differentiators.

Anyone who has watched an agent lose the thread thirty minutes into a build already knew that. It’s the same conclusion we landed on from the other direction in why agent isolation matters: the model is the easy part.

Attackers Are Already Running the Playbook

On September 8, Google Threat Intelligence Group published its latest AI threat tracker, documenting adversaries moving “from basic prompting to agentic AI workflows.” Two details stand out. GTIG found an exposed C2 server running a credential framework — complete with AGENTS.md and KNOWLEDGE.md files, because of course — managing over 23,800 harvested secrets in a live dashboard, many of them API keys for cloud and AI services. And in Q2, threat actors compromised a cloud resource and then planned, built, and executed a mass credential harvesting campaign in under six hours.

Google is careful to note it has not observed fully autonomous attack pipelines in the wild yet. Fine. The relevant lesson isn’t the threat forecast, it’s the operational one: 23,800 secrets in one dashboard is what happens when API keys are handed out and never inventoried. If you can’t answer “which credentials can act in my systems, and what did they do last week,” you have the same exposure whether the thing holding the key is an attacker’s agent or your own.

The Number Nobody Put in a Headline

Back to McKinsey, because the build-vs-buy coverage skipped the uncomfortable half. Internally built systems in that survey succeed roughly 33% of the time. Purchased tools succeed 67%.

Two-to-one against you. That gap is the actual news of the week, and it doesn’t mean building is a mistake — it means the industry celebrated getting good at producing software and has barely started on keeping it. A build that nobody can explain, that nobody snapshotted, that changed on a Thursday for reasons lost to a chat log — that build is in the failing two-thirds no matter how good the code was on day one.

Vendors read that gap and sell you a control plane. That’s a reasonable answer at enterprise scale, and it ships next year. There’s a cheaper answer available now, and it isn’t a product category: make every change visible, and make every deploy reversible. Not restricted — recoverable. The failure mode that kills in-house builds isn’t a bad change, it’s an unattributable one.

What Separates a Build That Survives

This is the whole thesis behind how Sentinel works, and it’s deliberately unambitious. Your AI connects over MCP to a machine that belongs to you, and it can genuinely develop against your CRM — read, write code, deploy. Every action it takes is logged: who, what, when. Snapshots are taken before deploys. Salesforce changes go sandbox-first with tests required. One write key at a time per org, unlimited read keys, so three people’s AI sessions can work the same org without silently overwriting each other.

None of that prevents your AI from building something dumb. It isn’t supposed to. It means when something dumb ships, you can see exactly what changed and roll it back — which is the difference between a build that lives in the 33% and one that doesn’t. The full version of that argument is in how AI-written changes stay safe, and the practical starting point is connecting Claude to your Salesforce org.

The control planes are coming. The question this week put in front of everyone is what you do in the meantime — and whether the things you build between now and then will still be explainable when they arrive.

If your AI is about to start building in your CRM and you’d rather not find out the hard way what it changed, that’s worth a conversation. Pricing is flat per Sentinel and is covered on a short demo call. Book a Demo Call and we’ll go through your org together.