Anthropic's own team just told the market something worth sitting with: they stopped building a new agent for every job. They started building AI agent skills instead, and that shift changes how we scope every client system at luup.
What actually changed
For most of 2025, teams building on Claude treated every new use case as a fresh agent. Need a research assistant? Build an agent. Need a report writer? Build another one. Need a scheduler? Build a third. Anthropic's own engineering team described giving up on that pattern in a piece on the company's engineering blog. Barry Zhang, Keith Lazuka and Mahesh Murag wrote that the agent underneath most of these jobs had become general purpose enough that rebuilding it from scratch, every time, was wasted work.
Their fix is Agent Skills, a folder-based system Anthropic launched on October 16, 2025. A skill is a directory: instructions, scripts and reference files that the agent loads only when a task needs them. The agent itself stays the same. What changes is which skill it reaches for.
We read the full engineering writeup and the official documentation as research for every AI Operations Agent build we are running right now. Here is the substance, and what we are doing with it.
Three levels, and why the token math matters
The mechanism is called progressive disclosure. Claude does not read every installed skill's full instructions at startup. It reads three levels, in order, and only as needed.
| Level | What loads | Token cost |
|---|---|---|
| Metadata. | Name and description only, read at startup for every skill installed. | About 100 tokens per skill. |
| Instructions. | The full SKILL.md body, read once a task matches the description. | Under 5,000 tokens. |
| Resources and scripts. | Reference files and executable code, read or run only when the instructions point to them. | Zero tokens until accessed. |
That third row is the part most operators miss. A script that a skill runs through bash never loads its code into context. Only the output does. That is the difference between an agent guessing at a Python script from scratch every run and an agent calling a script that already works and already passed review.
The four rules we now build into every skill
The source material lines up four practices worth stealing directly. We have started writing all four into every skill we ship on client AI Operations Agent and Second Brain builds.
1. Stop letting the agent reinvent solved problems
If an agent solves the same technical problem twice in two different sessions, the fix belongs in the skill, not in the conversation. Save the working script inside the skill's folder. Point the instructions at that file instead of asking the agent to write it fresh next time. This is the same discipline as DRY in software engineering, and it solves a real cost problem: regenerating code from scratch burns tokens and produces a slightly different result every run.
2. Write descriptions a real person would type
Claude decides which skill to load by matching your request against the description field, not the full instructions. A vague description like 'helps with content' competes with every other vague skill you have installed, and the agent ends up guessing. A description that names the trigger words a real person would use, what the skill does and when to use it, removes that guesswork. We audit every client's skill descriptions the way we would audit a landing page headline: read it cold, ask whether it is obvious what it does and when it fires.
3. Update the skill file, not just the chat
Correcting an agent mid conversation fixes that conversation. It does not fix the next one. When a process is wrong, the fix goes into the SKILL.md instructions. When the agent is missing brand voice or house rules, that becomes a reference file inside the skill. When the same mistake repeats, that becomes an explicit rule. The skill becomes the durable memory. The chat does not.
4. Verify against evidence, not the agent's own opinion
A skill that hands you a first draft and calls the job finished is not done. Bake the check into the skill itself. For a report, that means opening the primary sources and matching every claim to evidence before it ships. For anything more subjective, run it past a few reviewer personas and only act on the issues that show up more than once. The rule that matters most: verification has to come from something outside the agent's own read of its own work.
What this means for your business this quarter
Most 10 to 50 person companies we work with are not running dozens of custom agents. They are running one AI Chief of Staff or one AI Operations Agent and asking it to do everything, which is closer to the old pattern Anthropic just abandoned. The fix is not more agents. It is skills.
Practically, that means every recurring job, following up a lead inside a five-minute window, drafting the same weekly report, chasing the same vendor invoice, becomes its own skill with its own tested script, not a fresh prompt every time. That is exactly the shape of the systems we scope inside our automation builds: one durable agent, a growing library of skills underneath it, each one checked against evidence before it goes live.
Take a voice agent handling inbound calls for a property developer. The old pattern rebuilds the call logic every time a new script gets written. The skill pattern instead keeps one call-handling agent running through our voice agent builds, and gives it a library of skills: one for qualifying a lead, one for booking a viewing, one for escalating a complaint to a human. Each skill gets its own tested script and its own verification pass, so call quality does not drift between the third call of the day and the three hundredth.
If you are still running 10+ hours a week of manual admin that a skill could absorb, that is the leak our revenue leak heatmap is built to surface. We map where the hours go before we write a single skill.
This is also why we start every engagement with the AI Concierge assessment. It costs €999, credited in full against the build, and it exists to scope which jobs deserve their own skill versus which ones are a one-off prompt. You do not need forty skills on day one. You need the two or three that touch the highest-volume, most repeatable part of your operation, built once, checked against evidence and left running 24/7.
We are applying rule four, the verification step, to every product we ship, not just the AI Operations Agent. A Second Brain build gets its retrieval checked against the source documents before we call it done. An AI Concierge script gets read by a skeptical-buyer pass before it goes live on a call. None of that is new engineering. It is the same discipline Anthropic's own team is now writing into their skills, applied to the systems we build for operators.
You can see how this plays out across our case studies, and we will keep tracking this pattern on the blog as the tooling matures.
The part we would push back on
One caution from the source material is worth repeating plainly. No skill makes a weaker model perform like a stronger one. Skills are portable in the sense that the same folder structure works across compatible agent tools, and Anthropic has published the format as open source. But the underlying model still matters. A skill sharpens a capable agent. It does not manufacture one.
That is the operator takeaway. Do not treat a skill library as a way to cut corners on model choice. Treat it as the difference between paying an agent to relearn your business every session and paying it once to remember. We would rather build three well-verified skills on a capable model than thirty on a cheap one, because the four rules above only compound when the underlying agent is strong enough to follow them in the first place.