People talk about AI as if the model did everything on its own: Claude writes the code, GPT answers the customer request, Gemini analyzes the contract. In reality, the model is only one part of the system. The actual work only becomes possible through the software around the model – the AI harness, often also called the agent harness.
Without a harness, even the best model is a brain in a jar: it can think brilliantly, but it cannot touch anything – no file, no system, no process. This article explains what an AI harness is, which building blocks it consists of, why it measurably co-determines the quality of an AI agent – and why we see CompanyGPT as our harness and AI stack for companies.
What is an AI harness?
An AI harness is the software around a language model that makes it able to work: it drives the loop in which the model gathers context, acts and verifies results, provides tools and an execution environment, manages context and state, and enforces permissions.
The word “harness” describes it well: it gives the model’s power a direction and connects it to the environment in which it is supposed to have an effect. The term is not marketing language; it has arrived in practice. Anthropic’s own documentation describes Claude Code as the agentic harness around Claude that provides tools, context management and the execution environment, and the Claude Agent SDK as the harness that powers Claude Code. In the benchmark world, the older synonym scaffold or scaffolding is also common.
The Claude Code example: model and harness, looked at separately
Claude is the model. Claude Code is the harness around it. The difference becomes visible in a typical task: “Find the bug in this repository, fix it, run the tests and make sure nothing else breaks.”
The model can reason about this task. But on its own it cannot open a file, search the repository, run a terminal command, start a test suite or change code on disk. The harness provides those abilities:
- The model decides: “I need to inspect these files first” and generates a structured tool request.
- The harness checks whether the action is allowed, reads the files and puts the result back into the model’s context.
- The model thinks again: “The bug is probably in this function” and asks the harness to edit the file and run the tests.
- The harness executes the command in its execution environment; the test output lands back in the context.
- The model sees that one test failed, reasons about why, edits the code again and runs the tests once more – until the result is verified.
This loop is the core: gather context, act, verify, repeat. The pattern of interleaving reasoning steps with actions and observations goes back to the research paper ReAct. The model provides the reasoning. The harness provides the ability to interact with a real environment. We described what an AI agent fundamentally is in AI agents: what are they, actually? – the harness is the technical answer to the question of how that definition becomes a working system.
The seven building blocks of a harness
Tools are only one part. Across the common descriptions, seven building blocks recur that together determine how well an agent works.
1. The agent loop
The harness calls the model, evaluates its tool requests, executes them, returns the results and decides when to stop: task done, step limit reached, question to the human required. Without this control there is no agent, only a single answer.
2. Tools and execution environment
Reading files, querying systems, running commands, generating documents: every capability of the agent is a tool that the harness offers and executes in a controlled environment – often a sandbox. With the Model Context Protocol (MCP) there is an open standard for this, which has been developed under the umbrella of the Linux Foundation’s Agentic AI Foundation since December 2025.
3. Context management
Prompt, conversation history, opened files, tool results, instructions – all of this has to fit into the model’s limited context window. Anthropic calls the discipline behind it context engineering and describes concrete techniques: clearing old tool outputs, compacting histories, keeping structured notes, loading information only when it is needed. The work is shared between three roles: developers curate instructions and tools, the harness compacts and cleans up, and the model writes notes and requests content deliberately.
4. State and memory
A task that lasts longer than one context window needs memory outside the model: session logs, progress files, checkpoints, stored preferences. Anthropic’s article on harnesses for long-running agents shows that exactly this state handling determines whether an agent continues sensibly after an interruption.
5. Permissions
An agent may be allowed to read files freely but need approval before running a risky command. It may edit code but not deploy to production without confirmation. The harness enforces these rules, not the model – as the Claude Code documentation also states. Further layers sit behind it: the sandbox of the execution environment and the rights of the connected target systems.
6. Verification and feedback
A good harness lets the model check its work: running tests, comparing results against requirements, using a second agent as a reviewer, obtaining human approvals. Only this feedback turns “did something” into “did it right”.
7. Orchestration
Complex tasks consist of parts. One agent investigates the backend, a second the frontend, a third reviews the tests. For this, the harness provides sub-agents with their own context window, their own tools and their own permissions; what comes back is a condensed summary, so the main context stays clean.
System instructions, error handling with retries, and logging and tracing are often counted as well.
Same model, different harness, different result
That the harness is more than an accessory can be measured. When publishing its own SWE-bench results, Anthropic already pointed out that performance can vary significantly with the scaffolding – even with an identical model. The study “Stop Comparing LLM Agents Without Disclosing the Harness” (Zhang et al., 2026) compiles figures on this:
- On Terminal-Bench 2, an unchanged model rises from 69.7 to 77.0 percent through improvements to the harness alone.
- On SWE-bench Verified Mini, the same model scores 68 or 34 percent depending on the harness.
- On SWE-bench Pro, the six leading models are only 4.9 percentage points apart under a uniform harness – while changing the harness for a fixed model moves the result by 9.5 points.
The authors’ conclusion: anyone who compares agents without naming the harness is not comparing the models. For companies this means the choice of harness is at least as consequential as the choice of model.
A harness is not a permanent state, either. It contains assumptions about the strengths and weaknesses of models, and those assumptions go stale as models improve. A harness therefore needs maintenance – another argument for treating it as a product rather than a one-off project.
Harness, framework, scaffold, eval harness: a clarification
The terms are often used interchangeably. LangChain offers a useful classification in “Agent Frameworks, Runtimes, and Harnesses”:
| Term | Meaning |
|---|---|
| Harness | Ready-made, opinionated software shell around the model – usable immediately, with tools, context logic and loop |
| Framework / SDK | Abstractions for building agents and harnesses yourself |
| Runtime | Durable, stateful execution of long-running agents |
| Scaffold / scaffolding | Older synonym for harness, mainly used with benchmarks |
| Orchestrator | A role inside a harness that distributes subtasks – not the harness itself |
| Evaluation harness | Something else: a test framework that checks models against benchmarks, such as the lm-evaluation-harness |
The boundaries are blurry, as the authors themselves admit. In practice one question is enough: am I getting a system that works – or building blocks from which I have to build one?
From a developer harness to a company harness
Claude Code is a harness for a very specific environment: a repository, a terminal, a developer. The same applies to Codex, Pi, GitHub Copilot and other coding agents, each of which we describe along the seven building blocks in our overview of AI harnesses. A company is a different environment – and places additional demands on the harness:
- The tools are business systems. Not Git and a test suite, but ERP, CRM, DMS, SharePoint, email and line-of-business applications.
- The context is company knowledge. Not the contents of a repository, but policies, contracts, manuals and project files – spread across many sources.
- Permissions follow roles. Not one user with one terminal, but hundreds of employees with different rights that must come from the existing directory service.
- Governance is mandatory. Who used which model with which data, and when? GDPR and the EU AI Act demand answers that a harness with audit logs can give.
- The model must remain interchangeable. Model generations change every quarter. A company cannot rebuild its integrations, knowledge and permissions with every change.
The last point is strategically the most important: models are interchangeable, the harness stays. Whoever invests in integrations, knowledge preparation and permission concepts today is investing in the harness – and can choose the most suitable model underneath. Our article Claude or ChatGPT for business shows what that choice can look like per department.
CompanyGPT is our harness – and the core of your AI stack
This is exactly the role CompanyGPT plays. It is not another model and not a single chatbot, but the harness that makes language models able to work in your company. The seven building blocks map directly:
| Harness building block | In Claude Code | In CompanyGPT |
|---|---|---|
| Agent loop | Loop in the terminal | Agent runtime in the chat interface, the Office add-in and workflows |
| Tools and execution | File system, terminal, Git, tests | MCP servers, integrations with business systems, n8n workflows, web search, document generation with companyFILES |
| Context | Repository, history, tool results | companyRAG for SharePoint, file shares and DMS, file search, agents with their own knowledge |
| State and memory | Session log, progress files | Memory feature, stored conversations, agent configurations |
| Permissions | Approvals for risky commands | Roles from Entra ID or Keycloak, access rights at agent and source level, model release per role via the AI Gateway |
| Verification and traceability | Tests, session history | Answers with source references, approval steps in workflows, audit logs, cost dashboard with budgets |
| Orchestration | Sub-agents | Agent marketplace, specialized agents, multi-step workflows via n8n |
| Model layer | Claude | Multi-model: GPT, Claude, Gemini, Mistral and open-weight models |
This also makes CompanyGPT more than a harness. The harness is the runtime layer around the model. The AI stack is the entire architecture in which that layer operates: model access, company knowledge, identities, governance, cost control and infrastructure. CompanyGPT delivers both – the harness for your business users and the core of an AI stack that belongs to you. It runs in your own Azure environment or, for public administration and regulated industries, sovereignly on STACKIT. And because a harness needs maintenance, we develop it continuously while you choose the models underneath freely.
Why this stack idea holds up in the long run is described in detail in our guide ChatGPT for business: Enterprise, Copilot or your own AI platform and in the whitepaper From chatbot to colleague.
The loop in everyday business
What does “gather context, act, verify” look like outside a code repository? An example from sales:
An employee asks her agent: “Prepare the quote for the customer – based on the last conversation and our current price list.” The model decides that it first needs the meeting note. The harness queries the CRM through an integration and puts the result into the context. The model notices that the price list is missing; the harness searches the released sales documents via companyRAG – and only those, because the employee’s role allows nothing else. The model drafts the quote; the harness uses companyFILES to turn it into a document in the corporate layout. Before anything goes to the customer, the workflow provides for approval by the employee.
Every step is logged, the model would be interchangeable, and the data has stayed inside the controlled environment. The model did the thinking. The harness did everything else.
Seven questions to ask your harness
Anyone introducing AI agents in a company should start the selection not with the model, but with the harness:
- Loop: Does the system work through tasks autonomously in several steps – with clear rules for stopping and asking back?
- Tools: Can our business systems be connected via open standards such as MCP?
- Context: How does our company knowledge get into the context, and who decides which sources an agent may see?
- Memory: What does the system remember across sessions, and who can inspect and delete it?
- Permissions: Do roles and rights come from our directory service, and are risky actions approved rather than silently executed?
- Verification: Are there source references, approval steps, audit logs and budgets that stand up to GDPR and EU AI Act requirements?
- Model freedom: Can we switch the model without rebuilding integrations, knowledge and permissions?
A more detailed list of criteria can be found in our enterprise AI platform selection criteria 2026; what to watch for in terms of security when connecting tools is covered in MCP as a standard – yes, but securely, please.
Conclusion
AI agents are not just models. The model may be brilliant – without a good harness it remains a brain in a jar. Only loop, tools, context, memory, permissions, verification and orchestration turn it into an agent, and the measurements show that this shell shapes the result as much as the model itself. For developers, Claude Code is such a harness. For your company, it is CompanyGPT: the layer that connects any model with your systems, your knowledge and your rules – and that stays when the next model arrives.
If you would like to see how this harness works together with your business systems and your permission model, get in touch – we will show it to you in a demo using one of your own use cases.