On Oct. 22, 2026, Anthropic said it is handing Agent Skills over to the Agentic AI Foundation, or AAIF, under the Linux Foundation. The transfer covers the project name, logo, GitHub organization, and official domain. From here on, engineers from several companies will maintain it.
Agent Skills is designed to keep the method for a type of work in files an AI system can read while doing the job. A team can bundle steps, templates, reference materials, and required scripts into one skill package, then let the runtime pull in the pieces that fit a specific task. So the instructions users would otherwise keep repeating in chat can be saved, edited, and reused.
Turning a work method into a reusable package
The article uses an editorial team as the example. Say that team has to handle research, writing, image prep, and review every week, and it already follows fixed habits for headlines, chart font sizes, source checks, and delivery folders. Rewriting all of that in every single conversation wastes time. And things get missed.
With the Agent Skills format, the team can turn those requirements into a skill package. That package may include a core instruction file telling the AI when this workflow applies, what to read first, and the order for finishing the work. It may also contain layout templates, checklists, and small file-processing programs. Next time the same kind of task appears, the AI can use the method that already exists.
In the specification, that core instruction file is named SKILL.md. It opens with the skill name and a short statement of purpose, then spells out the working method in plain language. If extra material is needed, reference files, scripts, and assets can live separately and be linked from the instruction file. Editors can read the workflow. Developers, meanwhile, can keep expanding the automated pieces.
This setup gives teams a way to capture know-how that usually stays unwritten. A line like “charts should be readable on mobile” is fuzzy. Rewrite it into a minimum font size, information density per chart, preview dimensions, and a checking method, and you have a much better shot at consistent output. Simple as that. Whether a skill package works well depends a lot on whether experience has been converted into requirements that can actually be acted on.
The article also says completion standards need to be preserved. In an editorial workflow, review may start only after the body text hits the agreed length, sources can be traced, and images have been inserted and previewed. That gives the AI a way to test whether its own delivery is complete. It also gives users one shared standard for acceptance.
When a team spots new mistakes during use, it can update the same skill package. Then the better method is waiting there the next time the task comes around. For recurring work, that kind of steady revision tends to build up better than random one-off reminders.
A skill can also carry an approved example, like a fully formatted report with notes showing where the body text, images, and source files should go. That gives the AI something concrete to look at while it works, and it helps human reviewers spot the moment output starts drifting. The article adds one warning: examples should be cleaned first so client information and outdated facts are removed, leaving only reusable structure and method.
How an AI system finds the right skill
As the skill count grows, another problem shows up. If every instruction is sent to the model for every task, context gets eaten up and irrelevant rules start interfering with the job at hand. Agent Skills uses layered loading instead: the AI first sees the skill name and purpose, then loads the full instructions after it finds a match, and reads related files only if they are needed.
For instance, if a user asks only to “organize unresolved revision comments in a contract,” the AI can first identify the contract review skill without loading rules for cover design, traffic statistics, or invoice sorting. Once it begins the contract task, it can open the relevant templates and clause lists described in that skill.
That matching process rises or falls on whether the purpose description is specific enough. “Handle files” is far too broad. “Organize revision comments in an existing contract and generate a checklist of pending confirmations” is much easier to map to a real use case. In large teams, maintaining the skill library also means combining duplicate skills, removing outdated steps, and making it clear where neighboring workflows split responsibility.
Reference materials need to be broken apart too. Requirements used all the time can stay in the main instruction file. Longer statutes, client templates, or technical documents can be loaded only when needed. That cuts down the time a model spends digging through piles of material and makes it easier to update one section without copying the whole workflow again.
If a workflow has to run scripts, the runtime environment must also offer the right tools. A skill may say a spreadsheet should be turned into a chart, but real execution still depends on an available data-processing program, fonts, and a place to put the output. The skill package describes the method. The platform supplies the conditions for execution. Both have to match before the thing is usable.
Because of that, the article says cross-platform migration is best tried first on a small batch of real tasks. Move the same skill into a different AI tool and you may hit different file paths, available interfaces, approval methods, and output formats. Teams have to record those gaps if they want a skill library that is actually reusable.
What changes when governance moves to AAIF
Agent Skills started inside Anthropic’s product practice. It launched in October 2025 and became an open standard in December of that year. In its latest announcement, Anthropic said more than 70 agent platforms already support the format. The article adds a caveat: that number reflects integrations vendors have publicly disclosed, while real-world performance still has to be judged one task at a time.
As more parties adopt the format, changes to the specification start affecting more teams. The way a field gets interpreted, whether a new version stays compatible with older skills, and whether platforms can tack on their own extensions can all shape workflows enterprises have already built. By moving the project to AAIF, those issues now have a formal home for shared discussion and maintenance.
Anthropic said engineers from multiple companies will join as individuals, with David Soria Parra and Mahesh Murag serving as lead maintainers. Users do not have to become foundation members before using the standard or contributing to it. The project also pointed to future work on release management, a formal proposal process, and security guidance.
For enterprise users, version control jumps out. A skill approved by a team should be able to show which specification version, which template version, and which tools it depends on. If an update breaks things, there should be a path back to the last working version instead of trying to rebuild old requirements from chat history. That matters. A lot.
For platform developers, shared maintenance can reduce duplicated design work. Different platforms can build loaders, validators, and management tools around the same file structure, then keep improving their own product experience on top of it. Existing enterprise workflow materials are also easier to preserve, with migration costs focused on adapting the environment and validating results.
The article says the real impact of standard governance will show up in day-to-day maintenance: who handles issues, how changes get discussed, how security flaws are reported, and how long older versions stay available. As the roadmap turns into actual practice, enterprises can tune their internal update cycles and approval processes around it.
Agent Skills and MCP serve different roles
Another term that keeps coming up in agent infrastructure talk is MCP, short for Model Context Protocol. The article says MCP helps AI applications connect to outside tools and data sources. Agent Skills fits better when the goal is to preserve the steps and experience needed to finish a type of work. The two can be used together on the same task.
Take editorial work again. An AI system can connect to a content repository through tools in order to read articles, while using a skill to decide which sources come first, how verification results should be logged, and when writing should start. One side provides accessible content and operations. The other side organizes how the work gets done.
The same split holds in customer service. Tools can look up orders, read logistics status, and create tickets. Skills can set out what to check first for different issues, how to choose the handling path, and which requests have to go to a human. That lets enterprises update system interfaces and service rules separately instead of turning every process change into a software project.
In legal work, a skill can preserve the order of contract review, clause categories, and the output format for comments. But execution still needs the current contract, applicable law, and client requirements. The article argues that teams need to manage stable methods separately from facts that change from matter to matter, so conclusions from one project do not spill into another.
This matters for knowledge updates too. Effective dates, jurisdictions, and file versions should be stored with the reference materials. When policy changes, maintainers can replace the relevant file and check which skills point to it. For regulatory research and legal service teams, that is easier to control than just piling up huge numbers of documents.
The skill library has an organizational use as well: it lets new staff see how experienced employees get work done. Many workflows used to exist only as personal experience and were passed along by word of mouth. Writing skills down pushes teams to document error-prone steps, exceptions, and acceptance methods for both people and AI.
Permissions, security and external skills
The article says a skill package may include plain instructions, scripts, external links, and tool-calling requirements. Once an AI system selects it, that package can affect file access, data transfer, and real operations. So enterprises need to review both where the content came from and what runtime permissions it gets before importing external skills.
A skill that looks like it only organizes invoices may request access to an entire document directory. A script used for generating reports may connect to an outside server. Reviewers need to know how those permissions relate to the task, whether the scope can be tightened, and where execution logs are kept. Limiting permissions to the files and tools actually required can shrink the damage when mistakes happen.
The article points to OWASP guidance on prompt injection risks, which explains how outside content can change model behavior. When an AI system reads webpages, documents, or other materials, it may run into embedded operational instructions. If the system treats those as trusted requirements, the model may drift away from the user’s original task.
Skill usage runs into the same kind of issue. Teams need to inspect the skill itself and make sure the runtime environment separates work instructions from outside reference material. Actions like making payments, sending emails, or changing production systems should go through proper human review. And file and network permissions should be enforced by the real runtime system, not by text instructions alone.
The specification’s current allowed-tools field is still marked experimental, and support depends on the platform. The article says enterprises can list required tools in the skill description, then verify the actual available scope in platform permission settings and inspect tool-call logs during testing to make sure execution matches the design.
Licensing needs its own review too when external skills are introduced. The specification lets authors fill in a license field or point to a license file, but that field is not mandatory. Teams should confirm how code, templates, and bundled materials may be used, and keep the license text with the relevant version. If the licensing information is missing, they should contact the author before bringing the material into internal workflows.
Updates to external skills should be tracked as well. Teams can pin a reviewed version first, then evaluate updates on a regular schedule. If a skill suddenly adds network access, depends on a new program, or asks for broader permissions, maintainers get a chance to understand the change before it goes live.
Organizations handling large amounts of client material also need to check whether templates and examples inside a skill contain confidential information. If internal experience is being turned into a public skill, client names, contract excerpts, and identity information should be processed first. Public workflows and internal materials can be stored separately to lower the chance of accidentally exposing a full project file.
How enterprises can start building a skill library
The article suggests starting with tasks that are frequent, clearly bounded, and easy to inspect at delivery. Examples include organizing weekly reports, archiving contract comments, generating meeting action items, or preparing article review packages in a fixed format. Writing down the current method first, then letting AI run several rounds, usually exposes problems faster than trying to cover every business process from day one.
When preparing materials, teams can work backward from the latest successful delivery. What was the input? What sources did staff check? What steps were completed? How was the final result judged ready to deliver? Once the real workflow is on paper, error-handling steps can be added to give the skill a more reliable starting point.
Test materials should also include common exceptions: missing contract pages, broken source links, inconsistent spreadsheet fields, or images without authorization records. These cases hit delivery directly. Teams need to see whether the AI can identify the gap, preserve what has already been done, and explain the next step instead of continuing to generate a file that merely looks complete.
Evaluation can stay tied to real workload. How much human supplementation is needed for the same task? Which errors keep coming back? Are the delivered files complete? Do revisions improve stability? Once a small set of representative tasks and results is saved, that same set can be rerun after a skill or model update to see whether the new combination still fits the business.
Maintenance responsibility needs to be explicit too. Who can change steps, who checks legal or business grounds, and who decides when a new version goes into use should all be settled in advance. Skills spanning several departments can keep shared review records. Skills used only for personal organization can use a lighter process.
Teams can also agree on a simple change-log format: what problem showed up in this round, which step changed, and what task was used for validation. That makes it easier for later maintainers to understand why a new requirement was added. Content that has not been used in a long time, duplicates other skills, or depends on tools that have already been retired can be removed during periodic review, so the library does not keep swelling while execution slows down.
When the same skill is used for multiple clients, the article says the general steps and client preferences should be stored separately. The general part defines how work is verified and delivered. The client-specific part records names, formats, and special approval requirements. At the start of a new project, only the relevant client material is loaded. Then updates to the common workflow can be checked against existing projects. That helps keep methods consistent and lowers the risk of using another client’s material by mistake.
After one testing round passes, maintainers can save the skill version, template version, acceptance samples, and known limitations together. The next time the model or tools are updated, they can rerun that sample set and check whether files are complete, permissions are appropriate, and key verification steps were carried out. If differences appear, the team has a clearer route to the part that needs fixing and still keeps a stable version to fall back on.
Disclaimer attached to the original article
The original article says it is provided only for legal, policy, and industry research exchange. It states that the text is meant as an objective analysis of digital finance, stablecoins, digital assets, and related regulatory developments, and does not constitute investment advice, legal advice, tax advice, or any other professional advice. It also says the article does not amount to a recommendation, promotion, or solicitation for any financial product, digital asset, or commercial project.
The article also says the regulatory rules, market data, and institutional information cited are drawn mainly from public materials and may change as laws, regulatory policy, market conditions, and project progress evolve. Readers are asked to make their own judgments based on the latest public information and comply with the laws and regulations that apply in their own country or region. The author and publishing platform say they do not accept responsibility for investment, trading, or other business decisions made in reliance on the article.
The final disclaimer reads: “Markets carry risk, and investing requires caution. This article does not constitute investment advice. Users should consider whether any opinions, views, or conclusions in this article fit their own specific circumstances. If they invest on that basis, they bear the responsibility themselves.”
