Who Actually Did That? Making Sense of Model, Context, Tool, MCP Server, Skill, Agent, and Harness

Ask why an AI app did something and the answer usually starts with "the model decided to." Almost always, it didn't. The model predicted some tokens. Something else, a harness, decided what to do with them.

Six pieces share the work in a modern AI system: model, tool, MCP server, skill, agent, and harness (plus the stuff that flows between them, context). They're easy to blur together because they run side by side all the time. But blurring them costs you the one thing worth having here: the ability to look at any behavior and say exactly which part produced it. Was the limit in the brain, the bench, the tools, the plug, the playbook, the worker, or the shop that runs them?

Picture a workshop. You need a brain to make sense of the job, tools on the bench to actually do it, sockets to plug in tools you don't own, a playbook for the tricky builds, a worker to see the job through, and the shop itself, floor, power, safety rules, and a manager calling the shifts. Here's how the pieces fit.

Harness — the shop, and the manager who runs it
  │
  ├─ Agent — the worker with a goal
  │    loop: Observe → Decide → Act → repeat, until done or stopped
  │    │
  │    ├─ Model    — the brain     (predicts tokens)
  │    ├─ Context  — the bench     (what's in front of it right now)
  │    ├─ Tools    — the tools     (native, or plugged in via MCP)
  │    └─ Skill    — the playbook   (loaded when a job calls for it)
  │
  └─ MCP Server — the universal socket
       exposes tools, resources, and prompts over a standard protocol

Let's dive deeper into each piece.

Model: the brain

A model is an engine that, given some text, predicts what tokens come next. That's the whole job. Sometimes those tokens are a sentence for you to read; sometimes they're a structured request the harness recognizes as "call this tool, with these arguments." But the model isn't doing two different jobs in those two cases, it emits tokens either way. Whether anything happens as a result is someone else's call.

What it doesn't have: goals of its own, an execution loop, a filesystem, or any memory beyond the text in front of it right now.

*Example:* Claude Opus 4.8.

A model is close to brilliant inside its context window and helpless outside it. If something happened out in the world, it's because another part of the system fed the model, read what it produced, or ran what it proposed.

Context: what the worker can see right now

Context isn't a gadget like the others, it's the working memory the model operates on. Every prediction is a function of what's in the context at that moment: the system prompt, the conversation so far, retrieved documents, tool results, whatever skill is loaded. Change the context and you change the behavior without touching the model at all.

This is why "the model got worse" is so often the wrong diagnosis. More often the harness loaded different context, dropped an instruction while compacting a long history, or stopped surfacing a tool. The brain is the same. The bench it's working on changed. Keep context in view as the thing that flows through every other piece below.

Tool: a single action on the bench

A tool is one named function with a fixed shape for its inputs and outputs: list the files in a folder, open a pull request, run a query. One tool, one job. There are two flavors, native tools built straight into the harness, and MCP-backed tools reached through a standard protocol (next section).

The part people get wrong is who does what. The model doesn't wield a tool the way you'd swing a hammer. It writes down a request, this tool, these arguments, in a format the harness understands, and the harness is what actually picks up the hammer, or refuses to. The model proposes; the harness disposes. Everything downstream of that split is where permissions and safety live.

MCP Server: the universal socket

MCP (Model Context Protocol) is a standard interface for exposing tools, data resources, and prompts to a harness. The point isn't where the capability runs, an MCP server can sit on your own laptop or across the internet, it's that the harness talks to all of them the same way instead of hardcoding a bespoke integration for each one. It's the socket, not the appliance you plug into it.

*Example:* a GitHub MCP server that lets a harness inspect and manage repositories through that one standard interface.

Once a server is connected, its tools show up to the agent exactly like native ones. The agent doesn't need to know, or care, which side of the socket a given tool lives on.

Skill: the playbook

If a tool is the hammer, a skill is the step-by-step build guide for making a cabinet: which tools to reach for, in what order, what to check along the way, when to stop. It's procedural knowledge, packaged so the worker can follow a known-good path instead of improvising a complex job from scratch.

A skill isn't loaded all the time. The harness pulls it in when the job in front of the worker calls for it, and it stays on the shelf otherwise. And it replaces nothing — not the tools it directs, not the model reading it. It just biases the work toward a procedure someone already got right.

Agent: the worker

Point a model at a goal, give it tools and somewhere to track what it's doing, and let it run in a loop — observe the state, decide the next move, act, look at the result, go again — and you have an agent. The loop runs until the goal is met, or something errors out, or the harness calls time. That loop is the entire difference between an agent and a model: a model on its own answers one prompt and stops, while an agent keeps going until the job is done.

*Example:* an agent told to find a particular file in a large codebase. It scans the project, picks a search tool, reads the results, refines, and stops the moment it has the file.

Agents can also spin up subagents — helper agents, each with its own separate context, sent off to handle a sub-task without cluttering the main thread.

Harness: the shop, and the manager

Everything above runs inside the harness: the top-level program that makes the loop real. It creates the agent, assembles its context, calls the model, executes, or blocks, tool calls, enforces permissions, trims the history when it grows too long, spawns subagents, and decides when the task is finished.

*Example:* Claude Code.

If the agent is the worker, the harness is the shop around it: the benches, the power, the safety rules, and the manager who decides who's on shift and when the day is over. Which brings us back to the opening. Most of what people credit to "the model" is really the harness, what context got loaded, which tools were visible, what a skill was allowed to say, whether the loop got to continue. Shop policy, not the brain.

Putting it back together

• The model predicts.
• Context is what it predicts from.
• A tool is one action it can ask for.
• An MCP server is how outside tools and data plug in.
• A skill is how to do a longer job well.
• An agent is the worker looping toward a goal.
• The harness is the shop that makes the loop real, safe, and stoppable.