Разработчики Anthropic разъяснили различия между моделью, сервисом вывода и инструментом в системах агентов

Your Agent Is Not the Model I often hear people use the words agent and model interchangeably, referring to Claude as either one. So I thought it would be useful to write a quick reference on the terminology we use here, to help us have more precise conversations. Let’s start with a graphic that shows where we are headed. The Agent System An agent system is made up of several layers. At its core is a model. Things like Sonnet, Opus, or Gemini. These are trained on vast amounts of text and data, and in the end, they are essentially big collections of floating point numbers wired together in a particular way. Frontier models are far too computationally expensive for most of us to run locally at full scale. They need way more RAM than most of us have on our local machines. So we need somewhere else to run them. That somewhere is an inference service. Services like AWS Bedrock or Anthropic’s API. The inference service takes your API calls, feeds them into the model, and also tracks pricing as you go. The service runs the model in an inference engine, but it is still pretty basic. Text in, text out. Think of how ChatGPT worked when it first launched. That interaction layer, the thing that gives you a nice way to talk to the API, is called a harness. In its simplest form, it is just a lightweight wrapper. Other harnesses you might know are Claude Desktop or Claude CLI. And this is where things get interesting. Features like MCP and Skills? They are primarily part of the harness layer. The model doesn’t inherently know about an MCP server or a Skill; the harness decides what context and tools to expose to it. So if you put all that together, an agent system is a harness, a set of tools and logic for processing inputs, that calls an inference service, which runs a model. That is it. That is the whole stack. Real world examples Here is how the stack breaks down for some common tools you might be using. Notice the pattern. The harness is where your logic lives. The inference service is the hosted layer that runs the model. The model is the mathematical thing that produces text. The same model, say Sonnet, can be used across multiple agent systems with completely different harnesses, and it will behave differently because the harness is shaping the inputs and interpreting the outputs. Time to torture a metaphor Let’s imagine we are building a house. We have a building crew on site. They take a blueprint, order materials, handle equipment, and decide sequencing. They are the only ones who can actually touch the ground. Pour concrete, hammer nails, that kind of thing. But if something comes up and they need brainpower, they call an architect. They can’t talk to the architect directly, though. They have to go through the firm that employs them. The firm handles scheduling and billing. And the architect is very particular. You give it a brief, it gives you back paper plans. Nothing more. The crew is the harness. They’re the part that can actually touch the outside world and turn the architect’s plans into actions. The firm is the inference service. The gateway that handles logistics and cost. And the architect is the model. Pure, constrained, and brilliant at its narrow job. So when you use something like Claude CLI, the CLI is the harness. It uses Anthropic’s inference service, which runs their models, Sonnet and Opus. One interesting implication: as models get smarter, they might make some of today’s harness logic, like Skills or MCP, less useful. The way we build harnesses now might not age well. The takeaway Let’s be explicit with our terms. - Model - the mathematical function that transforms input tokens into output tokens. - Inference service - the hosted service that runs the model and tracks usage. - Harness - the logic that shapes inputs, interprets outputs, and touches the outside world. - Agent system - all three working together. When we say “my model is doing this or that,” we are usually talking about what the harness is orchestrating. The models themselves are just these inscrutable mathematical objects that we get to call out to. And that distinction matters. Because if something goes wrong, or if we want to make things better, we need to know where to look. Is the model giving bad answers? Maybe it needs better context from the harness. Is it too slow or too expensive? That is probably the inference service or the compute underneath. Is it not using tools correctly? The harness is probably formatting them wrong or not parsing the responses properly. When you can name the layer, you can fix the layer. That is the whole point of being precise. It is not about being pedantic. It is about being able to improve things faster and more effectively.