← Back to essays
·3 min read·By Ry Walker

Flexibility Is Not Optional for Agent Platforms

Flexibility Is Not Optional for Agent Platforms

Stage one of agentic engineering was tab autocomplete in the editor. Stage two was CLI-based coding agents on a developer's laptop. Stage three is running those CLIs in the cloud, triggered by tickets, alerts, releases — multiplayer, observable, integrated into existing workflows rather than siloed on one machine. Stage three is where every interesting enterprise question shows up. And the answer to almost every one of those questions is: the platform has to be flexible.

Flexible across CLIs, because the same coding CLI with the same model produces different results depending on the system prompt and harness. A team standardized on Claude Code for its main repo and Codex for its data pipelines does not want a platform that supports only one. The harness wraps the CLI; if you only support one harness, you have committed your customer to that one harness's bugs forever.

Flexible across models, because every customer with a real procurement department already has multiple model contracts. Selling tokens is not a business. The orchestration layer that lets teams bring their own keys and route work across providers is the business. Flexible across repos, because real engineering organizations have monorepos, polyrepos, submodules, vendored libraries, and at least three abandoned repositories that someone insists are still load-bearing. Coding agents that clone a single repo fall over the moment they encounter a type definition in a submodule. They invent types that already exist. They reference fields that do not match the actual schema. The fix is not a smarter model. It is a harness that understands repository topology.

Flexible on deployment, because EU data residency and self-hosted operation are not edge-case requirements. They are table stakes for regulated industries and any European customer. The competitive moat is running inside the customer's cloud with no data leaving their environment. Most SaaS-native competitors cannot satisfy that and never will.

Flexible on integration philosophy, because the best agent platforms do not force customers onto new tools. If the company uses SharePoint, the agent should use SharePoint. If they use Slack for approvals, the agent should use Slack for approvals. The moment you require a customer to migrate their data into your system, you have lost the enterprise sale. As I've argued in the agent buyer map, the buy cohort is the real market — and they are buying flexibility, not lock-in. Companies that win this will give developers the most freedom and customization in a way that remains sane.

Key takeaways

  • Platforms must support multiple CLIs, because the same model produces different results depending on the harness and system prompt.
  • Every customer with a real procurement department already has multiple model contracts. Selling tokens is not a business; orchestration is.
  • EU data residency and self-hosted deployment are not edge-case requirements. They are table stakes for regulated industries.

FAQ

Why does multi-CLI support matter?

The same coding CLI with the same model produces different results depending on the system prompt and harness. Teams standardize on different harnesses for different workloads — Claude Code for one repo, Codex for another. A platform that supports only one harness commits the customer to that harness's bugs forever.

Why is self-hosted deployment table stakes?

EU data residency and self-hosted operation are not edge cases. They are table stakes for regulated industries and European companies. Most SaaS-native competitors cannot satisfy that requirement and never will. The competitive moat is running inside the customer's cloud with no data leaving their environment.