Build vs. Buy Coding Agents: Why You Should Own the Platform

Stripe's minions merge 1,300+ pull requests a week with no human-written code. Sierra's Pinecone opens 70% of their PRs. Ramp is running 60%+ of their PRs through Inspect. You've probably read their write-ups and wondered if you should buy or build your own.

Those write-ups won't answer that question, because none of them are really about the platform. What they document is a team that could change whatever made the agent fail, on its own schedule, over and over.

Being able to iterate on the system your agents run on is the asset. It's the part that you can't buy.

I deploy coding agent systems into companies from teams of 10 engineers to entire orgs of 500. Here's what I see:

1. The portable part is the cheap part

The case made for buying is that the skills, MCPs, and rules are your differentiated layer and are all portable.

It's portable because it's text, and it's cheap because it's text. It assumes nothing about what runs underneath it. It isn't doing any of the work that is specific to you.

The offer is that you keep that layer and skip everything underneath. But underneath is where the cost is.

Underneath is your environment. Underneath is everything you want to change later. The community forums for cloud agent providers show what that looks like in practice: OTel support backlogged for months, per-user spend caps and network egress gated enterprise only, Android emulators an open thread with no reply.

All of these are not portability problems, they're roadmap problems — and it isn't your roadmap.

Across the deployments I've run, the blocker and challenges have never been skills. It has always been what's underneath.

2. The build is way smaller than it looks

Getting an agent into a VM is a weekend project; four nines and ten-second starts is a multi-quarter infrastructure project. That was true in 2024. It's much less true now.

Sandbox providers, durable session infrastructure, and open agent harnesses are commodity parts. There are now open-source MIT-licensed reference implementations — I maintain one. A 300-engineer company deployed it to their own infrastructure without talking to me first or signing an enterprise contract.

Getting the platform up and running was never multi-quarter. The long pole of these systems is environment capture and the company integration layer. Buying doesn't remove an hour of that and relocates it behind a platform boundary you can't modify.

3. Self-hosting the runtime isn't the same as owning the system

The strongest version of the buy case is that you shouldn't worry about control. You can deploy the runtime in your own network, use any model.

That changes where the compute runs, but it doesn't change what you're allowed to fix. Inference, planning and orchestration is still running in the vendor's cloud — you get to run the workers that execute tool calls.

Across deployments, I see teams hit the same issues:

RBAC — The moment more than one team is operating in the system, especially non-engineers, you need access controls. PMs are opening PRs, support is triaging customer issues. You need permissions that match your internal org policies.

Attribution — When an agent opens a PR, whose name is on the commit? On at least one platform it's the vendor's bot, and staff have confirmed there's no setting to change it and that self-hosting doesn't help. If the app authors the PR, someone can approve their own agent's changes.

Deployment topology — Teams that already own their infrastructure want the agents running on it. Their network, their egress rules, their audit trail. Not a vendor's definition of self-hosted.

On a system you own, each of these is a week. On one you bought, it's a ticket, and sometimes the answer is no.

Buy now, build later is backwards

The failures you get in month one are not the failures you get in month six.

Early on, most of your failures will be low hanging fruit. Missing documents, tuning a skill, adding a rule file. These are cheap and easy to fix. This is exactly when buying looks best.

Then non-engineers show up. Review volume goes from a couple of PRs a day to fifteen. Problems turn into attribution issues, access scoping, review routing, and spend control. A skill file won't fix a platform problem.

You make the call to buy before you see the real problems appear and when they do, it's too late.

When buying makes sense

A pretty simple criterion: if nobody is going to own the loop, buy.

Running a background agent system requires ongoing operations. The use cases will grow, and it requires a team to be able to iterate and handle this. I commonly see this falling under AI enablement, Developer productivity or platform teams. These teams have a directive to empower the organization and this fits perfectly into their mission.

Long-term, I think every org ends up running agent infrastructure, the same way platform teams run container infrastructure today.

Credit where it's due

The cloud platforms are good, and the teams building them are solving genuinely hard problems. The portable layer is real, and you should be writing those rules and skills either way. If you aren't running agents at all today, starting on someone else's platform beats a six-month planning exercise.

I'm Cole Murray. I build and deploy internal background agent systems — OpenInspect is the open-source one. If you're standing one up, I run a readiness review that shows you what breaks first.