Augment sells Cosmos and Auggie CLI to Harness, and Kilo urges developer control

Augment has agreed to sell Cosmos, Auggie CLI, the Code Context Engine and related technology to Harness, with the team behind those products joining as well. In a blog post, Kilo's Emilie Schario argues the deal shows why developers need more control over the coding agents they build workflows around.
- Augment agreed to sell Cosmos, Auggie CLI, the Code Context Engine and related technology to Harness, and the team joins too.
- Harness plans to connect Augment's code context with delivery and production context and says customers can keep using their preferred coding tools.
- Kilo's Emilie Schario argues that as agents become infrastructure, teams risk dependency on the tool they build workflows around.
- According to Kilo, its agent is open source, supports multiple model providers, and allows bring-your-own keys or local models.
- Schario suggests testing a real workflow by switching the model or an instruction and checking what could be taken elsewhere.
What Augment and Harness agreed
According to the Kilo post, Augment announced that it has agreed to sell Cosmos, Auggie CLI, the Code Context Engine and related technology to Harness. The team behind those products will join Harness too.
The reason Augment gave, as relayed by Schario, is that these capabilities can reach more customers and deliver more value inside a broader development platform. Schario says this points to where the coding agent market is heading: as agents take on more work, they become more deeply connected to the systems around them, which makes integration more valuable and developer control more important.
The post also says Harness describes plans to connect Augment's code context with delivery and production context. Harness has explicitly said customers can continue using their preferred coding tools. Schario calls that a useful commitment and says buyers should evaluate it as the products develop.
Why the choice of a coding agent is changing
Schario describes how a team's relationship with a coding tool deepens over time. It starts with asking the tool to explain a function or fix a bug. Then a team adds its own instructions, connects the tool to its issue tracker, configures the environment where it runs tests, and teaches it what a good pull request looks like and which actions require approval.
Some of that investment lives in the repository, some in configuration, and some may live inside the vendor's service. Changing the agent, the post says, means working out how much of that effort a team gets to keep. In Schario's framing, this is a different buying decision from choosing an autocomplete extension: a team is choosing a dependency in the way it builds software, and the better it works, the more gets built around it.
Schario says the goal is for time spent improving a workflow to keep paying off when a better model arrives, infrastructure requirements change, or a team uses a different tool for part of the work. Those changes should be ordinary maintenance, not a fresh rollout across the engineering organization.
Kilo's position on openness
The post acknowledges real benefits to bringing more of the workflow together. Developers spend less time moving context between tools, agents can use feedback from tests and reviews, and teams can set consistent expectations about what happens before a change is ready.
Schario says Kilo should be held to the same standard as Harness. She notes that Kilo joined Anaconda in July, and says connecting builder tools with more of the foundation their work depends on is useful when it expands what builders can do while preserving meaningful choice.
According to the post, Kilo's agent is open source, supports multiple model providers, and lets builders bring their own keys or use local models. That means the source can be inspected and modified, and a team can pick a different model without replacing its coding tool.
Schario adds that a license or a model picker is not the whole picture. Hosted services, integrations and stored context can create their own dependencies. She says builders should get clear answers on where their instructions live, what information integrations retain, and how much work it would take to move a recurring task elsewhere.
What teams can do before committing
The post offers a practical test for anyone trying a coding agent: take one real workflow through it, then change something. Switch the model, change an instruction, inspect the tools it called, and work out where the configuration lives and how another team member could reproduce it. Then ask what could be taken along if the workflow moved elsewhere.
Schario says this reveals something a demo cannot: how much control a team retains after the tool becomes useful. For buyers, the Augment and Harness deal is a prompt to ask those questions early, as coding agents move from add-ons to part of the development infrastructure.
Kilo Code: As coding agents become infrastructure, builders need more control

