Claude Skills for Business Workflows: What Changed

A Claude Skill is a folder containing a SKILL.md file plus whatever scripts and reference files the job needs, and it teaches an agent to do one specialized task the same way every time. The agent loads it when that task comes up, the way a new hire opens the procedure doc instead of memorizing every procedure on day one.

On August 19, 2026, Anthropic moved Agent Skills and the Skills API out of beta on the Claude API. The coverage framed it as a developer release. The business translation is more interesting, and it lands on a question a lot of operators are already asking: where does our institutional knowledge live once agents do the work?

What is a Claude Skill?

The format is deliberately boring, which is the best thing about it. A skill is a directory:

invoice-review/
├── SKILL.md          # required: metadata plus instructions
├── scripts/          # optional: executable code
├── references/       # optional: documentation
└── assets/           # optional: templates

SKILL.md needs a name and a description at minimum, then the instructions themselves. Everything else is optional.

Agents load skills through what the spec calls progressive disclosure, in three stages. At startup the agent reads only each skill's name and description, just enough to know when it might be relevant. When a task matches, it reads the full SKILL.md into context. Then it follows the instructions, running bundled code or pulling referenced files only as needed.

That staging is the part worth understanding, because it is what makes a library of fifty procedures practical instead of a context-window problem. Fifty descriptions cost almost nothing. Only the one that matters gets fully loaded.

What went generally available on August 19 was the Skills API (/v1/skills) alongside computer use, the new browser use tool, and the Files API. Per Anthropic's own release notes, requests no longer need the skills-2025-10-02 beta header, including Messages API requests that load Skills through the container parameter. Requests still sending the header keep working unchanged, so nobody's integration broke that morning.

Say plainly what a Skill is not. It is not a model. It is not a fine-tune. It is not an integration. It carries no credentials and reaches no system on its own. It is written-down know-how in a format an agent can load.

Skill vs tool vs MCP server: which one do you need?

This is where most teams get stuck, and the distinction is simpler than the discourse suggests.

The decision rule fits in one line: a tool grants an action, an MCP server grants access to a system, a Skill grants know-how.

The common and expensive mistake is building an MCP server when the actual gap was that nobody had written down how the job is done. We have watched teams spend six weeks on an integration so an agent could reach a system it was already reaching, because the real failure was that the agent did the work differently every time. That is a procedure problem wearing an integration costume.

The reverse mistake exists too. A beautifully written Skill cannot help an agent that has no way to reach the database. Diagnose the gap before you pick the shape.

Why this matters for a business, not just a developer

Here is the part that has nothing to do with APIs.

Most companies keep their real operating procedures in three places: a wiki nobody updates, a Slack thread from eleven months ago, and the head of the person who has been there longest. That has always been a liability. It becomes a bottleneck the moment you want an agent to do the work, because an agent cannot absorb tribal knowledge by sitting near someone.

A Skill turns that procedure into a versioned artifact. It lives in a repository. It gets reviewed the way a runbook change gets reviewed. When the procedure changes, somebody edits a file, and the change is visible, attributable, and revertible.

That has a second-order effect worth naming. Writing the procedure down well enough for an agent to follow it is a genuinely useful exercise even if you never ship the agent. Ambiguity that a human employee silently papers over becomes visible immediately, because the agent does the ambiguous thing and you see it.

On who writes them: in practice an operator drafts the procedure, because the operator is the one who knows it, and an engineer hardens the scripts and the edge cases around it. That division works better than either group doing both.

Where Skills fit in a system we would actually ship

Zoom out to the architecture level, because a Skill on its own is not a system.

In the agent systems we build, four things do four different jobs. Orchestration decides what happens and in what order, deterministically where determinism matters. Tools and MCP servers reach the systems that hold the data. Skills carry the repeatable procedures. Evals decide whether any of it is actually working, which is the layer most teams skip and then cannot explain why quality drifts.

Skills sit squarely in the third slot. They are not the agent orchestration methodology, they are one component inside it.

We use this shape across our own platforms. Smile PreVue is live on the App Store, Howdy Dispatch runs paying carriers, and both have operational procedures that need to happen identically every time regardless of which run executes them. Those are the workloads where packaged procedure earns its keep.

Be equally clear about where a Skill does not help. One-off work does not need one, and writing it costs more than doing the task. Anything requiring real judgment does not belong in a procedure file, because you will encode a decision that should stay a decision. And anything that changes every time is, by definition, not a repeatable procedure. Forcing those into skills produces a library nobody trusts, which is worse than no library.

How portable is a Skill really?

This deserves care, because two separate questions get blurred into one and the answers are genuinely different.

The format is open. The Agent Skills spec is published at agentskills.io, and the site states it was originally developed by Anthropic, released as an open standard, and is open to contributions from the broader ecosystem. The adoption list is the real evidence: Cursor, GitHub Copilot, VS Code, Gemini CLI, OpenAI's Codex, OpenHands, Goose, Letta, and a long tail of others all document skills support. A SKILL.md you write today is readable by agents from competing vendors.

Hosted execution is a different question. Running Skills through the Claude Platform depends on Anthropic's code execution environment and the Files API. That is infrastructure, and infrastructure is where the real switching cost lives. Being able to read your file elsewhere is not the same as being able to run it elsewhere.

We are not going to predict which lab wins, because that prediction has been wrong for everyone who has made it. The practical hedge is unglamorous: keep the procedure itself in the open format, keep your execution assumptions explicit and written down, and know in advance which half you would have to rebuild. For most businesses that answer is comforting. The procedure, which took the longest to get right, is the portable half. The runtime, which is the locked half, is also the replaceable half.

What to do this quarter

If you take one thing from the GA announcement, make it this: the interesting work is not adopting an API.

Pick one procedure your team does inconsistently. Not the hardest one, the one where the output varies depending on who did it. Write it down properly, before choosing any technology at all. If writing it down is hard, you have found something more valuable than a Skills integration.

Then diagnose the gap honestly. Is the problem know-how, access, or action? That single question answers Skill versus MCP server versus tool, and it prevents the six-week integration that solves nothing.

If you want a second set of eyes on where agents actually fit in your operation, get in touch. If you would rather read how we work before talking to anyone, our approach lays out the method.