Latest in AI
Anthropic Donates Agent Skills to AAIF: What Changes for Developers
Agent Skills gets a neutral home, while the harder work of making portable instructions reliable stays with builders.
Anthropic announced on October 22 that it is donating Agent Skills to the Agentic AI Foundation, or AAIF, under the Linux Foundation. The move changes stewardship of the open standard used to package agent instructions and resources. It does not announce a new Claude model or a replacement skills format.
This matters to teams building workflows across more than one agent. A useful procedure should not have to be rewritten simply because the team changes the product that runs it. A shared format helps, although sharing a file is only the beginning of portability.
What Anthropic is transferring
According to Anthropic's announcement, the donation covers the Agent Skills name and logo, its GitHub organization and the agentskills.io domain. Developers can keep using and contributing to the standard without joining AAIF.
Engineers from Anthropic, Google, OpenAI and other companies will maintain the project as individuals. David Soria Parra and Mahesh Murag are the lead maintainers. The proposed roadmap includes versioned releases, a formal proposal process and security guidance for skill authors and users.
Those are proposed next steps, not features that every supporting agent has already implemented. Anthropic says more than 70 platforms support Agent Skills, including ChatGPT, Cursor, GitHub Copilot and VS Code. That breadth explains why stewardship is becoming a practical engineering question rather than just a branding decision.
What an Agent Skill actually contains
The Agent Skills overview describes a skill as a folder built around a SKILL.md file. The file contains a name, a description and the instructions for a task. Scripts, reference documents and templates can sit alongside it.
A deployment-review skill, for example, could explain which checks to run, where to find the release checklist and how to record exceptions. The instructions would capture the procedure. The surrounding files would supply the details needed to perform it.
Skills load progressively. The agent first sees enough metadata to discover relevant skills, then reads the full instructions when needed and accesses additional resources as the task requires. That keeps every procedure from occupying the conversation context all the time.
The important design choice is deciding what the agent needs for every run and what it can retrieve only when relevant. Putting an entire handbook into the main file makes the package easy to create but harder to use selectively.
Portable files still have environment requirements
The format specification includes an optional compatibility field for requirements such as packages or network access. Its allowed-tools field is experimental, and support can differ between agent implementations.
That gives developers an important boundary: a portable instruction format does not guarantee identical execution. A script that needs a particular runtime will still need that runtime. A workflow that expects a database connection cannot acquire one merely because another agent can read its Markdown.
For a team moving the same review skill between tools, I would keep the procedure separate from environment-specific setup. Test whether each agent finds the right skill, follows the same checks and produces a useful record. A successful file import is a weak test of whether the workflow survived the move.
This also makes versioning valuable. If an instruction changes after a deployment, the team needs to know which version was used, especially when the result differs from an earlier run. The proposed roadmap could make that work easier, but teams still need their own review and testing process today.
Why neutral stewardship matters
AAIF is also discussing the adoption of Open Responses, a shared API contract based on OpenAI's Responses API. Its October 22 explanation focuses on reducing the provider-specific adapters that agent developers maintain.
The two efforts address different parts of the same integration problem. A model API describes how requests and responses travel. A skill describes a procedure the agent can use. Standardizing both can reduce duplicated integration work, but neither determines whether the underlying model chooses the right action.
For technical teams, the useful opportunity is to treat procedural knowledge as something worth maintaining independently of one vendor's interface. Keep the instructions understandable, make dependencies explicit and evaluate them on actual tasks. Then switching agents becomes a controlled engineering change rather than a fresh attempt to reconstruct how the team works.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help technical founders explain agent products, open-source work and launches in ways developers can understand and share.