The company that made agents all the rage is now telling you not to use so many of them… and I think it’s right.
After setting up a team of multiple AI agents—a manager who assigns tasks, one agent who researches leads, another who writes content, and another who handles billing—and drawing on the hands-on experience I’ve gained, I want to share with you the most counterintuitive lesson I’ve learned over the past few months. What really boosts my productivity isn’t setting up a new agent every time a task comes up—it’s training the ones I already have more effectively.
The other day, I summed it up almost without thinking: when you have a repetitive task, don’t open a new ticket; create a skill. Teach the system once and for all, so it can help you efficiently with all the tasks that come after. It may sound simple, but it’s true.
But... what is a "skill"?
Let’s take it one step at a time—the terminology here has gotten pretty dense. In October of last year, Anthropic launched Agent Skills: basically, folders containing instructions, examples, and some scripts that the agent loads only when it needs them. They aren’t forced into the model’s “brain,” taking up space. The agent looks through the catalog, decides which one it needs for the task you’ve asked it to do, and opens it at that moment. They call this “progressive disclosure,” which basically means “don’t read the whole manual just to change a light bulb.”
The analogy used by the people at Anthropic themselves to explain it is a cooking analogy, and I think it’s spot-on: the MCP is the pantry (it connects the model to your data and tools), the agent is the chef (the one who decides and executes), and the skill is the recipe. You can have the best pantry in the world and a brilliant chef, but if you haven’t given him your family’s recipe, he’ll make you a generic omelet—not the one your mom makes.
In fact, a skill helps your agent understand how you want them to perform their tasks, following your guidelines. Not which tool they should use (the MCP already provides that), but what criteria to follow, what tone to use, what steps to take, and which rules to follow. The difference between “you have access to my email” and “this is exactly how I write an email to a client” is like night and day.
The twist that almost no one has told the story of properly
The same company that has popularized the word “agent” to the point of exhaustion has been warning, for months, in its guide on how to build effective agents, that most production systems don’t need another autonomous agent. They need a workflow with clear steps, tailored tools, and measurable results. Autonomy is only added when flexibility outweighs the latency, cost, and errors that accumulate along the way. Which, honestly, is almost never the case.
Translated into plain English: Not everything deserves an agent. An agent is expensive, slower, and can get out of hand (I know a thing or two about this, I assure you; I’ve already talked about it here about the security front where the internet talks to your agent behind their back and your agent listens to it—which is pretty scary). Every new agent you set up is another mouth to feed, another point of failure, another token bill to keep an eye on. A skill, on the other hand, is knowledge that you package once and reuse in as many agents and conversations as you want. It’s shared, versioned, and corrected. It’s boring. And in engineering, boring almost always wins.
Take a look at this strategic move—and it’s no small one: Anthropic is launching the “skills” format as an open standard, exactly the same move it made with the MCP a year ago, when it became the de facto way for agents to connect to tools. First, you standardize how things plug in (MCP). Then you standardize how they’re taught to use them (skills). Whoever controls both plugs controls the whole kitchen… you don’t have to be a genius to see where this is going.
So, agents or skills?
The honest answer—and the one given by sensible people who analyze this without all the hype, is the most boring of all: both. It’s not a war; it’s a division of labor. The agent orchestrates and makes decisions; the skill provides the specific expertise to do it right; the MCP gives access to where your data lives. All three at once, each in their own role.
But if you force me to choose where to start, I’m absolutely certain—and this goes against the grain of almost everything you read— start with the skill. Before you think, “I’m going to set up an agent to handle my billing,” ask yourself if what you’re actually dealing with isn’t just a repetitive task with its own set of rules that you could package. Most of the time, what you think is an agent problem is actually a problem because you’ve never properly explained to the system how you do it.
And here’s something very important: the context you provide in a skill is what helps the agent understand its task—not the most expensive model, not the most autonomous agent. Context. Your guidelines, your examples, your “do this, don’t do that.” A mid-range model with a very well-written skill will give you better results than a top-of-the-line model left to its own devices, guessing what you wanted. I see this every week.
And one level up: the plugins
Okay, so where does a word you’re going to start hearing everywhere—”plugin”—fit in? Well, it’s the icing on the cake, and I like to think of it just as I jotted down the other day: a plugin is, more or less, the sum of all the above packed into a single package. In October, Anthropic introduced Claude Code’s plugins: installable packages that bring together various skills, their MCP connections, commands, and even agents—all bundled together and ready to use.
If a skill is a recipe, a plugin is the entire cookbook —complete with a pantry and all the necessary utensils already included. Instead of teaching your system one recipe at a time, you install the whole package all at once.
What’s really interesting is how they’re distributed: through marketplaces and catalogs where you choose and add what you need without having to build anything yourself. It’s—and I can’t think of a better way to put it—the “App Store moment” of all this. Or the “npm (Node Package Manager) moment,” if you’re the type who writes code.
Take a second to think about what that means for your business. Tomorrow, you won’t be “setting up” your billing with AI from scratch: you’ll install a billing plugin that already comes with the agent, the skills tailored to your business or industry’s rules, and the connections to your tools—and you’ll just need to teach it the four specifics of your business. The learning curve for setting this up flattens out dramatically. What takes me a full day’s work today will, before long, be just a couple of clicks and a bit of fine-tuning.
What I Believe (The Useful Part)
First of all—and this goes especially for anyone leading a team that’s serious about implementing AI—stop measuring this by the number of agents. I’ve seen people boast about “having twelve agents up and running” as if it were a medal—but it isn’t. Twelve poorly trained agents mean twelve places where things go wrong. In fact, one well-trained agent with sharp skills is preferable to a huge, disorganized digital workforce.
On the other hand—and this is what I see as the real good news—skills democratize this process tremendously. You don’t need to be a programmer to write one, since it’s in natural language; it’s your instructions: “When it asks for X, do it this way; watch out for this other thing.” Anyone who can clearly explain how they do their job can turn that knowledge into something the machine can reuse. And for an SME that doesn’t have an engineering team behind it, that’s a game-changer. The most valuable asset is no longer the person who knows how to program agents, but rather the person who can clearly explain how things are done in their company.
For two years now, we’ve been caught up in the “autonomous agent” craze—the “let them run wild and see what they do” approach—and it turns out that the most sensible advice, even from those who make a living selling agents, is almost the opposite. Don’t give them more autonomy than they need; give them more context than you think they need; teach them, instead of just letting them go. Come to think of it, that’s exactly what we do with people when they’re new to a team: you don’t leave them alone on their first day “to see how it goes”—you explain how things are done, right?
So now you know: the next time you find yourself about to set up yet another agent for a recurring task, stop for a second. Maybe you don’t need another cook in the kitchen—maybe you just need to write down the recipe… or just install the whole cookbook.
And how are you guys approaching this? Are you still in the phase of creating agents for everything, or have you already started thinking about training them instead of just creating more?
Leave me your comments, I’d love to read them.
Have a good week!
