If you’ve been following the evolution of artificial intelligence agents, you’ve probably come across words like harness, scaffold, policy, or rollout. The problem is that they don’t always mean the same thing, depending on the tool or team using them. Hugging Face published a technical glossary to organize these ideas and explain how they connect within an agent-based system.
The need for clarification emerged after ICLR 2026, when several professionals acknowledged that they heard people talk about harness and scaffold without finding a common definition. Why does this difference matter so much? Because two products can use the same model and offer completely different experiences depending on how they surround it and make it act.
The model is not the complete agent
The model is the language system that generates responses. Claude, Qwen, GPT, Kimi, and DeepSeek are examples of models that receive text and produce text. On their own, they don’t have memory between calls, maintain an execution loop, or open a file or query an API.
A model can express the intention to use a tool, but it needs another system to interpret that intention and carry it out. If it responds once and stops, we still aren’t dealing with an autonomous agent.
An AI agent is not just the model. It is the model plus the instructions, tools, and system that coordinates its actions.
Scaffold and harness: two layers that are often confused
The scaffold, which can be translated as a support structure, is everything that defines the model’s behavior. It includes elements such as:
- The system prompt or main instructions.
- Descriptions of the available tools.
- The format the response must follow.
- The memory and history it receives at each step.
- The way information is organized within the context.
The scaffold determines what the model sees and the rules under which it works. It’s similar to the script, manual, and workspace a person receives before starting a task.
The harness is the execution layer. It calls the model, receives its tool requests, executes them, returns the results to the context, and decides when the process ends. Put simply, the scaffold prepares the model and the harness makes the agent work.
The distinction isn’t always used strictly. Products such as Claude Code and Codex may call the entire system surrounding the model a harness. In other contexts, the term can also include environment configurations, hooks, files, and other infrastructure.
What turns a model into an agent
An agent combines the model with a cycle of observation, decision, and action. The model receives information, proposes an action, the system executes that action, and the result returns to the context. The process repeats until the task is complete or a stopping condition is reached.
Imagine an agent for programming. The model may decide that it needs to inspect a file. The harness interprets the call, runs a file-system tool, retrieves the contents, and presents them to the model again. Then the agent can edit the code, run tests, and fix errors.
That’s why the idea is often summarized this way:
Agent = Model + Harness
However, the scaffold remains important because it determines the quality of the instructions, tools, and context the model receives. A well-designed harness must also handle errors, set limits, manage permissions, and know when to stop.
The same model can produce different experiences
When you use Claude Code, Codex, Cursor, or a similar tool, you’re not interacting with a model alone. You’re using a product made up of a model, a harness, and specific design decisions.
Two products can use the same model and behave very differently. One may offer better tools for navigating a repository, while another may manage memory more effectively or handle dangerous actions more carefully.
The reverse is also true: if you replace the model within the same harness, the experience changes. The quality of reasoning may improve, the system may become faster, or it may fail to interpret certain formats. Model, harness, and product are related concepts, but they are not equivalent.
Context engineering: deciding what the agent sees
Context engineering consists of designing the information that reaches the model at each step. It’s not just about writing a good prompt. It also involves deciding how to incorporate:
- System instructions.
- Conversation history.
- Tool results.
- Information retrieved from documents.
- Safety rules and examples.
The context changes during execution. Each response and each tool call can modify what the model receives next. If too much information is included, the model may lose important signals. If too little is included, it will have trouble acting correctly.
Memory is part of this problem. Short-term memory exists within an execution, along with messages, results, and previous steps. Long-term memory is stored outside the model and retrieved when relevant to a new session.
Policy, tools, skills, and subagents
In reinforcement learning, a policy defines the probability of choosing an action in a given situation. In language systems, part of that policy is contained in the model’s weights, but it also depends on its instructions, tools, memory, and execution cycle.
The policy is not the agent. The policy defines how it behaves, while the agent is the complete system that acts in an environment.
Tools allow the agent to move beyond text and affect the outside world. They can be an API, a web search engine, a code interpreter, a database, or a file system. The model requests an action in a structured format, the harness executes it, and the result returns to the context.
A skill groups knowledge and procedures for completing a multi-step task. A tool would be “run this command.” A skill would be “investigate this error, propose a hypothesis, and prepare a solution.” The boundary between tools, skills, and subagents can change depending on the framework.
A subagent is another agent delegated a specific task. It has its own model, scaffold, and tools, and returns a result to the main agent. The difference matters: a tool executes a function, a skill packages knowledge, and a subagent can reason, use tools, and delegate more work.
Terms that appear during training
Hugging Face also separates several concepts specific to agent training. In this scenario, the system performs tasks, receives a score, and updates the model’s weights.
The environment is everything the agent can interact with. A file system is a simple example: an action such as touch foo.txt changes the state, and the new file list becomes an observation.
The trainer coordinates episodes, calculates scores, and updates the model. An implementation such as TRL’s GRPOTrainer brings these responsibilities together in a results-based training workflow.
A rollout, also called a trajectory or trace, is a complete execution of the agent. It records what the agent observed, the actions it took, and the reward it received at each step. It is one of the main data sources used by reinforcement learning algorithms.
The reward indicates whether the agent is improving. It can be verifiable, such as checking whether tests pass; learned, such as a human preference or an evaluation performed by another model; sparse, with a single score at the end; or dense, with a score at each step.
Rubrics break that reward down into specific dimensions. For example, an evaluation may separately assess correctness, safety, and efficient tool use, assigning a weight to each criterion.
Why this vocabulary is useful
These terms still don’t have universal definitions. One framework may use harness to describe the entire system, while another reserves it for the execution loop. The glossary’s goal isn’t to impose one way of speaking, but to offer a shared mental map.
The distinction helps diagnose problems. If an agent responds poorly, perhaps the model doesn’t have the necessary capability. But the scaffold may also be at fault for providing confusing instructions, the harness for mishandling a tool, or the context for becoming overloaded with irrelevant information.
Understanding these layers allows you to analyze agents more precisely and with less mystery. Intelligence isn’t found only in the model’s weights: it also exists in the architecture that decides what the agent can see, what it can do, and how it learns from each result.