# why cloud coding agents should be harness agnostic
Why we’re focused on the infrastructure to run any coding agent, including the harnesses companies build themselves.
- Author: Saai Arora
- Published: 2026-09-10
- Category: Company
- Canonical: https://replicas.dev/blog/why-cloud-coding-agents-should-be-harness-agnostic
there are coding agent companies making the bet that there will be a best harness in the world, and that it will be theirs. when i look at companies like cursor and cognition, that's the bet i see them making.
i think it's the wrong bet for us to make.
a harness is the code around the model that lets it work as an agent. the tools it can call, the system prompts, how it manages context, and how it keeps working after a tool returns. changing those things can change how well an agent performs, even when the model stays the same.
the parts of a harness. swap any of them and the same model behaves differently.
building a good one is hard. building one that stays better than everything else is a much bigger commitment.
## you're betting against competition
you have to believe that your team will keep building a better harness than the model providers, other coding agent companies, and all of the people working on open-source alternatives. even if you manage to do that today, you have to keep doing it as the models change.
it reminds me of the idea that the early model providers would stay so far ahead that nobody else would catch up. then we got models like [deepseek r1](https://deepseek.com/en/news/deepseek-r1/) and [qwen3-coder](https://qwenlm.github.io/blog/qwen3-coder/), with open weights that other teams could use and build on. i don't think we should assume the competition around harnesses will be any less aggressive.
## it's hard without post-training the model
it's incredibly hard to build a state-of-the-art harness if you can't post-train the underlying model to work well with it.
you can spend a lot of time changing tools and system prompts to get a model to behave the way you want. a company that also controls training can change the tools, train the model to use them, see where it fails, and repeat. the model gets better at working inside the exact harness that users will get.
[cursor does this with composer](https://cursor.com/blog/composer-2-technical-report). cognition released [swe-2](https://cognition.com/blog/swe-2) today, built by post-training kimi k3. so this advantage extends beyond the original model providers. but competing with it means taking on model training alongside everything else you're already building.
we don't want to spend our time trying to win that race.
## harnesses are built for different things
[pi](https://pi.dev/) gives you a small core that you can customize heavily. you can change its tools, extend its behavior, and control what goes into its context. [opencode's v2 beta](https://opencode.ai/v2/docs) uses [code mode for mcp tools by default](https://opencode.ai/v2/docs/mcp-servers). these are different decisions about how an agent should work, and different people will prefer them for different reasons.
choosing a harness for a workspace. everything else about the workspace stays the same.
## everything around the harness
so we want replicas to work with whichever harness makes sense for the task.
the work we're interested in is everything required to put that harness in the cloud and make it useful.
- how quickly can we give it a computer with your repositories and dependencies already installed?
- can you trigger it from slack, linear, github, or your phone?
- does it have access to the tools your team uses?
- can it run the app, test what it changed, and show you the result?
those problems take a lot of work. we've spent months making workspace startup faster and the agent's computer easier to use. there is still a lot we want to improve. choosing to focus here gives us more time to do it.
it also means that the work carries over when you change agents. the environment you configured and the connections you set up should be useful whether you're running claude code, codex, pi, or something that hasn't been released yet. that's what we're building toward.
an environment in replicas: repositories, a system prompt, start and warm hooks, plus variables, files, skills, and mcps. set it up once and every harness gets it.
we've been adamant about this focus since the start of replicas. we want to build the best cloud coding agent experience for any harness out there.
## bring your own inference
the same thinking is why we let users bring their own inference. you connect your supported subscriptions or api keys, and choose the models you want to use. replicas charges for the platform and workspace usage, while inference stays with your provider. [credentials](https://docs.replicas.dev/admin/credentials), [billing](https://docs.replicas.dev/admin/billing).
this gives you control over both parts of the cost. you can change the model or inference provider as your needs change, while continuing to use the environments, integrations, and automations you've already set up in replicas.
## bring your own harness
longer term, we also want companies to be able to connect their own harness to replicas.
companies are already building agents for their own engineering teams. [stripe has minions](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents). other teams will have their own tools, workflows, and ideas about how an agent should work. it makes sense that some of them will want to build the harness themselves.
if you've built a harness that works well for your company, we want you to be able to connect it to replicas and get the same environments, integrations, and ways to trigger and manage work. you should be able to focus on what makes your agent useful while we handle running it in the cloud.
a teammate approves in slack, and replicas reports the merged pull request back in the thread.
that's part of what we mean by helping you build your software factory. the platform should work with the agents you choose, including the ones you build yourself.
