One Folder, One Definition That Did Not Hold
Our internal marketplace has two folders at the top level: one for skills, one for agents. Sorting things into them, I stalled. What exactly goes where? I build these systems every day, and my quick definition still fell apart the moment I tried to write it down.
Skill, agent, automation: three words that constantly get mixed up, even by the people who build with them daily. This article sorts them out: what they mean, where the line runs, and which question actually matters in the end. Plainly, with no code required.
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. Software that works autonomously toward a goal, the who. The word says it: an agent acts on your behalf. Technically it is a language model given access to tools, which lets it decide for itself: it reads the situation, picks the next tool, checks the result, and sets the next step. The tools are where the line runs. A language model that only answers a question is not yet an agent. The moment that same model is allowed to open a website or run a search on its own, it starts acting agentically. 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: 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 | Limited | Limited | Limited |
| Agent | Yes | Yes | Yes |
Where the Clean Definitions Break
So much for the theory. As soon as I tested it against real cases, it fell apart, 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?
First attempt: rigid steps versus a growing persona. An obvious line runs at change. A skill like our ticket creation follows ten fixed steps, the same every time, and learns nothing. An agent would then be 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.
The counter-objection: skills heal themselves too. The line does not hold. 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 clean separation is softer than it first sounds.
The automation catch. Then the thing turns 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 is a language model with tools that works autonomously toward a goal on your behalf, deciding 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
There is no 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.
