AI Agents
Agent = model + harness: who owns the car?
Agent = model + harness: who owns the car?
Dr. Anoj Winston Gladius
·
12
Min. Lesezeit
aufsatz
Image: AI generated with neuland.ai HUB
The harness decides what a model may do, what it knows, what it costs and who owns the result. Companies should own this layer and be able to replace the model.
On the layer that decides what AI actually does in your company — what a harness is, why it should be yours, and why "bring your own harness" is the next thing that matters.
Same engine, different car, different result. Original graphic by neuland.ai; sources in note 1.
In 2024, four Formula One teams raced with the same Mercedes engine. The rules require engine suppliers to give their customer teams the same performance as their own works team. McLaren won the constructors' championship — its first in 26 years — and won it again in 2025. The Mercedes works team, running its own engine, finished fourth that first year; Aston Martin fifth; Williams ninth. Same engine, by regulation. Everything else decided the result.¹ In 2026, the AI industry wrote down the same lesson as an equation: agent = model + harness. Germany's enterprise AI debate is almost entirely about the engine — which model, which cloud, which regulation. Almost nobody is talking about the harness. That is a mistake, because the harness decides what the model is allowed to do, what it knows, what it costs, and who owns the result.
This series has argued for a year that the value in enterprise AI sits in the layer around the model.² That layer now has a name. This piece is about it.
The model is the engine. The harness is the car. In enterprise AI, the car has to be yours.
What a harness is
The word was formalised in February 2026, when the practice it describes — building the system around a model so that it can work as an agent — finally got a name.3 LangChain wrote down the equation, agent = model + harness, and defined the harness as "every piece of code, configuration, and execution logic that isn't the model itself".³ OpenAI published its own account of "harness engineering". Anthropic describes its Agent SDK as the harness that powers Claude Code.³
In practical terms, the harness is everything that happens between a user's request and a finished result. It runs the loop in which the model plans, acts and checks its work. It decides which tools the model may call and executes them, often in an isolated sandbox. It manages what the model sees — which documents, which history, which instructions — and what it forgets. It keeps state between steps and between sessions, recovers from errors, verifies results, enforces permissions, and writes down what happened.
The model reasons. The harness does everything else. And because a model on its own is a stateless function that turns text into text, it is the harness that turns it into something that can do work. Anthropic's own engineers make the point the other way round: each component of a harness exists because of something the model cannot yet do reliably on its own.⁴
Three harnesses Germany already understands
The word sounds technical. It is not. Germany has understood harnesses for a very long time — just not this one.
The first is the oldest: the harness on a horse. A horse is enormous power with no direction. The harness turns that power into work — a plough pulled in a straight line, a cart taken where the driver wants it to go — and the reins and blinkers decide where the horse goes and what it pays attention to. Direction.
The second is the one German engineering knows best: the Kabelbaum, the wiring harness of a car. It connects every sensor, every controller and every actuator in the vehicle, it is designed for each model specifically, and nobody who does not control its design can change how the car behaves. Connection.
The third is the one every engineer has built: the test harness, the rig that runs a component under controlled conditions and records exactly what it did. Verification.
An agent harness is all three at once. It gives the model's power a direction, connects it to every system in the company, and verifies and records what it did. That is why it matters more than it sounds.
Figure 1. Three harnesses Germany already understands. Original illustration by neuland.ai.
Why the harness matters more than the model
The Formula One result is not a curiosity. It is the normal case. When researchers evaluate AI agents, what they measure is the model and the harness together; Anthropic's own evaluation guidance says as much, and public benchmarks increasingly compare harnesses running the same model.³ An earlier piece in this series warned that a comparison run on two different harnesses quietly becomes a vendor ranking.⁵ And the nine-loop physics result described earlier in this series was not won by a bigger model than anyone else had. It was won by a harness that kept a model working for days, decomposed the problem, and verified its own steps.⁵
Harness engineering, as its practitioners describe it, means treating every agent failure as a defect in the system to be fixed permanently, rather than a prompt to retry.³ That is ordinary engineering discipline. It is also exactly where a company's own knowledge of its processes turns into a durable advantage — if the harness belongs to the company.
Why Germany is only talking about the engine
The German debate about enterprise AI has three subjects. Which model — the American one, the Chinese one, or a European one. Which cloud — and whether its servers stand in Frankfurt. And which rules — the AI Act, data protection, the works council. All three matter. None of them is the harness.
There is a simple reason the harness has stayed invisible: it came bundled. The assistant built into an office suite has a harness; so does an enterprise chatbot subscription, and so does a hyperscaler's agent service. In each case the customer chose a product and got the provider's harness inside it, without ever being asked. The result is the position this series has described from several angles: German enterprises renting the engine, renting the car, and calling it an AI strategy.
What a self-owned harness means
The frontier laboratories have built excellent harnesses. Claude Code, OpenAI's Codex and Google's Gemini CLI have, between them, worked out how an agent should plan, when to split work across sub-agents, how to compress a long history so the model does not drown in it, how to keep notes outside the context window, and how to check its own work. Several of these harnesses are open source, and the laboratories publish detailed accounts of their designs.³
A self-owned harness takes those lessons — the patterns, not the code — and builds them into a harness that belongs to the company using it. Distilled from the best frontier harnesses, but not tied to any of their models: the same harness can drive an open-weight model on the company's own hardware in the morning and a frontier model through an API in the afternoon, under the same rules.
And then it has to do what the frontier harnesses were never built for. Claude Code and Codex are designed for one developer, on one machine, working on one repository. An enterprise harness serves thousands of employees at once. It has to know who each user is and what each of them may see, before any model sees anything. It has to keep each user's session isolated from everyone else's, start a sandbox only when a task actually needs one, and hold state outside the model, so that a session can be paused, moved or resumed without losing anything. It has to control cost across the whole organisation rather than one person's subscription. And it has to write a record of every retrieval, tool call and decision that an auditor can read a year later.⁶
Figure 2. From a developer's harness to an enterprise harness. Original diagram by neuland.ai.
Bring your own harness
There is a second reason the harness is about to matter. Many large companies have already built agents — with LangGraph, with the Claude Agent SDK, with OpenAI's tools, or with their own code. Those agents have loops, tools and evaluation suites. What they usually do not have is the rest of the car: permissions enforced across systems, a shared model of the business, routing between models, and an audit trail.
That is what "bring your own harness" means. A company keeps the agents it has built and runs them inside a platform that supplies identity, permissions, knowledge, routing and the record, instead of rebuilding them on a vendor's proprietary runtime. The harness becomes a replaceable part, the way the model already is. An earlier piece in this series argued that "bring your own model" had become table stakes and that the harness was the next layer; that is now where enterprise architecture is heading.⁵
Figure 3. Bring your own harness. Support for customer-supplied harnesses is a current engineering priority of the neuland.ai HUB (note 9). Original diagram by neuland.ai.
The managed-service trap
The alternative to owning the car is renting it from a hyperscaler, one managed service at a time — document extraction from one, models and agents from another. These services are good, and for many workloads they are the right choice. But it is worth being precise about what renting means.
Metering. Microsoft's Azure Document Intelligence is billed per page: as of October 2026, ten dollars per thousand pages for its prebuilt models such as invoices and layout, and thirty dollars per thousand for custom extraction.⁷ Costs scale with volume, indefinitely.
Someone else's calendar. Microsoft retired the service's v2.0 API on 31 August 2026, and custom models trained on certain preview versions of the API had to be retrained.⁷ The previous piece in this series described what that kind of calendar looks like when it reaches a company's models.
Same quality on any cloud — not quite. Azure Document Intelligence runs on Azure; the equivalent on AWS is a different product with different behaviour and different prices. Microsoft does offer containers to run on your own hardware, including fully disconnected ones on annual commitments — but only the Read and Layout models run on the current API version there, and the prebuilt invoice container is a major version behind the cloud service.⁷
Where your requests go. Amazon Bedrock offers three ways to run a model: in one region, across the regions of a geography such as the EU, or globally across any commercial region. The EU option keeps data inside the EU, which is good. But new models are often available only through cross-region routing; one video model launched on Bedrock in October 2026 can be called from Frankfurt only through the global profile.8 AWS's own documentation notes that prompts and outputs may leave the source region during cross-region inference.
Whose harness. Bedrock's agent runtime, AgentCore, provides memory, policy and evaluations as AWS services.⁸ An agent built on it keeps its memory, its rules and its tests inside AWS. That is the car, rented — and moving it to another cloud means rebuilding it.
Figure 4. Managed services compared with one platform on Kubernetes. Original graphic by neuland.ai; sources in notes 7 and 8.
One platform, one cluster, any cloud
The alternative is not to avoid the hyperscalers. It is to own the layer that runs on top of them. A platform whose harness, document pipeline, knowledge layer and model serving all run as containers on Kubernetes behaves the same way wherever that cluster runs: on premises, in a German sovereign cloud, or in any hyperscaler's region. The same container images, the same open-weight models and the same pipeline produce the same results, given the same hardware. There is no per-page meter, no third-party retirement calendar for the parts you depend on most, and no question about which region processed a request — because you chose the cluster. Frontier models remain available through the router, where the company's policy allows them.
That is the real meaning of independence in enterprise AI. Not the absence of American technology, but the absence of any single dependency you cannot replace.
The harness check
Tick each statement that is true for your organisation today. In Word, click the box to tick it.
✓ | Statement | Layer |
☐ | 1. We can name the harness behind every AI agent we run — and who owns it. | Ownership |
☐ | 2. Our agents' logic, memory and rules live in a layer we control, not in a provider's agent runtime. | Ownership |
☐ | 3. We could replace the model behind an agent without rebuilding the agent. | Portability |
☐ | 4. Our document pipeline produces the same results on premises and on every cloud we use. | Portability |
☐ | 5. For every AI request, we know which provider and which region processed it. | Portability |
☐ | 6. Permissions are enforced per user before any model sees data — for every agent. | Scale |
☐ | 7. Each user's sessions are isolated, and their state survives a restart without living in the model. | Scale |
☐ | 8. We control the cost of AI across the organisation, not subscription by subscription. | Scale |
☐ | 9. Every retrieval, tool call and decision is recorded in a trail we own. | Governance |
☐ | 10. Agents our teams have already built can run under the same rules as everything else. | Governance |
Your score:
8–10 ticks | You own the car. Choose your engines freely. |
4–7 ticks | You own parts of the car. Start with where your agents' memory and rules live. |
0–3 ticks | You are renting the car and calling it a strategy. |
Where neuland.ai stands on this
The neuland.ai HUB is built around its own harness, distilled from what the leading frontier harnesses have shown works, and designed from the start for many users at once: identity and permissions enforced before any model sees data, isolated sessions, sandboxes started only when a task needs them, state held in a durable record rather than in the model, and an append-only trail of every step. The whole platform — harness, document pipeline, knowledge layer and model serving — runs on Kubernetes, on premises, in a European sovereign cloud, in any hyperscaler region or fully air-gapped, with the same behaviour wherever it runs. Most work runs on open-weight models hosted in house, with frontier models such as Claude and GPT used where the customer's policy allows. Support for customer-supplied harnesses — connected through SDKs, MCP and harness adapters — is a current engineering priority.⁹
The question we now hear most often from IT leaders is not which model should we use? It is who should own the thing that uses it? Our answer is: you should.
Personal take
This is not an argument against Microsoft or Amazon. Their services are good, many of our customers use them, and for some workloads a managed service is exactly the right tool. It is an argument about which layer a company should own. In Formula One, the teams that win are not always the ones that build their own engine. They are the ones that build their own car.
What I am pushing back against is the habit of treating the harness as an implementation detail that comes free with a subscription. It is the layer where a company's knowledge of its own processes becomes software, where its rules are enforced, and where its results are recorded. Germany knows better than almost anyone that the harness is where the engineering lives — it builds them for cars every day. It is time it noticed that AI has one too.
We at neuland.ai would rather our customers owned the car and chose the engine, than rented both and hoped the race was run on their terms.
Formula One: 2024 FIA Formula One World Championship (McLaren-Mercedes constructors' champions; Mercedes fourth, Aston Martin fifth, Williams ninth, all using Mercedes power units); 2025 FIA Formula One World Championship (McLaren retaining the constructors' title); PlanetF1 (December 2024) on the regulatory requirement for performance parity between customer and works power units.
Series articles available at https://neuland.ai/en/resources/insights.
On the term and its definition: Vivek Trivedy (LangChain), "The Anatomy of an Agent Harness" (2026), definition as quoted in "Distributing Security Controls Through Harness Engineering", arXiv:2607.25890; https://en.wikipedia.org/wiki/Agent_harness, on the formula agent = model + harness and the February 2026 origin of the term, including Mitchell Hashimoto's post on harness engineering; Ryan Lopopolo (OpenAI), "Harness engineering" (2026); Anthropic, Claude Agent SDK documentation, describing the SDK as the agent harness that powers Claude Code; Anthropic's guidance on agent evaluations measuring model and harness together, as summarised in "Harness Engineering for Language Agents", Preprints.org (2026); Firecrawl, "What Is an Agent Harness?" (2026), on harness engineering as permanent fixes rather than retries.
Anthropic's engineering writing on harnesses for long-running work, as summarised by Addy Osmani, "Agent Harness Engineering" (April 2026).
See earlier pieces in this series on blind evaluation, on nine loops, and on the compute constraint, which introduced "bring your own harness".
Design principles for multi-user agent execution as described in earlier pieces in this series on statelessness, containment and provenance.
Azure Document Intelligence pricing as reported by SuperDupr (24 October 2026); Microsoft Azure update, "Azure AI Document Intelligence v2.0 API will be retired on 31 August 2026"; IDP Software guide (2026) on the retirement of preview API versions on 30 June 2026 and the retraining of custom models; InvoiceExtractor (October 2026) and ReviewRamble (October 2026) on container availability by API version and disconnected container commitments.
Amazon Bedrock documentation on in-Region, geographic and global cross-Region inference, and on prompts and outputs moving outside the source Region during cross-Region inference; Amazon Bedrock model card for TwelveLabs Pegasus v1.5 (launched 8 October 2026), listing Frankfurt with global cross-Region inference only; Amazon Bedrock AgentCore documentation on cross-region inference for AgentCore Memory, Policy and Evaluations.
neuland.ai HUB: own agent harness for multi-user operation with identity- and permission-aware execution, isolated sessions, on-demand sandboxing, durable state and append-only audit; platform deployed on Kubernetes on premises, in a European sovereign cloud, in a hyperscaler region or air-gapped; per-task model routing across self-hosted open-weight and proprietary models; support for customer-supplied harnesses via SDK, MCP and harness adapters is a current engineering priority. neuland.ai AG retains responsibility for content quality and clean delivery of results across all customer engagements.
On the layer that decides what AI actually does in your company — what a harness is, why it should be yours, and why "bring your own harness" is the next thing that matters.
Same engine, different car, different result. Original graphic by neuland.ai; sources in note 1.
In 2024, four Formula One teams raced with the same Mercedes engine. The rules require engine suppliers to give their customer teams the same performance as their own works team. McLaren won the constructors' championship — its first in 26 years — and won it again in 2025. The Mercedes works team, running its own engine, finished fourth that first year; Aston Martin fifth; Williams ninth. Same engine, by regulation. Everything else decided the result.¹ In 2026, the AI industry wrote down the same lesson as an equation: agent = model + harness. Germany's enterprise AI debate is almost entirely about the engine — which model, which cloud, which regulation. Almost nobody is talking about the harness. That is a mistake, because the harness decides what the model is allowed to do, what it knows, what it costs, and who owns the result.
This series has argued for a year that the value in enterprise AI sits in the layer around the model.² That layer now has a name. This piece is about it.
The model is the engine. The harness is the car. In enterprise AI, the car has to be yours.
What a harness is
The word was formalised in February 2026, when the practice it describes — building the system around a model so that it can work as an agent — finally got a name.3 LangChain wrote down the equation, agent = model + harness, and defined the harness as "every piece of code, configuration, and execution logic that isn't the model itself".³ OpenAI published its own account of "harness engineering". Anthropic describes its Agent SDK as the harness that powers Claude Code.³
In practical terms, the harness is everything that happens between a user's request and a finished result. It runs the loop in which the model plans, acts and checks its work. It decides which tools the model may call and executes them, often in an isolated sandbox. It manages what the model sees — which documents, which history, which instructions — and what it forgets. It keeps state between steps and between sessions, recovers from errors, verifies results, enforces permissions, and writes down what happened.
The model reasons. The harness does everything else. And because a model on its own is a stateless function that turns text into text, it is the harness that turns it into something that can do work. Anthropic's own engineers make the point the other way round: each component of a harness exists because of something the model cannot yet do reliably on its own.⁴
Three harnesses Germany already understands
The word sounds technical. It is not. Germany has understood harnesses for a very long time — just not this one.
The first is the oldest: the harness on a horse. A horse is enormous power with no direction. The harness turns that power into work — a plough pulled in a straight line, a cart taken where the driver wants it to go — and the reins and blinkers decide where the horse goes and what it pays attention to. Direction.
The second is the one German engineering knows best: the Kabelbaum, the wiring harness of a car. It connects every sensor, every controller and every actuator in the vehicle, it is designed for each model specifically, and nobody who does not control its design can change how the car behaves. Connection.
The third is the one every engineer has built: the test harness, the rig that runs a component under controlled conditions and records exactly what it did. Verification.
An agent harness is all three at once. It gives the model's power a direction, connects it to every system in the company, and verifies and records what it did. That is why it matters more than it sounds.
Figure 1. Three harnesses Germany already understands. Original illustration by neuland.ai.
Why the harness matters more than the model
The Formula One result is not a curiosity. It is the normal case. When researchers evaluate AI agents, what they measure is the model and the harness together; Anthropic's own evaluation guidance says as much, and public benchmarks increasingly compare harnesses running the same model.³ An earlier piece in this series warned that a comparison run on two different harnesses quietly becomes a vendor ranking.⁵ And the nine-loop physics result described earlier in this series was not won by a bigger model than anyone else had. It was won by a harness that kept a model working for days, decomposed the problem, and verified its own steps.⁵
Harness engineering, as its practitioners describe it, means treating every agent failure as a defect in the system to be fixed permanently, rather than a prompt to retry.³ That is ordinary engineering discipline. It is also exactly where a company's own knowledge of its processes turns into a durable advantage — if the harness belongs to the company.
Why Germany is only talking about the engine
The German debate about enterprise AI has three subjects. Which model — the American one, the Chinese one, or a European one. Which cloud — and whether its servers stand in Frankfurt. And which rules — the AI Act, data protection, the works council. All three matter. None of them is the harness.
There is a simple reason the harness has stayed invisible: it came bundled. The assistant built into an office suite has a harness; so does an enterprise chatbot subscription, and so does a hyperscaler's agent service. In each case the customer chose a product and got the provider's harness inside it, without ever being asked. The result is the position this series has described from several angles: German enterprises renting the engine, renting the car, and calling it an AI strategy.
What a self-owned harness means
The frontier laboratories have built excellent harnesses. Claude Code, OpenAI's Codex and Google's Gemini CLI have, between them, worked out how an agent should plan, when to split work across sub-agents, how to compress a long history so the model does not drown in it, how to keep notes outside the context window, and how to check its own work. Several of these harnesses are open source, and the laboratories publish detailed accounts of their designs.³
A self-owned harness takes those lessons — the patterns, not the code — and builds them into a harness that belongs to the company using it. Distilled from the best frontier harnesses, but not tied to any of their models: the same harness can drive an open-weight model on the company's own hardware in the morning and a frontier model through an API in the afternoon, under the same rules.
And then it has to do what the frontier harnesses were never built for. Claude Code and Codex are designed for one developer, on one machine, working on one repository. An enterprise harness serves thousands of employees at once. It has to know who each user is and what each of them may see, before any model sees anything. It has to keep each user's session isolated from everyone else's, start a sandbox only when a task actually needs one, and hold state outside the model, so that a session can be paused, moved or resumed without losing anything. It has to control cost across the whole organisation rather than one person's subscription. And it has to write a record of every retrieval, tool call and decision that an auditor can read a year later.⁶
Figure 2. From a developer's harness to an enterprise harness. Original diagram by neuland.ai.
Bring your own harness
There is a second reason the harness is about to matter. Many large companies have already built agents — with LangGraph, with the Claude Agent SDK, with OpenAI's tools, or with their own code. Those agents have loops, tools and evaluation suites. What they usually do not have is the rest of the car: permissions enforced across systems, a shared model of the business, routing between models, and an audit trail.
That is what "bring your own harness" means. A company keeps the agents it has built and runs them inside a platform that supplies identity, permissions, knowledge, routing and the record, instead of rebuilding them on a vendor's proprietary runtime. The harness becomes a replaceable part, the way the model already is. An earlier piece in this series argued that "bring your own model" had become table stakes and that the harness was the next layer; that is now where enterprise architecture is heading.⁵
Figure 3. Bring your own harness. Support for customer-supplied harnesses is a current engineering priority of the neuland.ai HUB (note 9). Original diagram by neuland.ai.
The managed-service trap
The alternative to owning the car is renting it from a hyperscaler, one managed service at a time — document extraction from one, models and agents from another. These services are good, and for many workloads they are the right choice. But it is worth being precise about what renting means.
Metering. Microsoft's Azure Document Intelligence is billed per page: as of October 2026, ten dollars per thousand pages for its prebuilt models such as invoices and layout, and thirty dollars per thousand for custom extraction.⁷ Costs scale with volume, indefinitely.
Someone else's calendar. Microsoft retired the service's v2.0 API on 31 August 2026, and custom models trained on certain preview versions of the API had to be retrained.⁷ The previous piece in this series described what that kind of calendar looks like when it reaches a company's models.
Same quality on any cloud — not quite. Azure Document Intelligence runs on Azure; the equivalent on AWS is a different product with different behaviour and different prices. Microsoft does offer containers to run on your own hardware, including fully disconnected ones on annual commitments — but only the Read and Layout models run on the current API version there, and the prebuilt invoice container is a major version behind the cloud service.⁷
Where your requests go. Amazon Bedrock offers three ways to run a model: in one region, across the regions of a geography such as the EU, or globally across any commercial region. The EU option keeps data inside the EU, which is good. But new models are often available only through cross-region routing; one video model launched on Bedrock in October 2026 can be called from Frankfurt only through the global profile.8 AWS's own documentation notes that prompts and outputs may leave the source region during cross-region inference.
Whose harness. Bedrock's agent runtime, AgentCore, provides memory, policy and evaluations as AWS services.⁸ An agent built on it keeps its memory, its rules and its tests inside AWS. That is the car, rented — and moving it to another cloud means rebuilding it.
Figure 4. Managed services compared with one platform on Kubernetes. Original graphic by neuland.ai; sources in notes 7 and 8.
One platform, one cluster, any cloud
The alternative is not to avoid the hyperscalers. It is to own the layer that runs on top of them. A platform whose harness, document pipeline, knowledge layer and model serving all run as containers on Kubernetes behaves the same way wherever that cluster runs: on premises, in a German sovereign cloud, or in any hyperscaler's region. The same container images, the same open-weight models and the same pipeline produce the same results, given the same hardware. There is no per-page meter, no third-party retirement calendar for the parts you depend on most, and no question about which region processed a request — because you chose the cluster. Frontier models remain available through the router, where the company's policy allows them.
That is the real meaning of independence in enterprise AI. Not the absence of American technology, but the absence of any single dependency you cannot replace.
The harness check
Tick each statement that is true for your organisation today. In Word, click the box to tick it.
✓ | Statement | Layer |
☐ | 1. We can name the harness behind every AI agent we run — and who owns it. | Ownership |
☐ | 2. Our agents' logic, memory and rules live in a layer we control, not in a provider's agent runtime. | Ownership |
☐ | 3. We could replace the model behind an agent without rebuilding the agent. | Portability |
☐ | 4. Our document pipeline produces the same results on premises and on every cloud we use. | Portability |
☐ | 5. For every AI request, we know which provider and which region processed it. | Portability |
☐ | 6. Permissions are enforced per user before any model sees data — for every agent. | Scale |
☐ | 7. Each user's sessions are isolated, and their state survives a restart without living in the model. | Scale |
☐ | 8. We control the cost of AI across the organisation, not subscription by subscription. | Scale |
☐ | 9. Every retrieval, tool call and decision is recorded in a trail we own. | Governance |
☐ | 10. Agents our teams have already built can run under the same rules as everything else. | Governance |
Your score:
8–10 ticks | You own the car. Choose your engines freely. |
4–7 ticks | You own parts of the car. Start with where your agents' memory and rules live. |
0–3 ticks | You are renting the car and calling it a strategy. |
Where neuland.ai stands on this
The neuland.ai HUB is built around its own harness, distilled from what the leading frontier harnesses have shown works, and designed from the start for many users at once: identity and permissions enforced before any model sees data, isolated sessions, sandboxes started only when a task needs them, state held in a durable record rather than in the model, and an append-only trail of every step. The whole platform — harness, document pipeline, knowledge layer and model serving — runs on Kubernetes, on premises, in a European sovereign cloud, in any hyperscaler region or fully air-gapped, with the same behaviour wherever it runs. Most work runs on open-weight models hosted in house, with frontier models such as Claude and GPT used where the customer's policy allows. Support for customer-supplied harnesses — connected through SDKs, MCP and harness adapters — is a current engineering priority.⁹
The question we now hear most often from IT leaders is not which model should we use? It is who should own the thing that uses it? Our answer is: you should.
Personal take
This is not an argument against Microsoft or Amazon. Their services are good, many of our customers use them, and for some workloads a managed service is exactly the right tool. It is an argument about which layer a company should own. In Formula One, the teams that win are not always the ones that build their own engine. They are the ones that build their own car.
What I am pushing back against is the habit of treating the harness as an implementation detail that comes free with a subscription. It is the layer where a company's knowledge of its own processes becomes software, where its rules are enforced, and where its results are recorded. Germany knows better than almost anyone that the harness is where the engineering lives — it builds them for cars every day. It is time it noticed that AI has one too.
We at neuland.ai would rather our customers owned the car and chose the engine, than rented both and hoped the race was run on their terms.
Formula One: 2024 FIA Formula One World Championship (McLaren-Mercedes constructors' champions; Mercedes fourth, Aston Martin fifth, Williams ninth, all using Mercedes power units); 2025 FIA Formula One World Championship (McLaren retaining the constructors' title); PlanetF1 (December 2024) on the regulatory requirement for performance parity between customer and works power units.
Series articles available at https://neuland.ai/en/resources/insights.
On the term and its definition: Vivek Trivedy (LangChain), "The Anatomy of an Agent Harness" (2026), definition as quoted in "Distributing Security Controls Through Harness Engineering", arXiv:2607.25890; https://en.wikipedia.org/wiki/Agent_harness, on the formula agent = model + harness and the February 2026 origin of the term, including Mitchell Hashimoto's post on harness engineering; Ryan Lopopolo (OpenAI), "Harness engineering" (2026); Anthropic, Claude Agent SDK documentation, describing the SDK as the agent harness that powers Claude Code; Anthropic's guidance on agent evaluations measuring model and harness together, as summarised in "Harness Engineering for Language Agents", Preprints.org (2026); Firecrawl, "What Is an Agent Harness?" (2026), on harness engineering as permanent fixes rather than retries.
Anthropic's engineering writing on harnesses for long-running work, as summarised by Addy Osmani, "Agent Harness Engineering" (April 2026).
See earlier pieces in this series on blind evaluation, on nine loops, and on the compute constraint, which introduced "bring your own harness".
Design principles for multi-user agent execution as described in earlier pieces in this series on statelessness, containment and provenance.
Azure Document Intelligence pricing as reported by SuperDupr (24 October 2026); Microsoft Azure update, "Azure AI Document Intelligence v2.0 API will be retired on 31 August 2026"; IDP Software guide (2026) on the retirement of preview API versions on 30 June 2026 and the retraining of custom models; InvoiceExtractor (October 2026) and ReviewRamble (October 2026) on container availability by API version and disconnected container commitments.
Amazon Bedrock documentation on in-Region, geographic and global cross-Region inference, and on prompts and outputs moving outside the source Region during cross-Region inference; Amazon Bedrock model card for TwelveLabs Pegasus v1.5 (launched 8 October 2026), listing Frankfurt with global cross-Region inference only; Amazon Bedrock AgentCore documentation on cross-region inference for AgentCore Memory, Policy and Evaluations.
neuland.ai HUB: own agent harness for multi-user operation with identity- and permission-aware execution, isolated sessions, on-demand sandboxing, durable state and append-only audit; platform deployed on Kubernetes on premises, in a European sovereign cloud, in a hyperscaler region or air-gapped; per-task model routing across self-hosted open-weight and proprietary models; support for customer-supplied harnesses via SDK, MCP and harness adapters is a current engineering priority. neuland.ai AG retains responsibility for content quality and clean delivery of results across all customer engagements.