A capability can be a skill. It must never have to be one.

On 19 August I was sharing my screen with a freelance developer. Twenty-two seconds into the recording he cuts in: “when you say capability, we agree it’s the same thing as skills for AI agents, right?”

I said no. Then I spent two minutes explaining why, badly, circling the point before landing on the sentence that holds the whole thing: it can be one, but it must never have to be one.

It sounds like a squabble over words. It is actually the line between a system I can charge for and a system that costs me money on every run.

The same capability, two executions

Take the simplest capability I run: cross-posting a piece of content to several platforms.

A post comes in. If it is already good, if I wrote it myself and want it out as is, there is nothing to decide. The capability formats it, authenticates, publishes, records what went where. That is three API calls and one database write. No model wakes up, the output is identical every time, and the run costs a few cents.

Now the same post comes in as a rough draft, badly put together, written in a hurry on a Sunday night. Now someone has to pull the company context, the tone, the proof points already used, and rewrite before publishing. No script does that. It needs a model, so it needs a skill.

Same capability. Same entry point. Two paths that do not cost the same and do not take the same time.

Had I called that capability “a skill”, I would have locked the first branch inside the second. Every clean publication would have gone through a model for nothing. That is exactly what happens when you settle the vocabulary before looking at what actually happens at runtime.

The staircase only goes down

My method is four steps, and I always walk them in the same direction.

First step, the skill. At the start, everything goes here. It is what moves fastest: I describe what I want in plain language, the model figures it out, the capability exists the same day. I have nothing against a prototype built that way. It is the only sane way to begin.

Second step, the API call. As soon as the behaviour settles, I look at what inside that skill never had any business being decided by a model. Publishing to three platforms is not a decision, it is a procedure. Down it goes.

Third step, the script. What is left and has no dedicated API becomes a script of mine, versioned, tested, with behaviour I can read back.

Fourth step, the code. What has to survive over time and handle awkward cases ends up as real code, in the product, with its tests.

And when a piece genuinely cannot go down, I leave it at the top. But I isolate it. The skill then keeps only the part that is truly non-deterministic, the part that needs judgement, and everything around it moves out to API calls.

The work is never about choosing between the two worlds. It is about moving down, week after week, whatever can move down.

Why the word still matters

I could have called it a tool. I could have called it nothing at all and kept saying “my posting thing”.

Except other people’s vocabulary has already burned me. In an interview a few months ago, I could not explain what a harness was. I knew the thing, I had built one, and the word escaped me in the moment. Since then, terms everybody uses without anybody knowing what they cover genuinely irritate me. I decided to name my own building blocks, with words that describe what they actually do.

This is not fussiness about naming. The name I give a block decides how I build it. “Skill” already carries the assumption that a model sits in the loop, every single time. “Capability” carries only the idea of an outcome, and leaves me free to choose, call by call, what actually has to think.

The developer on the other end raised the one objection that counts: when you sell to someone non-technical, the term is not the problem, what you sell is the outcome and what it does for them. He is right, and it contradicts nothing. Vocabulary is not there to sell, it is there to build correctly. As I write elsewhere: the value is not in the agent, it is in the process you hand it.

What it costs to run

Here is where the distinction shows up on an invoice.

The orchestrator running my capabilities sits on a 10 year old MacBook Pro, an i7, 16 GB of RAM. It computes nothing. It only orchestrates: it reads what comes in, it picks the branch, it makes API calls.

That is only possible because most of what runs is deterministic. If every execution had to wake a model, that machine would not do, and worse, every publication would be billed at the price of a thought when it was only ever a procedure.

The same arithmetic applies to anyone buying this kind of system. What sets the monthly price is not the number of features, it is the share of the system that still needs to think. When a vendor cannot answer that question, it means everything stayed on the first step.

The guardrail

Walking down the staircase does not mean taking the human out of the loop.

Autonomous in execution, controlled in outcome. A capability publishes on its own because the rule it applies was settled once, by me. What moves down is the execution of the gesture. What never moves down is the decision about what gets published, to whom, and at what price.

That is the real test, in fact. If you have to read every output of your automation, it is still entirely on the first step, and you have swapped one chore for another rather than removing one.

The sentence I keep

Two minutes of fumbling to get there, but it stands on its own.

A capability can be a skill. It just must never have to be one.

The day it has to be, you have not built a capability. You have taken on a dependency you pay for on every run.

So what about you: in whatever you are running right now, how many times a day do you wake a model up to make it follow a procedure?