Coding Agents: Why the Harness Makes the Difference (Part 1)

Last Updated on 11. November 2026

Coding agents have arrived in many development teams, including ours. Whether they actually help day to day, though, often depends less on the language model than on the coding agent harness: the skills, rules, tools, and project knowledge a team equips its agent with. Usually every team builds its own, and nobody really knows whether it pays off.

At mgm, we developed a method that turns this into a learning cycle: run and share harnesses securely, measure and improve the most successful ones on your own code, and make the result available to every team again. It grew out of our own day-to-day work. But many companies face exactly the same questions. This first part covers running and sharing. The second part is about measuring and improving.

Every team builds its own harness

mgm works across many locations on a large number of projects. In Aachen, a team has figured out which skills and rules make its coding agent deliver reliably good results on its project. A team in Leipzig is working on a very similar project and starting from scratch. We do hold best-practice sessions. But the AI world moves faster than experience spreads through the hallways.

Then there are two uncomfortable questions. First: What actually works? Whether a skill helps or just burns tokens is mostly a gut call today. Second: Where do the agents run, and what can they see? If you don’t offer developers a secure option, you get shadow IT, like the personal chat account that solves a coding problem “just this once.”

Our thesis: AI in software development is not a one-time tool rollout. It is a cycle you can measure and improve like any other engineering problem. And at the center of that cycle is not the model, but the harness.

Why the harness is the real lever for coding agents

The public debate mostly revolves around models: Which one is the best right now? In practice, though, no model works on its own. It sits inside a harness. That includes the agent app (such as Claude Code or OpenCode), the skills, the tools, the rules, and the project knowledge. Then there are MCP servers, which let the agent connect to external tools and data sources via the Model Context Protocol. Only harness and model together make up the agent a developer works with.

This has consequences: Same model, different harness, different result. It becomes especially clear with smaller open-weight models, whose weights are freely available so you can run them yourself. Many companies and public agencies need exactly that, because code and data must not leave their own data center. A large frontier model, meaning one of today’s most capable models, forgives a lot. A small model needs much more guidance. With the right harness, though, it can come close to the large models for many tasks, at a fraction of the cost.

The harness has a second property that sets it apart from the model: It belongs to the team. It consists of files that can be versioned, stored in the repository, passed on, and changed deliberately. That makes it exactly the place where a company can improve without waiting for the next model.

So the real question isn’t “Which model is best?” It is: Which harness, with which model, solves our tasks best on our infrastructure? And how do you find it without trying every conceivable combination?

The cycle at a glance

Our answer is a cycle with a built-in filter. Many harnesses emerge and get shared, but we only invest the effort to measure and improve the ones that prove themselves in practice. At mgm, we are developing this cycle under the name ESACA (European Sovereign Agentic Coding Appliance). All four steps run on the same AI layer, in your own data center or in the cloud.

• Run: the sandbox. Teams work with their harness in a secure, preconfigured environment. The configuration lives in the repository and can be shared.
• Share: the registry. Teams publish their harnesses centrally and adopt them in any other sandbox. This shows which setups catch on in practice.
• Measure: the benchmark. We automatically test the harnesses that have caught on against real tasks from our own projects.
• Improve: optimization. Whatever has been measured can be improved in a targeted way. The verified version goes back into the registry.

The principle: Teams experiment freely, usage shows what works, and only that gets measured and improved. Optimize once, use everywhere. Then the next round begins, because new models, new skills, and new projects keep shifting the picture. Let’s take a closer look at the first two steps.

Run: A sandbox that doesn’t get in the way

If you give developers an agent, you need to think about a sandbox. Three risks stand out. Credentials can leak through skills or MCP servers. The agent has the same permissions as the developer, on local and connected systems alike. And internal data can flow out.

Our approach is an isolated environment with a gateway in front of it. The sandbox only knows placeholders. The real credentials live in the gateway and are only inserted on the outgoing call. The gateway blocks connections to unknown destinations from the start.

Convenience matters at least as much as security. A cumbersome sandbox gets bypassed, because the unprotected agent in the terminal is just one command away. So the rule is: set it up once, store the harness together with the sandbox configuration in the repository, and every colleague starts with the same environment, including skills and MCP servers and support for common IDEs.

This also shifts the perspective. Instead of optimizing each developer individually, we optimize the team. Every project gets a shared base harness, and everyone can add their own skills on top. That is the first shared harness, and it is exactly the one we can measure later.

Share: Many harnesses, few catch on

Once the harness lives as configuration in the repository, it can be shared beyond your own project. A registry makes sandbox configurations, including skills, rules, and MCP servers, discoverable for all teams. The building blocks are versioned individually and can be bundled into packages, much like you know from the JavaScript package manager npm. So the team in Leipzig doesn’t have to start from scratch. It picks up the harness from Aachen and adapts it to its project.

Variety emerges quickly, and that is intentional. You could try to define a standard harness centrally. But people far from the project rarely know what actually helps a team day to day. That is why we rely on emergence: Teams experiment freely, borrow from each other, and adapt. Usage shows which harnesses get adopted often and kept for a long time. In the same way, individual libraries become established in the open-source ecosystem without anyone mandating them.

Alongside this, a knowledge hub collects guidelines and project knowledge at different levels: from the whole company to team and project down to the individual. This knowledge is part of the harness, too. Smaller models in particular benefit, since they need more context.

Usage alone doesn’t prove quality, though. A harness can be popular because it was there first, because a well-known team uses it, or because it simply feels good. Whether it actually delivers better results is something only measurement can answer. Emergence tells us where to measure. The benchmark tells us whether what’s popular also holds up.

Interim conclusion and a look ahead to part 2

A convenient, secure sandbox and a registry for shared harnesses lay the foundation: Teams work in a protected environment, learn from each other, and it becomes visible which setups catch on. In part 2, we show how we measure these candidates on real tasks from our own Git history and improve them automatically. We also talk openly about where the approach still reaches its limits today. [LINK: Part 2 of the series, once published]

---

Interested in sovereign agentic coding?

---

Frequently Asked Questions (FAQ)