What build-versus-buy actually looks like in agentic engineering

Most build-versus-buy debates assume you're choosing once, at the start, and living with it.

Agentic engineering doesn't work that way. The decision shows up at every layer of the stack, and the teams getting it right aren't the ones who picked "build" or "buy" as a philosophy. They're the ones who know which layer is which.

Patrick Dawkins, Upsun’s principal software engineer, helped build Upsun's internal AI review agent before Upsun Dispatch™ existed as a product, and later helped build Upsun Dispatch itself. 

Along the way, he made the same call at three different layers of the stack, and landed on a different answer each time. That's more useful than a framework, because it shows where the reasoning actually changes.

The tool sprawl nobody chose

Before there was a platform, there were laptops. Engineers picked their own tools, ran their own agents locally, and everyone assumed that was fine because it had always been fine. Dawkins watched the cracks show up.

"When you close your laptop, it stops running," he said. "You can't get on a plane where you don't have Wi-Fi, or just stop work and go to sleep for the night and leave your agents running." In London, he put it more plainly: getting on the Tube killed whatever an agent was in the middle of doing.

That's a minor annoyance for one person. At the scale of an engineering org, it's a governance gap. No one outside that one laptop has any visibility into what the agent actually did. The "buy" decision here wasn't really a decision at all. Letting each engineer pick their own tool became the org's entire AI strategy by default, without anyone signing off on it. 

The fix wasn't a better individual tool. It was building something centralized enough that the work didn't vanish the moment a screen closed.

The cheap path, and what it costs later

There's a faster way to get an agent doing real work, and Dawkins doesn't pretend otherwise. "You can use things like OpenClaude, or Claude with dangerously-skip-permissions, as an individual," he said. No approval gates, no constraints, full tool access, run until the goal is done. "But as an organization, it doesn't help us."

The gap between those two sentences is the whole argument. Skipping permissions works fine until a compliance auditor or a regulated customer starts asking questions you can't answer. 

Dawkins calls the alternative harness engineering: giving an agent enough tools to be genuinely useful while constraining exactly what it's allowed to touch, running it inside a sandbox that gets thrown away the moment the task ends. 

It's slower to build. It's also the version that holds up when someone asks how you know it's safe.

What an actual vendor decision looks like

When Dawkins needed to pick a sandbox provider for Dispatch, he didn't guess. His team built throwaway prototypes across several options to see how each one actually behaved.

The result was almost anticlimactic. The options came back close enough in capability that the choice barely mattered on technical merit alone. So the team picked one and deliberately kept the infrastructure layer decoupled from it, treating the decision as reversible rather than final. 

That's the real skill in a build-versus-buy call at the infrastructure layer: recognizing when the choice barely matters, and building for the ability to change your mind rather than betting on having picked correctly the first time.

Buy the commodity, build the judgment

The same logic shows up again one layer up, at the model itself. Upsun Dispatch started by letting customers bring their own Anthropic key rather than building a proprietary model-access layer from day one. Buy the commodity. Don't rebuild what a frontier lab already does well.

What Dawkins is building instead is the part that can't be bought off the shelf: an evaluation framework to compare models scientifically, so choices about cost, quality, and reasoning effort stop being guesswork. 

"You can quite often get what you pay for," he said, "just not all the time." Knowing which times, for which tasks, is the actual product.

The pattern underneath all three decisions

Buy the parts that are genuinely commodity: a sandbox runtime, a frontier model, the raw compute underneath. Build the parts where your own judgment is actually the product: the constraints, the evaluation, the reasoning you'd have to defend to someone who didn't build it. 

Upsun Dispatch exists because Dawkins ran into that fork three times and kept landing on the same answer.

• New here? Read the introduction to Upsun Dispatch.
• Want to help build it? Apply to the founding design partner cohort.