Classify Agent Capabilities by Who Controls Them, Not What They Do

The interface between an agent and the outside world is not a flat list of functions. When you look closely at what an agent can actually reach, the capabilities sort into a small number of kinds, and the line that separates them is not what each one does. It is who decides to use it. Some capabilities the model invokes on its own judgment. Some the surrounding application supplies without consulting the model at all. Some the human selects deliberately, before any reasoning begins. Function does not distinguish these categories. Ownership does. Two capabilities that perform the identical operation belong to different kinds if a different party decides when they fire, and getting that assignment right is most of what it takes to design a capability layer that behaves. Getting it wrong produces a system that leaks, surprises, or quietly does the wrong thing, and it does so in ways that trace back with unnerving directness to handing a decision to the wrong owner.

This is the reframe worth internalizing before any particular protocol enters the picture. A capability’s defining property, for the purpose of designing a safe and predictable agent, is its control owner. The tool-integration standard the ecosystem has converged on, MCP, carves the boundary into exactly three kinds along precisely this axis, and that carving is a good one, but the triad is the instantiation. The axis is the idea. Once you see the boundary as a question of who drives each decision, the three kinds fall out on their own, and so do the failure modes that appear when you assign an owner carelessly.

The axis that matters is control, not behavior

Start with the trap, because it is the one almost everyone walks into first. The natural instinct is to classify a capability by what it accomplishes. A thing that reads data is one category, a thing that changes data is another, a thing that formats text is a third. That taxonomy feels obvious and it is nearly useless, because it tells you nothing about how the capability should be wired into an agent. Reading a document and reading a document can be two entirely different design objects depending on a single question the behavior does not answer: who decided to read it.

If the model decided, because it reasoned that the document was relevant to the request in front of it, that is one kind of capability. If the application decided, because its own logic knows that any conversation of this type needs that document present, that is a different kind, even though the bytes returned are identical. And if a human decided, because they picked a prepared workflow that happens to pull the document in as part of its setup, that is a third kind again. Same operation, same payload, three different owners, three different design objects with three different sets of consequences. The behavior is constant across all of them. The control is what varies, and the control is what you are actually designing when you decide how to expose the capability.

This is why the useful classification axis is ownership. It sorts capabilities by the one property that determines how they behave inside a running agent: which party holds the decision to invoke. That decision is where the risk lives, where the surprises come from, and where the security boundary sits. Sorting by function organizes a catalog. Sorting by control organizes a system.

The model owns actions

The first kind is the capability the model invokes on its own reasoning. These are the callable functions an agent triggers when it judges, from the conversation in front of it, that doing so serves the goal. Running a query, calling a computation, sending a notification, mutating some piece of state: anything the model should be able to reach for in the middle of its own reasoning, at a moment only it can recognize, belongs here.

Everything turns on the verb: the model decides. What makes something a model-owned action is not that it performs an action in the abstract. It is that the model, not the application and not the user, holds the choice of whether and when the call happens. The model reads a description of what the capability does and a specification of how it must be called, and then it reasons about whether invoking it advances the task at this exact point in the conversation. That reasoning is the whole reason the capability is owned by the model: the decision depends on in-context judgment that no fixed rule written ahead of time could reliably make, because whether the call is warranted is a function of what the user just said and what has happened so far.

This ownership carries the sharpest consequences of the three, and they are worth naming plainly. The set of actions you hand the model is the full reach of what your agent can set in motion. Every one of them is something the agent can choose to do, unprompted and unapproved at the level of the specific call, whenever its reasoning lands there. That is exactly the power you want when the whole value of an agent is that it acts without a human scripting each step. It is also exactly the exposure you have to bound, because a capable model with a broad action set is a system that can take a wide range of consequential steps on its own recognizance. The question of whether the model should be able to trigger something unprompted is not a separate security review you run later. It is the same question as whether the thing is a model-owned action at all, which means the classification decision and the least-privilege decision are one decision wearing two hats.

The application owns context

The second kind is the capability the surrounding application supplies to the model without the model asking. These are addressable data objects a provider exposes so that the host can pull them in and place them in front of the model before or during a conversation. A knowledge base, a policy document, a configuration snapshot, a set of records that a given workflow always needs: content the model should be reasoning over, but content the model did not and should not have to request.

The distinction from a model-owned action is entirely about who chooses. Here the host application makes the call, driven by its own logic about which material a given situation calls for: the kind of work under way, who is doing it, and where the session has gotten to. The model does not select this material. It receives it, and then it reads it exactly as it would read anything else in its context, with no awareness that it played no part in deciding the material was there. The provider’s job is to make the content addressable and retrievable. The decision about when to retrieve it stays with the application, because the application is the party that holds the broader picture of what a given situation requires.

That last point is the reason this ownership is correct rather than merely conventional. The knowledge of which background belongs in a compliance conversation, or which records a support workflow always needs, lives in the application’s understanding of its own domain, not in the model’s read of a single turn. Leaving that decision to the model would be asking it to infer, from the conversation alone, facts about the system’s structure that it has no reliable way to know. Worse, it would make the presence of essential context contingent on the model choosing to fetch it, which turns a guarantee the application could have made into a gamble the model re-runs on every request.

The user owns templates

The third kind is the capability the human selects deliberately. These are reusable, parameterized starting points, stored where the agent can offer them, that a person browses, chooses by name, and fills in before an interaction begins. A structured methodology for a recurring analysis, an approved instruction set for a regulated task, a guided path through an unfamiliar process: prepared workflows that a user launches on purpose, with intent, as the opening frame for what follows.

What makes this a distinct kind is once again the owner, and here the owner is the human. The model does not decide to apply one of these on its own. The application does not slip one in silently. A person makes a deliberate, visible selection, and that deliberateness is not incidental to the design; it is the entire point. The value of a user-owned template is that it lets people configure their own starting conditions intentionally, choosing a prepared frame rather than reconstructing it from memory each time. Take the deliberate human choice out of it and you have not improved the capability. You have destroyed the property that justified making it a separate kind at all, because a template nobody chose is just context the application injected or an action the model took, and it should have been modeled as one of those instead.

Ownership tracks who holds the information

The three-way split is not an arbitrary partition that happens to have three parts. It is principled, and the principle is worth stating because it is what lets you assign an owner correctly for a capability the examples never covered. Each kind belongs to whichever party is best placed to judge that one decision: the one with the information the call turns on, and the standing to make it without reaching past what it should own.

The model owns actions because the model is the party reasoning, turn by turn, about what needs to happen next, and it has the live context that decision depends on. No rule fixed in advance can match a model’s read of the moment for deciding whether this call, right now, serves the goal. The application owns context because the application is the party that sees the whole situation rather than the single turn, including which material a task of this kind leans on and what the current state calls for, all the things a single exchange never reveals. And the user owns templates because a template is fundamentally about a human setting their own intent, and intent is not something the model or the application is entitled to manufacture on the person’s behalf. Match each decision to the party with the best information and the least risk of overreach, and the assignment is not a matter of taste. It is nearly forced. The triad is what you get when you apply that rule to the three decisions a capability boundary actually has to make.

This is also why the axis generalizes past any one protocol’s naming. A different system might carve its boundary with different labels, or draw a line the triad does not, but it cannot escape the underlying question, because every capability an agent can reach was invoked by someone, and someone had to decide. The durable skill is not memorizing three category names. It is learning to ask, for any capability, who is the right party to hold the decision to use this, and then exposing it so that party, and only that party, does.

What breaks when the owner is wrong

The reason to take the classification seriously is that a misassigned owner does not fail loudly at the boundary. It fails later, in the running system, as a behavior that is hard to trace back to its cause. Each of the three mistakes has a characteristic signature.

Model something the application should own as a model-owned action, and you make essential context conditional on the model’s judgment. Background that the workflow always requires is now present only when the agent chooses to fetch it, which means the same request can succeed on one run and stumble on the next depending on whether the model reasoned its way to the retrieval. You have also spent a reasoning step and a round trip on a decision that was never in doubt, and you have introduced variance into a place that should have been a constant. Context the application can simply guarantee should be guaranteed, not left to a choice the model has to make correctly every time.

Model something the model should own as auto-injected context, and you get the opposite pathology, most dangerously when the capability has a side effect. A state-changing operation wired to fire on the application’s schedule rather than on deliberate in-context judgment is an action that happens whether or not the moment warrants it, on a trigger that has no view of whether the call is appropriate now. Actions belong to the party that can judge the moment. Handing that trigger to fixed application logic replaces judgment with a schedule, and schedules do not know when they are wrong.

Let the model or the application silently apply what a human should have chosen, and you strip intent from the one place intent was the entire justification. A template the user did not select is a starting frame imposed without consent, and the whole reason to make prepared workflows a distinct kind, rather than folding them into context or actions, was to keep the human’s deliberate choice in the loop. Remove the choice and the category has no reason to exist, so its misassignment is not a subtle degradation. It is the quiet deletion of the property you were trying to provide.

Underneath all three signatures is the same structural fact: control ownership is a boundary through which consequences propagate, and putting the boundary in the wrong place routes consequences to a party that cannot govern them. That is why the classification is not documentation applied after the design. It is the design.

Where the triad blurs, and where it does not

The categories are cleaner in statement than in every case you will meet, and it is worth being honest about the edges so the framework holds up against the messier cases real systems throw at it. The most common source of apparent ambiguity is a single underlying thing that legitimately has more than one owner. The same document can be background the application injects for the workflows it knows about, and also something the model should be able to query when it recognizes a need the application never anticipated. That is not a contradiction to resolve. It is two decision paths with two different owners, and the correct answer is to expose it twice, once as application-owned context and once as a model-owned action, because the classification attaches to the invocation path, not to the bytes at the end of it. The question is never what the thing is. It is who decides to reach for it in this particular path, and one thing can honestly sit at the end of two paths with two different answers.

A second edge is properties that feel like they should determine the category but do not. Whether content is static or generated fresh on each request, whether a capability is cheap or expensive, whether its result is large or small: none of these change the owner. They are real design concerns, but they are orthogonal to control, and letting them drive the classification is how you end up assigning ownership by accident. The only property that sets the category is who holds the decision to invoke. Everything else is a detail to handle within the category, not a reason to move between categories.

What does not blur is the axis itself. You can argue about how many kinds a given system should expose, or whether a particular capability wants one owner or two, but you cannot design a capability boundary without answering, for every path across it, who decides. The triad’s real contribution is that it forces that question to the front. It makes control ownership an explicit, up-front design decision rather than an implicit property you discover you got wrong when the agent fetches sensitive data it should have been handed, fires an action nobody meant to trigger, or applies a workflow no one chose. Sort your capabilities by who controls them before you build, assign each decision to the party with the information and the standing to make it, and the system that results is one whose behavior you can reason about. Sort them by what they do, and you have organized a list while leaving the decisions that actually govern the agent unmade.