On October 22, 2026, Anthropic announced the donation of Agent Skills to the Agentic AI Foundation under the Linux Foundation. Anthropic reported adoption across more than 70 agent platforms. Engineers from Anthropic, Google, OpenAI and other companies will maintain the standard as individual contributors. [1]
For businesses investing in AI workflows, this creates an opportunity to reuse procedural knowledge across compatible tools. A skill packages instructions in a SKILL.md file, optionally accompanied by scripts and reference material. However, a portable package does not guarantee identical permissions, execution capabilities or data handling across products.
The commercial decision is therefore more specific than whether to adopt Agent Skills: which workflow should use them, in which runtime, and under whose operational responsibility?
Separate the open format from the execution environment
An enterprise evaluation should distinguish three layers:
- The skill package: instructions, scripts, reference files and dependencies.
- The agent runtime: how the package is loaded, which tools it can call and where code executes.
- The business application: authentication, approvals, transaction handling and operational records.
This distinction prevents an architectural mistake: assuming that support for the same skill format means two products provide equivalent security boundaries.
The format can make instructions reusable. Your implementation must still establish who can invoke them, what information they receive and which actions require approval.
For buyers comparing platforms, request evidence against the intended workflow. A document-generation demonstration does not establish that the same environment can safely operate a deployment pipeline or update customer records.
What to verify in Claude’s API implementation
Claude’s API documentation describes workspace-wide access to custom skills, a managed code-execution environment without external network access or runtime package installation, and explicit version selection. It also states that Agent Skills are outside Zero Data Retention arrangements. These are characteristics of the documented Claude API implementation, rather than universal properties of the open standard. [2]
Before commissioning an integration, translate those characteristics into project decisions:
Access: Decide which teams or tenants may share a skill collection. Review workspace membership and key scope before uploading proprietary procedures.
Dependencies: Inventory what each script requires. Confirm that dependencies are available as pre-installed packages or compatible bundled assets; test the actual environment rather than assuming a developer’s laptop represents production.
Data: Classify the information entering the workflow. Obtain approval for the applicable retention terms before using sensitive documents or operational records.
Change control: Record the tested skill version, its owner and the application release that uses it.
These decisions should appear in the implementation scope. Leaving them until deployment can turn an apparently small automation into an access-control or data-handling redesign.
Review the package before trusting its behaviour
Anthropic’s enterprise guidance distinguishes security scanning available for certain Claude web-product deployments from Skills API uploads, which are not covered by that scanning. Its guidance also calls for reviewing skill contents and evaluating behaviour before deployment. [3]
Treat a skill containing executable scripts as a software dependency. Review the files it reads, the commands it runs, its handling of secrets and any instructions that could redirect the agent away from the approved task.
A useful acceptance test should include:
- A normal request that should activate the skill.
- A related request that should not activate it.
- Missing or malformed input.
- An attempted action outside the approved scope.
- A representative output checked by the workflow owner.
The objective is to establish observable behaviour. A convincing response from the agent is insufficient evidence that the underlying operation completed correctly.
Hypothetical example: deployment diagnostics
Consider a platform team evaluating a skill that prepares canary-release diagnostics.
The intended outcome is a report combining deployment metadata, logs and health indicators. During discovery, the team finds that the proposed script expects direct access to private monitoring endpoints, while the chosen Claude API execution environment cannot make those network calls. [2]
One possible design is to collect an approved diagnostic snapshot through an authenticated application service, then provide that snapshot to the skill for analysis. The application records when the snapshot was collected and which service it represents. The resulting report clearly distinguishes observed evidence from suggested next actions.
The skill can assist with interpretation, while release approval remains with the existing deployment process.
This is a design option, not a universal requirement. Another runtime may offer different connectivity. The evaluation should compare those capabilities against the organisation’s access and data requirements before selecting an architecture.
A practical governance worksheet
Use this worksheet during discovery and supplier evaluation. Complete one entry for each proposed workflow.
Review areaEvidence to collectAccountable ownerDecision to recordUnresolved gap
Business purpose
Intended users, inputs and measurable output
Workflow owner
What the skill may assist with
Ambiguous scope or success criteria
Runtime and dependencies
Tested environment, required packages and tool access
Engineering lead
Supported execution path
Untested dependencies or connectivity
Workspace access
Membership, key scope and tenant boundaries
Platform administrator
Who may access the package
Shared access requiring separation
Data handling
Data classification and applicable retention terms
Data owner
Permitted inputs and exclusions
Approval still required
Release control
Tested version ID, review record and rollback procedure
Release owner
Approved production version
Unreviewed changes
Acceptance
Representative tests and expected outcomes
Product owner
Conditions for launch
Failed or incomplete checks
For the hypothetical diagnostics workflow, an approved entry might specify sanitised log snapshots, no deployment-write permissions, a tested skill version and human review of release recommendations. These are illustrative controls to adapt to the actual system.
Start with a bounded implementation
A suitable first project has a clear owner, accessible test data and an output that a person can verify. Examples include preparing a report from approved records, checking a document against an internal procedure or summarising a diagnostic snapshot.
More consequential workflows need additional design. If an agent can initiate payments, change permissions or deploy software, specify authorisation and recovery behaviour at the application level. Instructions inside a skill should not be the sole control protecting those actions.
Xtreme Systems Solutions can help assess a proposed agent workflow, compare runtime requirements and define a scoped implementation. A technical scoping engagement can produce a workflow map, access and data decisions, acceptance criteria and an implementation estimate—giving buyers a concrete basis for deciding whether to proceed.
Practical takeaways
- Evaluate the skill format and the selected runtime separately.
- Confirm workspace access, dependencies and data handling before uploading sensitive procedures.
- Review executable content and test behaviour against representative requests.
- Track approved versions and assign responsibility for changes.
- Start with a workflow whose output and business value can be verified.