Congratulations to Matt and the Augment team on their next chapter with Harness. Building tools that developers trust with their code is hard work. The team has taken on important problems in codebase understanding and agentic development, and I’m glad they’ll have the opportunity to keep working on them.
Augment announced that it 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.
The reason they gave deserves attention: those capabilities can reach more customers and deliver more value inside a broader development platform.
I think that tells us something about where the coding agent market is going. As agents take on more work, they become more deeply connected to the systems around them. That makes integration more valuable. It also makes developer control more important.
You’re investing in more than the tool
Consider how your relationship with a coding tool changes over time.
You start by asking it to explain a function or fix a bug. Then you give it your team’s instructions. You connect it to your issue tracker. You configure the environment where it runs tests. You teach it what a good pull request looks like and which actions require approval.
Eventually, you have invested quite a bit in how that tool works. Some of that investment lives in your repository. Some lives in configuration. Some may live inside the vendor’s service.
Changing the agent now means figuring out how much of that work you get to keep.
That is a different buying decision from choosing an autocomplete extension. You are choosing a dependency in the way your team builds software. And the better that dependency works, the more you are likely to build around it.
This is why I care about openness. I want the time a team spends improving its workflow to keep paying off when a better model arrives, its infrastructure requirements change, or it decides to use a different tool for part of the work.
Those changes should be ordinary maintenance. They should not require a fresh rollout across the engineering organization every time.
Integration has to preserve choice
There are 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. Teams can establish consistent expectations about what happens before a change is ready.
Harness describes exactly that ambition, including plans to connect Augment’s code context with delivery and production context. It also explicitly says customers can continue using their preferred coding tools. That is a useful commitment, and one buyers should evaluate as the products develop.
We should hold ourselves to the same standard.
Kilo joined Anaconda in July. We see value in connecting the tools builders use with more of the foundation their work depends on. This is useful when those connections expand what builders can do while preserving their ability to make meaningful choices, as we have with Kilo and Anaconda.
Control needs to be practical
Kilo’s agent is open source, supports multiple model providers, and lets builders bring their own keys or use local models. Those are practical ways to retain control over parts of the workflow. The source can be inspected and modified. A team can choose a different model without replacing its coding tool.
There is also more to evaluate than a license or a model picker. Hosted services, integrations, and stored context can introduce their own dependencies. Builders deserve clear answers about those, too.
The ability to change models matters. So does knowing where your instructions live, what information your integrations retain, and how much work it would take to move a recurring task somewhere else.
These details become more consequential as you ask the agent to do more.
Try changing something before you commit
When you try a coding agent, take one real workflow through it. Then change something.
Switch the model. Change an instruction. Inspect the tools it called. Work out where the configuration lives and how another person on your team would reproduce it. Ask what you could take with you if you moved that workflow elsewhere.
You will learn something a demo cannot tell you: how much control you retain after the tool becomes useful.
The market will keep changing. Our job at Kilo is to help builders benefit from that change while keeping the work they have already put into building.