Harness Engineering: The What, Why and How

Picture two organisations using exactly the same AI model.

The first has built a handful of impressive agent demos. They work beautifully in a meeting room. In production, they occasionally invent an answer, skip a step, or tell you a task is finished when it is not. Nobody quite trusts them with anything that matters.

The second runs agents across real, regulated processes. Its advisers spend three times as much time with clients. Its engineers ship faster than ever.

Same model. Completely different outcome.

The difference has a name: harness engineering. And as AI models become more capable, more interchangeable and more widely available, it is quickly becoming the part of your AI strategy that decides whether agents create value or just create risk.

‍

‍

What is harness engineering?

Harness engineering is the practice of designing the operating structure around an AI agent: what it must deliver, which rules it must follow, which information it can use, how its work is checked and who is accountable.

The model supplies the intelligence; the harness turns that intelligence into dependable work.

‍

‍

In its simplest form, a harness is everything around the AI model.

Microsoft puts it neatly in its announcement of the Microsoft Copilot harness: "If the model supplies the intelligence, the harness is everything around the model." That means the instructions an agent receives, the context it can draw on, the environment it runs in, and the controls that keep it on track.

In a September 2026 article, Boston Consulting Group takes the idea a step further. It describes harness engineering as building "an operating system, or harness, around agents", one that establishes effective governance, accountability and proper controls. Just as your laptop's operating system decides which programs can run, what they can access and what happens when something crashes, a harness does the same for AI agents.

The word itself is a useful image. A harness does not slow a horse down. It turns raw power into controlled, useful work. Without one, you have energy. With one, you have a plough.

Harness engineering, then, is the discipline of designing that structure deliberately: deciding what an agent is meant to achieve, what it must never do, what it is allowed to know, how its work is checked, and who is accountable when something goes wrong.

‍

Why harness engineering matters in the age of AI agents

For the past few years, most organisations have focused on the model. Which one is smartest? Which one is cheapest? Which one should we standardise on?

That question is losing its importance, and there are three reasons why.

‍

Models are becoming a commodity

New frontier models now arrive every few months, and the gap between them keeps narrowing. Microsoft's harness alone gives access to more than 20 frontier models, plus the option to bring your own. As Microsoft states plainly: "If you want to compete, you need to be multi-model."

BCG draws the logical conclusion. As models commoditise, winning "won't depend on having the best model", but on a harness that captures your organisation's own processes, rules and requirements. Your competitors can buy the same model you use tomorrow. They cannot buy your harness.

‍

Agents fail in very particular ways

A chatbot that gives a weak answer is an inconvenience. An agent that acts on a weak answer is a business problem.

BCG lists the failure modes that anyone who has piloted agents will recognise: they hallucinate, introduce errors, declare unfinished work done, and can fail customer and regulatory scrutiny. These are not problems a better model solves on its own. They are problems of structure: missing specifications, missing checks and missing oversight.

It is also why so many initiatives stall. Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear business value and inadequate risk controls. BCG observes something similar: most large companies are not yet actively scaling agents, and those that are often report limited bottom-line impact.

‍

Regulators are starting to look at architecture

According to BCG, regulators are "starting to move from principle-based guidance for the use of agents to architecture-based requirements." In other words, it will no longer be enough to say you use AI responsibly. You will increasingly need to show how your systems are built to make that true.

For European organisations, this lands alongside the EU AI Act, whose transparency obligations have applied since August 2026. A well-designed harness produces an audit trail by design, rather than as an afterthought. That is a very different conversation to have with your compliance team.

‍

What harness engineering looks like in practice

The strongest argument for harness engineering is what happens when organisations get it right.

‍

A Southeast Asian bank: the gains came from the harness, not the model

BCG recently built a fully agentic advisory platform for a large Southeast Asian bank, operating in a regulated banking environment. The results were striking. Advisers tripled the time they spent actively engaging with clients, and wealth-adviser revenue productivity rose by more than 30%, with a four to five times improvement in customer conversion. Behind the scenes, engineering efficiency increased fivefold, and the journey from design to deployment was 50% faster.

‍

‍

The most telling line in BCG's write-up is not a number. It is this: "These enhancements came less from the selected model and far more from the harness around it." The evaluation and approval processes, and the behavioural guardrails built around the agents, made the difference.

‍

A software company: from AI-assisted to agentic-native

In a second example, BCG describes a software company that moved from an AI-assisted way of working to an agentic-native one, applying harness engineering across its full product lifecycle. The team's productivity increased by as much as five times.

‍

GitHub and Microsoft: one harness, many products

Microsoft offers a third case, at a very different scale. The harness that GitHub engineering built for its own coding agents has been adopted across Microsoft and now powers Copilot Code, Copilot Studio, the GitHub Copilot app, the command line and VS Code. According to Microsoft, it has been proven "at the scale of millions of users and hundreds of real-world use cases."

The lesson Microsoft draws is one every organisation can apply: "Improve the harness, and every surface it touches benefits." Invest in the structure once, and every agent you build on top of it gets better.

‍

How to build a harness: the five components

‍

‍

An effective AI harness has five components, according to BCG: specs, a constitution, a control panel, a context hub and quality gates. Each has a familiar equivalent in a computer's operating system.

Specs (the application manifest). A clear scope contract for what the agent is expected to deliver, including the criteria its work will be evaluated against. Crucially, specs should be machine testable, so you can check automatically whether the agent did what it was asked.

Constitution (the kernel). The rules the agent must always follow and must always avoid, the triggers for escalating to a human, and the named person accountable for the agent. Rules that are truly non-negotiable are written as deterministic code, not left to the model's judgement.

Control panel (the system monitor). Visibility into what agents are doing, a complete audit trail, an escalation matrix and a way to recover when something fails.

Context hub (shared memory). A curated repository of the background information and data sources an agent needs, so it does not have to guess or go searching the open internet. If this sounds familiar, it is closely related to the organisational memory we wrote about last week.

Quality gates (permissions). Checkpoints that work must pass before it moves on. BCG describes four kinds: automated gates, evaluation gates (where a separate critic agent reviews the work), human stage gates with a named reviewer, and regulatory gates for compliance.

On top of these five components sits a governance maturity ladder. New agents start under a "check everything" regime. As they prove themselves on a particular type of work, clearance rules relax towards occasional spot checks. Trust is earned, not assumed.

‍

Three principles to start with

BCG pairs the framework with some practical advice. Start small, with one contained process, and build the harness around it before expanding. Be selective: the best first candidates are processes that are already documented, and where quality can be checked objectively. And build rather than buy, because the parts of the harness that capture your processes and rules are your competitive advantage. As BCG puts it, "a customized harness can create a strong competitive moat."

That last principle raises an obvious question. If you are meant to build your own harness, where does a ready-made one from Microsoft fit in?

‍

The Microsoft Copilot harness: what it is and why it matters

The Microsoft Copilot harness is the agent harness GitHub engineering originally built for its own coding agents, and the one that now runs Microsoft's Copilot products. On 28 October 2026, Microsoft made it available to customers in Foundry Agent Service, currently in public preview. It is offered as a fully managed way to build agents that reason, use tools and complete complex, long-running tasks.

What makes it stand out is that it is truly multi-model. The harness supports more than 20 frontier models, plus bring your own key, and can route work to the right model, or combination of models, depending on the task. GitHub explains how this works in its write-up on multi-model orchestration. It is also built on open standards, including the Model Context Protocol (MCP), agent skills and agent plugins, so your agents are not locked into one way of connecting to tools and data.

Microsoft runs the agent loop and the secure sandbox the agent works in, with governance and optimisation built in from day one. You can let Foundry manage the harness entirely in the cloud, or download the Copilot SDK and build with it yourself. And because the runtime was rewritten in Rust, Microsoft says agents now carry less session overhead and start responding faster.

‍

Build or buy? Both.

‍

‍

Should you build your own harness or use a ready-made one? In most cases, both. At first glance, the Copilot harness seems to contradict BCG's advice to build rather than buy. In practice, the two fit together well.

Microsoft's division of labour is explicit: Microsoft runs the loop and the sandbox. "You bring the instructions, skills, tools, and model choice."

Map that onto BCG's five components, and a clear picture emerges. The plumbing of a harness, such as the agent loop, execution environment, model routing and baseline governance, is not where your advantage lies. Rebuilding it yourself costs time and creates risk. The parts that make a harness yours are your specs, your constitution, your context and your quality gates. Those still have to be designed, by you, around how your organisation actually works.

Put simply: buy the engine, build the rules of the road.

‍

Where to start with harness engineering

If your organisation is running agent pilots today, a few honest questions will tell you how mature your harness is.

Start with the work itself. Could you write down what each agent is meant to deliver, in a way a machine could test? If not, that is where to begin. Then look at accountability: does every agent have a named owner and clear escalation rules? That is the heart of managing AI agents at scale. Ask where each agent gets its information from, who keeps it up to date, and what has to happen before its output reaches a customer or a system of record.

Finally, ask the question that reveals the most: if you swapped the underlying model tomorrow, what would break? The answer tells you how much of your value sits in the model, and how much in the harness.

The organisations that scale agents successfully will not be the ones with access to the best model. Everyone will have that. They will be the ones that took the time to build the structure that makes agents dependable.

At Digital Bricks, we help organisations design and build that structure, from agent development and orchestration to security and governance and the adoption programmes that help people work alongside agents with confidence. If you are wondering what your own harness should look like, we are always happy to think it through with you.

‍