Adopt the Agent. Build the Loop.

Adopt the Agent. Build the Loop.

Every engineering org I talk to is having the same argument right now: Cursor or Claude Code or Copilot. Which agent do we standardize on? Which one do we buy seats for? Which one is "best"?

It is the wrong fight. The agent is the most volatile, fastest-commoditizing part of your stack, and you are about to spend a quarter of meeting time picking the thing that will be replaced twice before the procurement contract renews.

I have watched this movie. Two years ago the argument was which model. I argued then that picking a model was the wrong unit of decision, because the model was the volatile layer and the durable thing was the eval suite and capability interface you built around it. Adopt the model. Build what is stable around it.

The same logic now applies one layer up. Adopt the agent. Build the loop.

You already learned this lesson

The models converged. By early 2026 the frontier had collapsed into a tight cluster, with open and proprietary models landing within a few points of each other and a handful of labs from OpenAI to Google to Anthropic trading the top spot every few weeks. The cutting edge is a race between organizations spending billions a year on it. Reasoning became a commodity somewhere in early 2025, and the price kept falling.

You are not going to out-research those labs. Neither am I. Building your own frontier model to get a coding agent is the 2026 version of building your own A/B testing framework, or your own analytics pipeline, or your own feature-flag service. We have run this experiment a hundred times, and the homegrown version loses: the off-the-shelf option laps it inside a year. Dan McKinley's Choose Boring Technology called this your supply of "innovation tokens": you get a small, fixed number, and spending them on undifferentiated infrastructure is how you quietly go out of business while feeling productive.

The coding agent is now boring technology in McKinley's exact sense. That is a compliment. It means you should buy it and move on.

What "adopt" actually means

Buy the model. Buy the agent runtime, the harness, the thing that runs the loop and calls the tools: Claude Code, Cursor, Copilot, OpenCode, whichever wins your eval this quarter. Pay someone else to keep it on the frontier so you can spend your own engineers on finding product-market fit for whatever you are actually building.

There is exactly one exception. If being the agent orchestrator is your product, if you are selling the harness itself, then build it, because that is the thing you are differentiating on. For everyone else, the harness is a cost center you are weirdly excited about. The honest question for that Cursor-vs-Claude-Code meeting is whether you are an agent-orchestration company. If you are not, pick one quickly, keep the switching cost cheap, and go build the part that is actually yours.

What you build is the loop

No vendor sells you this part, because it is specific to your codebase, your systems, your users, and your business. This is where the engineering investment goes:

• Your workflows, your agents, your instruction files. The natural-language definitions that tell the agent how to think, how your team works, which tools it is allowed to touch, and what "done" looks like in your repo. This is real engineering work, and it is yours to write.
• Deep integration into your systems. The plumbing that lets the agent reach the rest of your tooling, the systems that build, ship, and monitor your code: command-line tools and MCP servers (Model Context Protocol, the emerging standard for how agents call external tools) wired into your build, your deploy, your ticketing, your observability. Armin Ronacher, who builds agents from the product side, makes the case that the durable work is the loop and the tool wiring itself, not the framework you wrap around it. From wherever you sit, the conclusion is the same: the integration is the work.
• Recipes and cookbooks for your teams. The skill libraries that encode your architecture decisions and clean-code conventions, with concrete examples of which prompts produce good results for which tasks. I made the longer version of this argument last year: the agent does not see your system, it sees your description of your system, and the quality of that description is the quality ceiling of the output.

None of this is free. The loop is an owned platform investment with a maintenance tax. It needs a team, and it has to track the rented layers underneath it as they shift every few weeks. A half-built loop with brittle gates and stale instruction files can be worse than none. Budget for it like the product it is.

The evidence that this is where the value lives is piling up in public. Dropbox, where I work on AI products, just published a post describing Nova, "an internal service for running coding agents in our cloud" (everything below comes from that public post). The notable part is the layer around the agents: isolated sessions that snapshot the monorepo at a specific commit, validation loops that run after the agent finishes, and skills, plugins, and MCP integrations including access to observability systems. Dropbox calls it a "platform approach" so agents apply across internal workflows instead of one-off implementations.

Cloudflare wrote up the same move in April. Instead of building a code review agent from scratch, they built CI-native orchestration around OpenCode, an open-source agent, fanning out up to seven specialized reviewers per merge request behind a coordinator agent that dedupes the findings. In one 30-day window the system ran 131,246 review runs across 48,095 merge requests, median review under four minutes, about $1.19 each. All of that value sits in the orchestration they wrote.

I have also watched the inverse happen. A team picks the "best" agent, buys the seats, declares AI adoption done, and then nothing changes. Six weeks later usage is flat and the few PRs the agent produces sit unreviewed, because no one built the CI gates to absorb them, the cookbook to make the output match the codebase, or the integration to let the agent see anything beyond the open file. The tool was fine. They never built the loop around it. (Adoption has a culture half too, engineer trust and ownership and incentives, which is its own problem. The loop is the half teams skip on the infrastructure side.)

The loop is the moat

You cannot buy this loop, and that is exactly why it is worth building. It is made of your ticketing system, your test suite, your deploy pipeline, your data, and your definition of a good fix. It is assembled out of the specific shape of your business, so no vendor can sell it to you.

The front half of it already ships. GitHub shipped it in May 2025: you assign a GitHub issue to Copilot, and it boots a VM, clones the repo, analyzes the codebase, writes the code, runs the tests, and pushes commits to a draft pull request before tagging you for review. Assign an issue, get a PR. That ships in production today.

Now wire that into your business. A user reports a bug in your feedback system. That report becomes a ticket. The ticket kicks off an agent that reproduces, fixes, tests, and opens a PR. A senior engineer reviews the change at the design level while CI agents handle the line-level checks. This is the pipeline shape I sketched back in 2024, now with the front end connected straight to the thing your users complain about. The system starts to self-heal, and the human moves up to judgment: is this the right fix, does it match the architecture, should we ship it.

The model is rented. The agent is rented. The loop is the only thing that compounds, and it compounds for you alone.

One warning: do not turn the loop into a usage dashboard. I went after that failure mode in detail recently, and it applies double here. Build the loop because it ships fixes faster, and measure it on the fixes, not the tokens.

The boundary

If you take one thing from this, take the line:

The orgs that win the next two years will not be the ones that picked the best agent. That choice ages out in a quarter. They will be the ones who wired the tightest loop between a user reporting a problem and a reviewed fix going out the door. Rent the agent and keep the switch cheap. Then go build the only thing that was ever going to be yours.