Two Founders, One Folder, One Argument
Last week Keith and I were building our internal marketplace together, a directory that all of our AI tools pull from. At the top level there is a folder for skills and a folder for agents. And then the thing happened that is probably happening in a lot of teams right now: we stopped mid-build and realized we could not cleanly say what actually belongs in which folder.
Keith asked: what is the difference between an agent and a skill? I answered with my definition. He answered with his. They did not match. We build these systems every day, and it still took us twenty minutes to settle on a shared language.
When the people building the thing disagree, the confusion you may feel is not a knowledge gap. It is justified. This article opens the black box: what skill, agent, and automation really mean, why the line between them is blurry, and which question actually matters in the end. Explained plainly, even if you never write a line of code.
Why the Terms Are So Confusing
The words are new, overloaded, and used differently by every vendor. "Agent" sometimes means a chatbot, sometimes an autonomous system, sometimes a marketing promise. "Skill" means one thing in one tool and something else in the next. There is no central authority that decides who is right.
On top of that, the terms do not describe things with clean edges. They describe points along a gradient. That makes every rigid box-style definition vulnerable. Let us start with the clean version anyway, before we show where it breaks.
The Three Terms, Clean Version
Three building blocks, three simple core questions: Who decides? Does the system change over time? Does it need a language model?
Automation. Fixed steps, zero discretion. Same input, same path, every time. A classic automation is the rule "when an invoice arrives, file it in folder X". It decides nothing, it executes. This has existed for decades, with no AI at all.
Skill. A defined procedure, the how. A reusable set of instructions for a specific task. Anthropic, the company behind Claude, describes Agent Skills as organized folders of instructions, scripts, and resources that an agent loads on demand. A skill sits ready and is pulled in when a task calls for it. It describes a procedure, it does not run it on its own. The format is now an open standard that other vendors are adopting too.
Agent. The combination of instructions, a language model, and access to tools that can decide for itself, the who. The agent reads the situation, picks the next tool, checks the result, and decides the next step. This reason-act-observe pattern traces back to the ReAct principle. In Building Effective Agents, Anthropic defines agents as systems where the language model dynamically directs its own process and tool use.
My own rule of thumb from the argument with Keith: the agent runs the skill, but the skill defines the agent. The moment an agent reads the research skill, it becomes the research agent.
| App | Who decides? | Changes over time? | Needs a language model? |
|---|---|---|---|
| Automation | — | — | — |
| Skill | Eingeschränkt | Eingeschränkt | Eingeschränkt |
| Agent | Ja | Ja | Ja |
Where the Clean Definitions Break
So much for the theory. In the real argument it fell apart immediately, in three places:
- Change: Does the system learn, or does it stay rigid?
- Self-healing: Can it react to an error and adapt its path?
- Drive: Is there always a language model behind it in the end?
"In the end every skill is an agent, because a language model has to run it. I just packaged it differently." — Keith Govender, Co-Founder IJONIS
Keith's test: rigid steps versus a growing persona. Keith drew the line at change. A skill like our ticket creation follows ten fixed steps, the same every time, and learns nothing. An agent, for him, is a persona that develops over time. Our research agent and our content agent were built on purpose so that they grow through feedback and new instructions. Rigid procedure equals skill, growing persona equals agent.
My counter: skills heal themselves too. I pushed back: when the ticket skill hits an error, the model running it can adapt the procedure and correct itself. So even a "rigid" skill changes as it runs. And more fundamentally: every skill is run by a language model. In that sense there is an agent inside every skill. The line Keith draws is softer than it first sounds.
The automation catch. Then the argument turned once more. If a skill works through the same ten steps every time, at its core that is an automation, just one powered by a language model. So the third category flows into the other two. Automation, skill, and agent are not separate boxes. They leak into each other.
A Framework That Holds: The Spectrum
The resolution did not come from better boxes, but from dropping the boxes. The three terms are not separate categories, they are points along a gradient. One single axis makes the difference: how much does the system decide on its own?
At one end sits fixed automation. Zero decisions, fixed path. In the middle sits the skill, a procedure with some room to move, run by a model that adapts it when needed. At the other end sits the autonomous agent, choosing its own path. This is exactly the distinction Anthropic draws in Building Effective Agents: workflows run over predefined code paths, agents direct their own process dynamically. OpenAI describes agents the same way, as systems that independently accomplish tasks on the user's behalf. It is not either-or, it is a dial.
Why It Matters in Practice
For a company this is not hair-splitting, it is an architecture decision. You do not buy "an AI agent". You decide, per task, how much autonomy makes sense, and you match the tool to the decision load.
A task with clear, always-identical steps needs no autonomy. Give it too much, and the result becomes unpredictable and expensive to control. A task that has to weigh options and react to the unexpected on every run, by contrast, suffocates inside a rigid automation. It needs an agent. The skill lies in setting the dial correctly for each task. Too little autonomy makes the system brittle, too much makes it unpredictable.
And here a fourth term enters, the one that makes the trade-off tangible: the harness. A skill raises the ceiling of what an agent can do, because it supplies the domain knowledge. The harness raises the floor of what it reliably does: the layer of verifier, stopping conditions, and handoffs that keeps an agent on track across many rounds. For a one-off task the ceiling matters, for production the floor does.
Anthropic shows these building blocks as a runnable reference in the cwc-long-running-agents harness. More autonomy means more room to drift, which is exactly why the harness grows in importance as autonomy rises.
This is exactly the trade-off we make at IJONIS, based in Hamburg, for our clients: not "agent or not", but how much decision-making each step can handle. That is the architecture behind a system that runs reliably in daily use, not just in the demo. What this same logic looks like in real processes, we show with concrete examples in Agentic Workflows. And why the real control layer sits above the agent, we cover in Loop Engineering.
Frequently Asked Questions About Skill, Agent, and Automation
What is the difference between a skill and an agent?
A skill is a defined procedure, a reusable set of instructions for a task. An agent pairs those instructions with a language model and tools, so it can decide for itself which step comes next. The agent runs the skill, the skill only describes the procedure.
Is an automation the same as an AI agent?
No. A classic automation follows fixed steps without any discretion and needs no language model. An agent makes its own decision at every step. The skill sits in between: a procedure that a model runs and adapts when needed.
What question should I ask instead?
Instead of "skill or agent?", the useful question is: how much should the system decide on its own? The answer sits on a spectrum from fixed to procedural to autonomous, and it predicts behavior more reliably than any label. Choosing the autonomy per task deliberately is what builds systems that run reliably in daily use instead of only in the demo.
The Label Does Not Matter, the Autonomy Does
Keith and I did not land on a perfect definition in the end, and that is fine. The terms skill, agent, and automation do not describe hard borders, they describe stations on a path from fixed to free. Anyone planning an AI system gains little from the right label and a lot from the right question: how much should the machine decide on its own? Answer that, and the box sorts itself out.
