Every engineering team hits the same fork: build or buy the harness, the loop of tools, sandbox, memory and rules that wraps the model. It is where performance and differentiation live, yet most decide by instinct or licence fee alone.
The conventional view treats build-or-buy as one decision: buy to avoid engineering cost, or build to escape the model bill. A decent model with a great harness beats a great model with a bad harness, as Addy Osmani puts it.
The frame breaks when you look at Coinbase, Shopify and Ramp: they pay Anthropic and build their own harness anyway, which licence-first logic cannot explain. The way to make the call is a total-cost-of-ownership lens that counts what the price sheet omits; the wider enterprise coding agent ownership picture is covered separately.
Why are companies like Coinbase, Shopify and Ramp building their own coding agents while still paying Anthropic?
Coinbase, Shopify and Ramp pay Anthropic and build in-house because the model is a purchased input while the harness is the owned lever. They wrap a bought base, Claude Code and the Claude Agent SDK, with memory, routing, quality gates and governance. The point is differentiation and control over the loop; the model bill is not the thing they are trying to remove.
The pattern is consistent: Claude Code handles the reasoning, debugging and architectural decisions, while the custom layer adds memory, task routing and quality gates. The model stays the reasoning engine while the custom layer scaffolds around it.
Shopify layers memory, routing and quality gates over Claude Code. Ramp’s Inspect carries more than half its merged PRs, up from 30 per cent, according to research tracking in-house agents. Coinbase wraps Claude Code with custom scaffolding, Skills and MCPs.
Ownership here means controlling the loop. The model vendor relationship is unchanged, and the model bill remains; that is the economic shape. This connects to the full harness picture and why the harness outperforms the model.
What does an enterprise actually own when it builds its own coding agent harness?
An enterprise building its own harness owns the primitives it writes and ratchets in after real failures: context engineering (what enters the context window), orchestration (the model-tool loop), memory and governance. It does not own the model, which stays a purchased input, nor the commodity runtime of sessions, sandboxes and tracing. Own the judgment, buy the runtime.
Agent = Model + Harness: if you are not the model, you are the harness, a framing from Builder.io. Context is the layer where failure is most often blamed, so that is where ownership pays off; the runtime is cheap to delegate.
Context engineering and orchestration are the primitives most commonly built in-house, and the two most common cost drivers. Context is scarce, and orchestration adds token overhead and latency to every run, per Anthropic’s harness work.
The dividing line is commodity runtime versus product judgment. Move sessions, sandboxes, tracing and event streams to managed infrastructure. Keep judgment, evidence standards and publication gates local.
What should I look for before committing to an in-house harness?
Run a portability audit: which components (state, memory, workflow definitions and evaluation data) stay portable, and in what format, if you migrate in 18 months (the question Augment Code suggests asking).
Which harness primitives should you own versus buy off the shelf?
Buy the SDK and runtime primitives (the Claude Agent SDK and the OpenAI Agents SDK) plus ready-made tools such as GitHub Copilot. Own the ones that encode your team’s taste, standards and institutional memory. The list of what a harness contains, the lock-in a build does not remove, and the cost of governing what you own map the two sides of that split.
How should I evaluate whether to build or buy a coding agent harness for my team?
Evaluate per primitive, not for the whole harness; control, portability, differentiation and team capacity point in different directions for each layer. Ask one question per primitive: is this where we differentiate, or is it commodity runtime a vendor already runs better? Weigh OpenAI’s Codex against Anthropic’s Claude Managed Agents on data residency, extensibility and switching cost, not raw capability.
Four criteria decide the build case, and it wins only where all four align. On most layers they will not, which is why the decision stays per-primitive.
OpenAI’s Codex (Agents API) vs Anthropic’s Managed Agents: which fits an enterprise?
Both are managed paths, and capability is near parity. The choice turns on data residency, extensibility and switching cost. Anthropic rents the harness by the hour, while OpenAI hands you the blueprints and lets you bring your own compute; the OpenAI Agents SDK ships a model-native harness with sandbox execution, sessions and tracing.
Is building your own harness a trap?
Building the wrong layer (commodity runtime, for status) is the trap. Owning the layer you differentiate on is the point; the trap is re-implementing what the vendor already gives away.
Do you need to own the harness if vendors keep giving it away free?
A free managed harness is still not yours: it carries switching costs and dependence on the vendor’s runtime and migration path.
How do I assess the total cost of ownership of an in-house harness against a managed alternative?
Build the cost stack beyond licence fees: engineering time, evaluation infrastructure, observability, governance and compliance, and ongoing maintenance, plus inference spend and switching cost. TrueForge, MIT-licensed, comes in at $8.50 per run against Claude Managed Agents at $11.80, roughly 30 per cent cheaper, but only at parity accuracy. Bring-your-own-compute cuts the per-run price but moves sandbox, credentials and audit trail onto your team.
Most teams anchor on the first two lines of the bill and skip the rest.
Claude Managed Agents vs TrueForge: which is cheaper at parity accuracy?
TrueForge is cheaper when accuracy holds at parity. The differential is conditional: an accuracy gap erases the saving, because a weaker harness pays the difference back in rework and review time.
Managed service vs bring-your-own-compute: what does the pricing divergence mean for a mid-size team?
BYO-compute drops the per-run price but transfers operational ownership of the sandbox, credentials and audit trail to your team. For a 50 to 500 person team, that divergence is where the decision turns.
Evaluation and governance stay directional, so price them rather than assume them away: budget four to eight weeks of engineering for evaluation infrastructure, and expect compliance to add 20 to 40 per cent. AI FinOps and cost attribution are the missing discipline. Those two threads lead to the cost of governing what you own and the economics of self-hosting.
Owning a harness means owning the primitives that encode your judgment and buying the commodity runtime. The model stays a purchased input, the loop is the thing you build, and the real cost sits in everything the price sheet omits.
Across the full harness picture, the question to carry into the budget is the same for every primitive: do you differentiate here, or does a vendor already run it as commodity?
Frequently Asked Questions
Is a coding agent harness the same thing as the AI model?
No. The model is the reasoning engine you buy; the harness is everything around it, the loop of tools, sandbox, memory, context and rules that decides what the model sees and does. Using the Agent = Model + Harness equation, if you are not the model, you are the harness. That is why two teams on the same Claude model can ship wildly different results.
How long does it realistically take to build an in-house coding agent harness?
Plan for months, not weeks, and treat it as an ongoing product rather than a project. A usable first version might land in 4 to 12 weeks, but the harness only becomes valuable once you ratchet in the primitives that encode your standards after real failures. Budget roughly 4 to 8 weeks of engineering just for evaluation infrastructure, and expect maintenance to continue indefinitely.
What justifies building a harness instead of buying one?
What justifies building is capacity and differentiation, not competitor envy. Build when a platform or developer-productivity team can own the loop full-time and the primitives encode something rivals cannot copy. For most mid-size teams that means buying the runtime and spending scarce engineers on the judgment layer. If no one can maintain it ongoing, a managed harness wins by default.
What happens if our model vendor changes its API, pricing or terms?
You absorb it, which is exactly why ownership matters. The model bill remains either way, so the harness is your hedge: if your context engineering, memory and orchestration sit in primitives you own, a vendor change becomes a swap rather than a rebuild. That is why the named enterprises pay Anthropic and build their own loop, so the model stays a replaceable input.
Does building our own harness mean we can switch between models freely?
No, not automatically. Portability is a design choice you make in advance, not a free consequence of building. If your workflow definitions, memory and evaluation data are locked to one vendor’s format, swapping the model is still expensive. Run a portability audit and keep state, memory and eval data in open formats if model-agnosticism is a goal.
Doesn’t open source remove the licence cost and make it cheaper?
Not necessarily, because open source removes the licence line, not the total cost of ownership. An MIT-licensed harness can undercut a managed one on price per run and still lose once you count evaluation, observability, governance and maintenance. The comparison is only real at parity accuracy: a weaker harness quietly pays the saving back in rework and review time.
What skills does a team need to build and maintain a coding agent harness?
You need context engineers and platform engineers more than ML researchers. The scarce skills are prompt and context design, orchestration, evaluation design, observability and governance, plus the discipline to run AI FinOps and attribute cost per run. If your team cannot staff evaluation and maintenance ongoing, a managed harness will almost always beat a neglected in-house one.
How do we know if our harness is genuinely better than a managed alternative?
Measure outcome, not vibes. Build an evaluation set drawn from your own repositories and compare task success, accuracy at parity and cost per resolved task, not cost per run. If your in-house harness only wins on a benchmark it was tuned for, it is not better, it is overfitted. Track resolved-task cost and review burden monthly, because accuracy gaps surface slowly.
What is MCP, and why does it matter for a harness we own?
MCP, the Model Context Protocol, is the open standard for connecting models to tools and data sources, and it is a portability lever. Adopting it keeps your tool integrations reusable across models and runtimes instead of tied to one vendor’s plugin system. For a team building its own harness, MCP reduces the cost of moving primitives between providers later.
Can we move from a managed harness to an in-house one later?
Yes, but the migration cost depends on what you kept portable. If your memory, workflow definitions and evaluation data sit in vendor-proprietary formats, moving later means rebuilding them from scratch under pressure. The cheaper path is often hybrid: buy the runtime today, own the judgment layers from day one, and keep exports open so the eventual shift is a migration, not a rewrite.
Why do security and compliance teams care about who owns the harness?
Because the harness, not the model, is where credentials, sandbox boundaries, audit trails and publication gates live. Owning those primitives gives you control over where code and data flow and how every agent action is logged; buying them means inheriting the vendor’s controls and their compliance timeline. Expect governance and compliance to add roughly 20 to 40% to build costs, which the price sheet never shows.
Does the harness matter more than the model itself for real-world results?
Increasingly, yes. Frontier models sit near parity on capability, so the harness is where performance and differentiation actually live. The harness determines what enters the context window, how tools are orchestrated and what evidence a change must clear. Two teams on the same model can differ dramatically because one owns its loop and the other accepts a default.
