Controllability Beats Magic Every Time

There is a tempting product strategy in the coding agent space: build a layer of abstraction on top of the agents, give it a catchy name, and sell the simplicity. The customer does not have to think about how the agent works. They just push a button and get code.

Enterprise buyers do not want that. Every single one we talk to wants full control.

The reason is simple. When you abstract away how the agent operates, you also abstract away the customer's ability to fix things when they break. And they always break. A company that just inherited 360 repos from three acquisitions does not need magic. They need a platform where they can define exactly how code reviews work, which repos get which treatment, and what standards the agent enforces. They need to be able to say "only flag backend Python issues" or "run this task deterministically" or "route this PR to the security team." That is not a feature request. That is the entire value proposition.

The granularity matters in practice. A VP of Engineering consolidating three acquired companies — Java in one codebase, Python in another, repos spread across GitLab, Bitbucket, and GitHub — does not want an agent that makes decisions for them. They want to control which skills load for which language, whether a review agent uses a frontier model or a cheaper one for simple enrichment, and which ticket status fires a trigger, because their product managers need time to finish writing the ticket before the agent enriches it.

We see this play out in live deals. A PE-backed company recently evaluated us against a competitor and was leaning the other way — until the flexibility difference became concrete. The competitor ships its own CLI, its own opinionated workflow, its own way of doing things. We are a harness of the harnesses: we wrap the coding agents engineers already use rather than replacing them, and the customer keeps control of the stack underneath. They chose flexibility. Another prospect was deciding between agent platforms and paying an AWS partner to build a fully internal tool from scratch. That is the real competitive set in enterprise. If your platform does not give serious teams control, they will conclude — not unreasonably — that they should just build their own.

Controllability also means getting defaults right while keeping every default steerable. Take something as small as how an agent delivers code. Some companies never want an agent pushing directly to a developer's branch, so the safe default is opening a separate PR against it. Other teams find that annoying and just want the commit on their branch. The wrong answer is to pick one behavior and hard-code it. The right answer is a steered default that a user can override in a single prompt or change permanently in their organization's settings. We rebuilt our entire agent loop around this principle. The old architecture had hard-coded logic that opened PRs on the agent's behalf — including PRs for accidental temp files the agent never meant to ship. The new architecture is an agent with tools in a loop inside a sandbox: the agent owns the action, and the customer owns the policy. Want two PRs from one task, a monorepo joke and its Ruby translation? Fine. Want commits pushed to a specific branch in a specific review workflow? Also fine. Modern models are smart enough to handle this; babysitting them with rigid scaffolding and bloated context does not make them safer, it makes them dumber.

This is why controllability is not optional for any platform targeting serious engineering organizations. The teams actually deploying agents in production treat the agent like software they own, not a service they rent. They want templates they can modify, review workflows they can customize, execution logic they can inspect, and the freedom to choose models and bring their own keys.

The competitors who build opaque abstraction layers will win demos. They will lose renewals. The first time an enterprise customer hits an edge case the abstraction cannot handle, they are stuck filing a support ticket instead of fixing it themselves — and engineering leaders do not tolerate that for long. Magic is a great pitch and a terrible contract. Control is harder to sell in a pitch deck and much easier to defend in a renewal conversation. And in enterprise, renewals are where the real money lives.