What exactly is a 'harness'? Hugging Face clarifies AI agent terminology that everyone uses differently

When talking about AI agents, unfamiliar terms keep popping up one after another.

"Harness," "scaffold," "context engineering"—I've heard them all, but if you asked me to explain them accurately... it's a bit difficult, isn't it?

And to make matters worse, the same term means different things to different people. This is truly troublesome.

😅 Everyone was confused at ICLR 2026 too

At the end of May 2026, the AI community "Hugging Face" published a blog post. The title is "Harness, Scaffold, and the AI Agent Terms Worth Getting Right."

The reason this glossary was created is so honest it's funny.

A Hugging Face member (@ariG23498) who attended the major AI conference ICLR 2026 posted this after the conference.

Even participants at the world's top conference didn't have consistent definitions.

That means it might not have been our fault that we were "pretending to understand" 😂

🔍 First, what kind of entity is an "AI agent"?

Before we start organizing the terms, I want to grasp the overall image of an agent.

Ordinary chat AIs (Claude, ChatGPT, etc.) answer when asked and that's it. It concludes with a single "question -> answer" cycle.

Agents are different. They autonomously repeat a loop of using external tools, checking results, deciding on the next action, and moving again. A typical example is how Claude Code writes code, runs tests, and fixes errors.

So, if we break down the elements that make up this agent, Hugging Face's organization looks like this.

🧩 Breaking down the terms

Model

This is simple. It refers to the LLM itself, like Claude, GPT, or Qwen, which receives text and returns text.

A model on its own has "no memory and no loop." It can indicate an intention to use a tool, but it doesn't have a mechanism to actually execute it. It stops after answering once.

Scaffolding

Think of a scaffold as "scaffolding in construction."

The "behavior definition layer" that surrounds the model—system prompts, tool descriptions, how to interpret model output, and how to manage memory across multiple steps—is the collection of settings that makes up a scaffold.

In short, it could be said to be the part that determines "how to show the world to the model."

Harness

This is the term that has caused the most confusion.

In a narrow sense, a harness is the "execution layer." It is the part that calls the model, processes tool execution, and decides when to stop. You could also call it the "engine that actually runs the agent."

On the other hand, in a broad sense, a harness can refer to "everything except the model." The official Claude Code documentation states: "Claude Code acts as an agent harness around Claude." In this usage, the scaffold is also included in the harness.

Rather than which is correct, it is currently used differently depending on the context. Hugging Face acknowledges this discrepancy and says, "Be aware of which meaning you are using."

By the way, I also see the term "harness engineering" quite often lately. It is a new field of practice that refers to the entire design of the execution layer to make agents run well—including error handling, stop conditions, and guardrail design.

Agent

There is an equation often used in the community.

Agent = Model + Harness

More accurately, it is "model + scaffold + harness," which together become "an entity that can act within a loop."

What is interesting is that even with the same model, if the harness is different, it looks like a completely different agent. Even if Claude Code and something else use the same model, the user experience will be completely different depending on the harness design. The model, harness, and product are different things.

🔧 Related terms I'd like to organize while I'm at it

Context Engineering

It is often confused with prompt engineering, but the scope it refers to is different.

• Prompt Engineering → How to write instructions for a single inference

• Context Engineering → What information to put into that inference window and how

As the agent moves, "how to include the results of previous steps in the context" changes. This entire dynamic management is the scope of context engineering.

Skills and Sub-agents

• Tool → A single action ("execute this command")

• Skill → A reusable knowledge package for handling multi-step tasks ("investigate a bug, form a hypothesis, and fix it")

• Sub-agent → An independent agent called by another agent. It can use tools itself and even call further sub-agents

A higher-level controller that bundles multiple agents is called an orchestrator. While a harness is for "running a single agent," an orchestrator has the image of "coordinating multiple agents."

💡 Miccell's perspective: "Standardizing definitions" itself is the next frontier

What caught my attention in this glossary might be the background of "why this became necessary" rather than the content itself.

In the field of AI agents, technological progress is so fast that a common understanding of terminology hasn't kept up. At a cutting-edge conference like ICLR 2026, stakeholders were referring to different things with the same words—I think that's not a joke, but a phenomenon unique to frontier domains.

Imagine the era when electricity first started to spread, and the definitions of "voltage," "current," and "resistance" varied from person to person. A common language is born when technology matures to a certain extent and multiple people start working together to build something.

I think current AI agents are just entering that stage.

The fact that Hugging Face released this glossary is a sign that the community has reached a stage where "we can't move forward without standardizing our language." Those who can accurately describe the mechanisms can accurately design the next steps. We might be approaching such a time.

📝 Summary: Everyone is just as confused

To briefly review what was organized in this article,

• Model → The LLM itself. It cannot function on its own

• Scaffold → A configuration layer that defines "how the world is shown" to the model

• Harness → Execution engine. In a narrow sense, an execution loop; in a broad sense, everything other than the model

• Agent → A combination of model + harness (+ scaffold)

• Context Engineering → Design and management of the contents of the context window

You aren't the only one who found the meaning of "harness" ambiguous. Researchers around the world were in the same situation.

That said, now that the definitions have been organized like this, it should be much easier to discuss and design agents. Wouldn't it be interesting if, when we talk about Claude Code or Codex next time, we could have a conversation like, "It's not the model, it's the difference in harness design"?

Which definition of the word "harness" felt most intuitive to you? Please let me know in the comments.

✏️ Production Notes

The inspiration for this article came when I was reading several articles on harness engineering and realized, "Wait, the definition of a harness is different depending on the site."

When I looked into it, I found that Hugging Face had just released a glossary to resolve that confusion. The sense of relief I felt when I realized "I wasn't the only one who was confused" was huge 😂

Once you start thinking about models and harnesses separately, you can distinguish whether "this agent not working well is a model issue or a harness design issue." I believe this is a very important perspective for practical use.

Miccell - Once you understand how things work, the world becomes more interesting.