TL;DR: The new AI vocabulary is about the systems around the model, not the model itself. Harness, agent loop, tool contract, progressive disclosure, MCP, grounding, guardrails and human handoff each describe one part of turning a model into an agent a business can trust. Here is what each one means, why it matters, and what it looks like in practice.
Every now and then, the AI industry replaces its vocabulary with a fresh batch of terms everyone is suddenly expected to know. In 2023, the words everyone needed to know were prompt, token, and hallucination, because most people met AI through a chat box and the main skill was learning how to talk to it. By 2025, we had moved on to context windows, embeddings, and retrieval, as companies tried to get models to answer questions using their own documents instead of relying entirely on what the model had absorbed during training. Now, a new set of terms is circulating through product launches, engineering blogs, and investor updates, and many people nod along without a clear picture of what they actually mean.
The industry’s attention has moved away from the “brain” of Artificial Intelligence itself and toward the systems around the model: how agents take action, how their outputs are checked, when humans need to intervene, and how we figure out what went wrong when something inevitably does. As models from different labs become increasingly competitive, the model itself is becoming less of a differentiator. The difference is in the engineering around it, and that is exactly what this new vocabulary describes.
I’ve put together eight terms you’re likely to encounter in 2026, roughly following the way an AI agent is built, from the components that give it capabilities to the systems that keep it accountable once real customers are involved. I’ll explain what each one means, why it matters, and what it looks like outside an engineering diagram.
| # | Term | What it covers |
|---|---|---|
| 1 | Harness | The runtime around the model that runs its tools and enforces the rules |
| 2 | Agent loop | The decide, act, observe cycle, and the step budget that bounds it |
| 3 | Tool contract | What a tool accepts, what it returns, and what the model may claim |
| 4 | Progressive disclosure | Showing the model only what it needs for the current step |
| 5 | MCP | One open standard for connecting agents to tools and data |
| 6 | Grounding | Making answers depend on context and knowledge the business controls |
| 7 | Guardrails | Deterministic checks before the model runs and after it drafts |
| 8 | Human handoff | Approval and takeover, and what the agent must stop doing |
1. Harness
An AI model can generate a tool call, but generating one is not the same as executing it correctly. It doesn’t automatically know whether the requested tool exists, whether the parameters are valid, whether the API is responding, or whether the result actually completes the task. Those responsibilities belong to something we call a harness: the runtime infrastructure that sits between the model and the application it operates in. It manages the agent’s available tools, enforces execution rules, validates model-generated instructions, and controls the loop through which an agent receives information and takes successive actions.
A useful way to think about it is that the model decides what to do, while the harness controls how it gets done. It connects the model to tools, enforces permissions, validates requests, handles failures, and manages what happens next. Without it, you have a model that can suggest actions but no reliable system to carry them out.
The model decides what to do. The harness controls how it gets done.
OpenAI’s Harness Engineering article provides a practical look at this approach through its work on Codex. It illustrates why so much of agent development involves infrastructure that has very little to do with model training or prompt design.
It also explains why harness engineering (the practice of designing and building this layer deliberately, as a product in its own right) has become increasingly important as model capabilities converge. The model can be changed independently of the surrounding application because the tools, execution logic, permissions and validation mechanisms are managed separately. Instead of rebuilding your product around every new model release, you replace one component while keeping the rest of the system intact.
Building that layer well is a project in itself, which is why some agent-building platforms now ship with a sturdy harness already in place. That saves you the headache and leaves your time for deciding what the agent should actually do.
2. Agent loop
An agent rarely completes a task in a single model call. It takes an action, receives the result, evaluates what happened, and decides what to do next. This repeated cycle is called the agent loop.
In Building Effective Agents, Anthropic draws a useful distinction between agent loops and workflows:
- Workflow: a predefined sequence in which code determines when the model is called and what happens afterward.
- Agent: the model has more autonomy. It decides which tool to use and what step to take based on the results of previous actions.
Of course, giving a model control over the next step doesn’t mean giving it unlimited attempts. Agents can repeat tool calls, get distracted by irrelevant results, or spend several steps trying to solve a problem that a simpler approach would have handled. A step budget puts a limit on that behaviour.
In practice a budget has two numbers:
| Number | What it does |
|---|---|
| Default per turn | How many tool calls the agent may make in a single turn. For an agent answering customers over chat or text, this is often as low as two or three, because a person is waiting for the reply and most turns only need a lookup and an action |
| Hard ceiling | The number it can never exceed. It exists for the unusual cases, and when the agent reaches it, it responds with what it has instead of trying again |
Coding agents sit at the other end of the scale and routinely get dozens of steps, since nobody is watching a typing indicator while the tests run.
The design of this cycle is starting to be called loop engineering. Whether or not the name lasts, the decisions behind it are permanent ones:
- What ends the loop.
- What each step is allowed to cost.
- When the agent has to stop and ask a person.
- Who verifies the result when it reports that the task is complete.
3. Tool contract
Every tool an agent can call has an interface: the parameters it accepts and the result it returns. A tool contract is that interface written down and enforced, together with the parts that usually go unwritten: how long the call may take, what happens if it is retried, and what the model is permitted to say once the result is back.
The input side is rarely the problem, because the model cannot make the call without knowing the parameters. The output side is where things go wrong. If a booking tool returns loosely structured text, the model has to interpret it, and models interpret ambiguous results generously. The customer is told the appointment is confirmed when the system actually reported a conflict.
A contract that holds up in production has four parts:
- Named outcomes: it returns one of a fixed set, such as booked, slot unavailable, too soon, or uncertain, and never free text.
- An idempotency key: so that a retried call cannot create two appointments.
- Schema validation: the model’s arguments are checked, so a hallucinated field name becomes an error instead of a silent failure.
- Language tied to the outcome: the agent may say an appointment is booked only when the tool said so.
The agent may say an appointment is booked only when the tool said so.
4. Progressive disclosure
Context windows have grown large enough to hold entire codebases, and the first instinct of many teams was to fill them. The results were disappointing. A model’s attention degrades as the window fills, and a model shown forty tool definitions chooses between them less reliably than one shown six.
Progressive disclosure is the response. The model is given the minimum it needs for the current step, with the rest available on request.
- Tools are presented as a name and a one-line description, and the full parameter schema is loaded only when the model selects one.
- Data works the same way: the model knows a knowledge base exists and what it covers, and retrieves specific passages when a question requires them.
- Procedures follow the same pattern through skills, explained below.
Anthropic’s Agent Skills format applies the same idea to procedures. A skill is a folder containing a SKILL.md file with instructions, plus any scripts or reference material it needs. The agent sees only the skill’s name and description until a request matches, at which point the full instructions are loaded. An agent can have dozens of skills available and pay the context cost of one. Both Claude and ChatGPT now let users add their own, which makes this one of the few agent engineering patterns that has reached a settings page.
A practical consequence: many reports of an agent “ignoring” an instruction turn out to be cases where the instruction was present but buried in a prompt that had grown far beyond what the model could reliably attend to.
5. MCP (Model Context Protocol)
The Model Context Protocol is an open standard for connecting AI applications to tools and data sources. A provider runs an MCP server that describes the tools and data it offers, and any client that implements the protocol can discover those tools and call them. The specification is public and defines how servers advertise their capabilities and how clients invoke them.
Before MCP, a company that wanted its calendar or CRM available to several assistants built a separate integration for each one, and each integration broke whenever either side changed. A shared protocol removes that duplication, which is why adoption has been fast, why platforms are being built on it, and why the term appears on so many product pages.
MCP support on a product page tells you less than it appears to. It means the product can connect to MCP servers. It says nothing about which servers, or what permissions each connection carries, and those are the two questions that determine risk.
A read-only server over a document store and a write-enabled server over a billing system are both MCP.
6. Grounding
Grounding is the term for making an agent’s answers depend on information it was given, so that any price, policy, or opening time it states can be traced to a source the business controls. It is sometimes used loosely to describe pasting an FAQ into a system prompt. The more useful version separates two kinds of information.
| Context | Knowledge | |
|---|---|---|
| When the model gets it | On every turn, without asking | Only when a question calls for it |
| What it holds | The business profile, the customer’s record, the current date and time, and the conversation so far | Policies, price lists, uploaded documents: everything too large to send with every request |
| Example | If the profile lists the accepted insurance plans, the agent answers the insurance question from context alone | A question about the cost of a cleaning finds a passage titled “Services and prices” even though the wording differs |
The search behind the knowledge column is retrieval-augmented generation, introduced in a 2020 paper by Lewis and colleagues at Facebook AI Research. In current systems the documents are split into chunks of roughly a thousand tokens, embedded, and searched by meaning. Only passages above a similarity threshold are returned.
The failure mode is consistent across implementations. When nothing relevant is found, an ungrounded model answers anyway, in the same tone it uses when it is right.
The simplest test of any agent’s grounding: ask about something it was never told and see whether it says so.
7. Guardrails
Guardrails are deterministic checks that run outside the model. Some run before the model is called and decide whether it should respond at all. Others run after it has produced a draft and decide whether that draft is allowed to go out. They exist because the model is probabilistic and the business is not. Behaving correctly most of the time is acceptable for a model and unacceptable for the system sending messages to your customers.
The pre-checks are deliberately unglamorous. None of these decisions should involve a model.
| Pre-check | The question it asks |
|---|---|
| Opt-out | Has this contact opted out? |
| Takeover | Has a teammate taken over the conversation? |
| Duplicate | Has this exact message already been processed? |
| Hours | Is the agent within its operating hours? |
The post-checks compare the model’s draft with what the tools actually did. Consider a scheduling agent whose booking tool has just returned slot unavailable because another customer took the time moments earlier:
- The model, following the pattern it has seen thousands of times, drafts a confirmation anyway.
- The post-check finds a claim of a booking with no successful booking behind it and rejects the draft.
- The draft goes back to the model once, with the real outcome attached.
- The corrected reply offers the next open time.
The customer never sees the first version, and nothing about the model has changed.
OpenAI’s harness article describes the same principle for code generation. The agent’s claim of success is verified by something other than the agent.
8. Human handoff
Every agent needs a defined way to leave a conversation. Some requests fall outside policy, some customers are past the point where an automated reply is helpful, and some messages describe situations that need a person immediately. Human handoff, also called human-in-the-loop, escalation, or takeover depending on the vendor, is the mechanism for transferring a conversation or a decision to a person.
It takes two forms:
- Approval: the agent prepares an action, such as a refund or a reschedule, and a person confirms it before it executes.
- Takeover: a person enters the conversation and the agent withdraws.
Takeover is harder to implement correctly than it appears, because an agent consists of more than its replies. It typically has scheduled follow-ups and outreach sequences attached to the same contact, and a takeover that only silences the chat leaves those running. The result is a familiar failure: a customer asks for a manager, the manager replies personally, and an hour later the agent’s scheduled follow-up arrives asking whether they are still interested.
A correct implementation treats takeover as one of the pre-checks described above. Once a person owns the conversation:
- The agent is halted before the model runs.
- Every scheduled message for that contact is suspended.
- Nothing resumes until the person hands the conversation back deliberately.
The easiest property of an agent product to verify from the outside: ask for a human, then wait and see whether the agent messages you again.
The Short Answer
None of these eight terms describes a way to make the model smarter, and that is the point of the list. The model has become good enough that the interesting problems now live in the code around it: how it acts, how its claims are checked, when it steps aside, and how its behaviour can be reconstructed afterwards. Knowing the vocabulary of that code is what lets you ask an agent vendor the right questions, and notice when they cannot answer them.
That’s it, you’re now part of the 10%. See you next time the vocabulary changes.
