Developers do not want a wrapper around their coding agent. They want raw access to the real thing, running exactly the way it runs on their laptop, and they will walk away from any platform that gets between them and it.
We see this in almost every buying conversation now. Teams have invested months in a specific coding agent. They have built skills, tuned configurations, developed instincts for how it behaves. When a vendor says "use our proprietary agent instead," they are really saying "throw away everything you learned and trust our interpretation." Buyers hear that clearly, and increasingly they refuse. What they ask for is the opposite. Run the agent I already use. Let me swap it for a different one tomorrow. Do not lock me in at the layer where I have the most invested.
There is a technical version of the same lesson. Early on, everyone building agent platforms added determinism to the loop. Take the keys from the agent, script the critical steps, hand control back when the risky part is done. That instinct made sense when models were weaker. It no longer does. The agents are now good enough to run freely in the cloud, and every piece of magic you bolt onto the loop becomes a constraint your users trip over. The scaffolding that once felt like safety starts biting you.
This is why the harness layer keeps commoditizing while the layers around it do not. The coding agent itself is interchangeable, and the labs will keep improving all of them. What is not interchangeable is the infrastructure that runs those agents at scale, the environments they execute in, the visibility a team gets across every session, and the controllability enterprises actually demand before anything touches production. Own that, and it does not matter which agent wins.
If you are evaluating agent platforms, ask one question first. Can I bring the agent my team already uses, unwrapped, and leave with my work intact if I go? Vendors who answer no are betting their harness beats the entire frontier lab ecosystem. That is not a bet you should fund. Key takeaways
- Engineering teams have accumulated real workflow investment in specific coding agents, and they will not abandon it for a proprietary wrapper.
- Models are now good enough that hard-coded determinism inside the agent loop subtracts value instead of adding safety.
- The durable platform position is running the agents teams already use, unmodified, and owning the infrastructure around them.
FAQ
Why do developers reject wrapped coding agents?
Because they have already built skills, configurations, and habits around a specific agent. A wrapper forces them to relearn everything and locks them into one vendor's interpretation of how the agent should behave. Raw access preserves their investment and their optionality.
If the agent itself is not the moat, what is? Everything around the agent, including the compute it runs on, the environments it works in, the visibility teams get into its sessions, and the review and approval infrastructure. The harness is interchangeable. The operational layer is not.
Related Essays #
Wrap the Product in Services Until the Buyer Catches Up
Non-technical buyers cannot configure their own agents yet. The fastest path to revenue is selling the service of building agents for them.
Amplify the Tools They Already Trust
Enterprises are wary of single-vendor AI lock-in. The durable position is the agnostic layer that runs the coding agents teams already use, not a replacement for them.
From Agent to Platform: Why the GTM Is Services-Shaped
There is no winner-take-all platform in agents. The GTM is services-shaped, the harness is commoditized, and coding-agent companies have a narrow window to pivot before the floor falls out.