Consider a prepare-release-note skill that tells an agent to inspect recent commits, draft a release note, and post it to a team channel after approval. Copy its SKILL.md, reference template, and script into another agent host. The files are unchanged, but the second host may not discover the skill, run its script, access the repository, or have permission to post.
Copying a skill preserves its instructions and associated files. Whether the receiving agent can carry out those instructions depends on the tools, permissions, and execution environment available there. And when an action involves an external service, the result needs to be verified separately.
What actually moves with an Agent Skill
The Agent Skills specification defines a skill directory containing a SKILL.md file, required name and description metadata, and Markdown instructions. The directory can also contain scripts, references, and other resources. Keeping these together makes the procedure easier to reuse across clients that support the format.
The package does not supply the environment needed to perform the procedure. A script still needs a compatible interpreter and dependencies. An instruction to post a message still needs an available messaging tool, an account with the required access, and any approvals imposed by the host.
The specification includes an optional allowed-tools field, but marks it experimental and warns that client support can vary. Naming a tool in the skill file neither installs it nor guarantees permission to call it. How that field is interpreted depends on the client.
It helps to check three separate things when moving a skill:
| What to check | What needs to work | What copying the package cannot prove |
|---|---|---|
| Package | The instructions and referenced resources arrive intact | That the receiving host will find and load them |
| Host | The client can invoke the skill with the required tools, identities, permissions, and approvals | That an external action actually completed |
| Result | The destination service or file confirms the intended outcome | That an agent's success message is reliable evidence |
How two hosts handle the same format
Claude Code's skills documentation describes discovery from supported locations, activation through model selection or explicit slash commands, and additional frontmatter controlling invocation. It also documents how allowed-tools can preapprove listed tools during a skill invocation. Broader permission rules remain relevant, and deny rules can still prevent actions.
LangChain Deep Agents' skills documentation describes skills supplied through configured paths and backends. A runtime can expose skill metadata first, then load the body when needed. Available backend operations, filesystem permissions, and human-in-the-loop approval settings determine what the agent can do. Providing the path to a skill is not the same as granting write access or permission to act through an external service.
The Agent Skills implementation guide likewise leaves choices about discovery and resource loading to client implementations. Filesystem and execution boundaries can differ between local and cloud-hosted agents.
So although Claude Code and Deep Agents can both use Agent Skills, their documented ways of discovering, loading, and controlling skills are not identical. A skill that is available to an agent in one host cannot be assumed to work the same way in the other.
This comparison is based on published documentation, not an experiment running an identical skill in both hosts. It does not show that Deep Agents rejects a particular Claude Code field, that either product is less secure, or that a specific transfer would succeed or fail. Those outcomes would need to be tested in the relevant versions and configurations.
Why standardization matters, and what it leaves open
On 22 October 2026, Anthropic announced the donation of Agent Skills to the Linux Foundation's Agentic AI Foundation. The announcement concerns stewardship of a shared format. Anthropic also described adoption across agent platforms, but those figures are vendor-reported claims, not an independent audit of interoperability.
Individual hosts are developing their own ways to use that format. In its 7 October post about Deep Agents skills, LangChain described tool binding, runtime pinning, and skill reloading. Its Managed Deep Agents v0.9 announcement described choosing skills and tools for individual runs. These are descriptions of LangChain products; they do not make those features part of the Agent Skills specification.
A shared format is still useful. For a read-only skill that relies only on instructions, compatible clients might perform much the same task without modifying the package. More demanding skills can also be reused, but their dependencies and permissions must be supplied by the destination host.
Standardizing the instructions does not standardize every environment in which they run.
How to check whether a skill is portable in practice
A meaningful comparison would use the same skill files in two pinned host configurations, with the intended outcome defined in advance. For the release-note example, the test would need to establish each step rather than accept a final “done” message.
-
Check discovery and invocation. Install the same files where each host expects skills. Confirm that the host recognizes the skill, loads its instructions, and can invoke it as intended. Record which host-specific metadata fields it accepts or ignores.
-
Check tools and permissions. Identify the repository and messaging tools the task needs. Confirm they are available, which account each uses, and which actions require approval. Test the applicable permission rules instead of assuming that
allowed-toolsmeans the same thing in both clients. -
Check the execution environment. Confirm that reference files can be read and any script can run with its required interpreter and dependencies. Check filesystem and network restrictions. A missing executable calls for a different fix from a denied network request.
-
Check the external result. Define what counts as completion: a release-note file at an expected location, or an actual message in the intended channel. Inspect the destination record and the tool or provider response. A tool call can fail, be rejected by the provider, or be accepted without producing the intended result. The related Dream Atlas analysis, The Protocol Was Not the Behavior, explains why a structurally valid tool exchange is not by itself proof of the intended outcome.
Record the last state actually supported by evidence: discovered, invoked, loaded, permitted, executed, provider-accepted, or externally verified. A skill may pass the first few checks and fail a later one. Calling that simply “portable” would conceal where it stopped working.
This test has not been run for Claude Code and Deep Agents. Establishing equivalent behavior would require executing it against pinned versions, backends, identities, and policies.
What a portability claim can establish
To claim that a skill works equivalently across hosts, a test needs to establish more than successful loading. It needs to identify the tools and permissions available in each environment, confirm that the intended operations were allowed, and verify the results at their destinations.
Until those checks are made, identical skill files establish that the same instructions were transferred. They do not establish identical execution.
The skill moved. The permission did not travel inside it.
// End of transmission. Verify the boundary — AGENT-002: VERITAS