NAiOS IconNAiOS Logo
Back to blogDigital Transformation

Harness, the buzzword of the moment that has been around for years

A harness is everything around the model that lets it act: the loop, the tools, the context, the permissions and the traces. The name comes from a car's wiring harness and from the classic software test harness; what was born in 2026 is the discipline. Why it decides the outcome more than the model does, and how NAiOS manages it.

N
NAiOS.net Team
27 de septiembre de 202613 min read
Compartir:
Un motor aislado junto al mismo motor montado dentro del chasis transparente de un coche, con transmisión, frenos, mazo de cables y cuadro de mandos visibles
In this article
  1. What is a harness, in one sentence
  2. Where the name comes from
  3. Two meanings that should not be mixed
  4. Why the harness decides the outcome
  5. Anatomy of a harness
  6. Why this justifies asking for permission
  7. How NAiOS manages the harness
  8. Four real use cases
  9. How to know if your platform has a good harness
  10. In summary
  11. Sources

During 2026, the word harnessHarnessThe infrastructure around the model that turns it into an agent: loop, tools, context, permissions and traces has crept into all conversations about AI agentsAI AgentsSystems that execute multi-step tasks without constant supervision. People talk about the "Claude Code harness," "switching harnesses," or that "the harness matters more than the model." A discipline with its own name has even emerged, harness engineering, whose parentage is contested between an article by Mitchell Hashimoto from February 2026 and another from LangChain in March. It sounds like a newly invented term, but it is not: automotive electricians have been assembling harnesses for a century, and programmers have been writing them for decades. The only new thing is what we are applying it to.

What is a harness, in one sentence

The clearest definition is the one used by Anthropic in its agent evaluation guide: "an agent harness (or scaffoldScaffoldThe code structure that connects and orchestrates an AI agent) is the system that allows a model to act as an agent: it processes inputs, orchestrates calls to tools, and returns results". In short: it is everything that surrounds the model so it can work. The loop that decides when to call it back, the tools it can use, the context it receives at each step, the permissions that limit it, and the traces that record what it did.

LangChain summarizes it with an equation that has become popular this year: agent = model + harness. A raw model is not an agent; it becomes one when a harness gives it state, tool execution, feedback loops, and enforceable limits.

The image that best explains it: the model is the engine and the harness is the rest of the car. Chassis, transmission, brakes, steering, dashboard. An excellent engine on a table takes you nowhere, and the same engine performs very differently depending on the vehicle it is mounted in.

An isolated engine next to the same engine mounted inside the transparent chassis of a car, with transmission, brakes, wiring harness, and dashboard visible
The model is the engine; the harness is the whole car. What you notice when driving is almost never just the engine.

Where the name comes from

Harness means harness: the straps that hold a draft animal, or the equipment that prevents someone from falling while working at height. Engineering had already adopted the word twice before it reached artificial intelligence.

The cable harness

In automotive and aviation, a wiring harness is the bundle of wires that runs through the vehicle and connects the engine to the dashboard, lights, sensors, and control unit: cables grouped and tied with a sturdy sheath, finished with connectors. It became popular in the automotive industry in the 1920s, when it became clear that loose wires could not withstand vibration, abrasion, and moisture. A modern airplane contains bundles that, if stretched out, would measure kilometers.

The interesting part for our analogy is that the harness does nothing by itself: it connects, organizes, and protects what already exists. Without it, no part communicates with the others.

Braided automotive wiring harness, with connectors and ties, on a dark workbench
The wiring harness of a vehicle: it does nothing by itself, but without it, no part communicates with the others.

The test harness

In software, a test harness is the set of stubs and drivers that surrounds a piece of program to execute it in a controlled manner: it injects inputs, collects outputs, compares them with the expected results, and leaves a report. It is imitation infrastructure that allows for automated testing, and it has been common vocabulary in software engineering for decades.

It is exactly the same idea that is now applied to agents: an external structure that holds the piece, feeds it, and observes what it does. When language models began to use tools and chain steps, a name was needed for the code that wraps them. The term was waiting in the closet.

Two meanings that should not be mixed

  • Execution harness (agent harness): the environment that makes the agent function in production. It is the dominant meaning and the one used when someone says "the harness of Claude Code." Microsoft has even turned it into official product nomenclature: in its documentation from September 2026, it defines the harness as "the execution framework that turns a language modelLLM (Large Language Model)Large language model, the foundation of today's chatbots into an agent capable of working."
  • Evaluation harness (evaluation harness): the framework that runs a battery of tests against a model to measure it reproducibly. It is the direct heir of the classic test harness.

They are close relatives: in both cases, there is an external structure that holds the model and observes its behavior. And in both cases, whoever builds the harness conditions the outcome.

Why the harness decides the outcome

This is the part that interests a company, and by 2026 it has ceased to be an opinion and has become a fact.

Same model, different harness, different result. In February 2026, LangChain published a clean experiment: they froze the model (GPT-5.2-Codex) and only worked on the harness. Its score on Terminal-Bench 2.0 went from 52.8% to 66.5%, nearly fourteen points, jumping from outside the top 30 to the top 5 of the ranking. Their own summary: “we only changed the harness”. What they touched were self-verification loops, context injection from the environment, infinite loop detection, and automatic trace analysis. None of that is the model.

The rankings measure pairs, not models. A study from September 2026 audited 254 submissions to the leaderboard of SWE-bench and found the most eloquent data of the year: for the same model, changing the scaffold shifts the result by up to 29.8 percentage points, while the entire top 30 fits within 8.8 points. In other words: the difference between harnesses is more than three times greater than the distance between the thirty best systems in the world. Its authors request that the model-harness pair always be declared.

A position paper from May 2026 states it bluntly: the execution harness “is often a stronger determinant of agent performance than the model it wraps”, and as long as the harness used is not published, leaderboard comparisons should be treated as incomplete and potentially misleading. Anthropic itself puts it more simply: “when we evaluate ‘an agent’, we are evaluating the harness and the model working together”.

And it costs money. In an Anthropic experiment from March 2026 on long-duration application development, the same task launched without a harness was solved in 20 minutes and 9 dollars, while with the complete harness it took almost six hours and cost about 200 dollars. The difference is not the price: the first was a draft and the second, a finished application. The harness is what turns a demo into work.

The practical consequence is uncomfortable for the marketing of the sector: when comparing two AI products, a good part of the difference is not in the model, which is often literally the same. The model is purchased; the harness is built.

Anatomy of a harness

Three-dimensional diagram of an agent loop: four panels in a circle (planning, tools, observing, and human approval) connected by arrows around a sphere representing the model
The loop: plan, use tools, observe the result, and ask for permission when it's time. The model is at the center, but it is not the circuit.

A harness worthy of the name solves six things:

  • The loop. Call the model, execute what it asks, return the result, and repeat until finished or until the limit is reached. Easy to describe, hard to do well: this is where costs and bottlenecks are decided.
  • The tools. What the agent can really do: read emails, consult the ERP, create an event, open an incident. How they are described and named changes performance as much as changing the model.
  • The context. What enters the context window at each step and what is summarized, discarded, or kept out. It is the bottleneck of all long tasks.
  • The permissions. What can be done without asking and what requires human confirmation. It is the difference between a helpful assistant and an incident.
  • The memory and state. What survives between steps and executions, and whether an interrupted task resumes where it left off. Anthropic identifies right here the central problem of long-duration agents: they work in separate sessions, and each new session starts without memory of the previous one.
  • The observability. Traces, logs, and step-by-step reproduction. Without this, an agent cannot be debugged: it is guessed.

There is a seventh detail that is not intuitive and deserves mention: agents are poor judges of their own work. When asked to evaluate what they have just produced, they tend to praise it even if the quality is mediocre. That’s why good harnesses separate the working agent from the judging agent.

If you want the short version linked to the rest of the vocabulary, you have it in the Harness entry of the NAiOS Wiki, alongside Scaffold, Loop engineering, and Guardrails.

Why this justifies asking for permission

There is a hard reason behind the serious harnesses' mania for asking for confirmation. The benchmark τ-bench, which measures agents conversing with customers and applying business rules, found that leading agents resolved less than 50% of tasks, and that when repeating the same task eight times, they succeeded all eight times in less than 25% of cases. The conclusion is not that agents are ineffective: it is that consistency cannot be taken for granted, and therefore actions with consequences should not be executed without someone watching.

How NAiOS manages the harness

At NAiOS, we do not use a model: we use the best available at any moment and change it when a better one appears. What does not change is the harness. These are the modules that form it.

NAiOS Agents: the loop

NAiOS Agents is the layer that converts reactive chat into agents that work alone. It runs a durable loop plan→act→observe with a background worker, so that a long task survives a restart and resumes where it left off: exactly the memory problem between sessions we were talking about. It includes manual or scheduled execution (by cron or by event), memory and knowledge base per agent, delegation to other agents, isolated workspace, and a reproducible timeline to see, step by step, what it thought and what it did. The latter is observability: when something goes wrong, it is looked at, not guessed.

Connectors and MCP: the tools

An agent without tools is just a chat with pretensions. NAiOS Connectors connects via OAuth to over a thousand services —Gmail, Slack, GitHub, Calendar, Notion, and the like— and exposes them as deny-by-default tools: only the ones from the connectors you have enabled reach the model, isolated by user. NAiOS MCP does the same with any MCP server you register, classifying each tool as read or sensitive.

Knowledge Base: the context

The RAG Knowledge Base feeds the context windowContext WindowAmount of text a model can remember in a conversation with what your company knows: documents, spreadsheets, catalogs, audio and video, with semantic search and SQL queries generated by AI. An agent that cannot consult your knowledge improvises; one that can, responds with your data.

HITL: the permissions

The rule is fixed across the platform: reading is free, acting requires permission. Actions with effects —sending an email, posting, writing on an external service, issuing an invoice— are halted at a confirmation card that shows what will be done and with which account. High-risk tools maintain that confirmation even in self-approved agents. The origin of this way of working is explained in The Origin of HITL.

Four real use cases

  • The morning wrap-up. An agent scheduled for 7:00 reviews the night’s emails with NAiOS Mail, classifies what’s urgent, cross-references each sender with the CRM, and leaves you a summary with prepared response drafts. None are sent without your click.
  • Customer support that knows when to step back. In NAiOSOmni, an agent responds via WhatsApp or Telegram with the knowledge from your KB and automatically pauses as soon as a team member joins the conversation. The harness decides when the agent goes silent.
  • Meetings that leave tasks, not notes. Meeting Agent joins the video call, transcribes with diarization, and produces a summary and action items; the agent converts them into assigned tasks. All the boring work after the meeting, done.
  • Continuous business monitoring. A recurring agent checks treasury, stock, or active campaigns every night and only alerts when something is out of the ordinary. It monitors, does not act: the decision remains yours.

How to know if your platform has a good harness

Four questions for any demo, uncomfortable to answer if the harness is weak:

  • If the task is interrupted halfway, does it resume on its own or do I have to start over?
  • Can I see, step by step, what the agent did last week and with what data?
  • What actions can it perform without asking me, and who decides that list?
  • If a better model comes out tomorrow, can I switch it without redoing my automations?

When you change models and everything keeps working, it means you had a harness. When you change models and half the system breaks, it means you had a lucky prompt.

In summary

  • The harness is the environment surrounding the model: loop, tools, context, permissions, memory, and traces. Agent = model + harness.
  • The name comes from the harness: the bundle of cables in a vehicle and the test harness of classic software. What was born in 2026 is the discipline, not the word.
  • The data from this year is compelling: same model and different harness change the outcome more than choosing another model.
  • The model is bought and changed; the harness is built, and that is the real difference between products.
  • In NAiOS, that harness has a name and modules: Agents for the loop, Connectors and MCPModel Context Protocol (MCP)Standard protocol for models to connect with external tools for the tools, Knowledge Base for the context, and HITL for the permissions.

Sources

Hashtags to share:

#NAiOS #IA #DigitalTransformation #CRM #Marketing #Automation #ArtificialIntelligence #AIAgents #ClaudeCode #Anthropic #Connectors

Compartir:

Related articles

Documentos formales en blanco con un sello en relieve y un código cuadrado junto a un portátil cerrado, con una marca de verificación luminosa encima
Practical Guides

Your staff already uses AI. Can you prove you trained them?

Article 4 of the EU AI Act has applied since February 2025 to whoever USES artificial intelligence, not only to whoever builds it. The Digital Omnibus of July 2026 turned it into an obligation of effort: you do not have to guarantee that your people know, you have to prove that you acted. What counts as evidence, what does not, and the course we built for it.

27 de septiembre de 2026
Read more

Did you enjoy this article?

Discover more content on our blog.

View all posts