How A3IP relates to neighboring standards in the AI-agent ecosystem.
A3IP is a package format and install protocol for portable AI agent workflows. Several adjacent standards address pieces of the same problem space — skill description, dependency resolution, runtime tool calls, plugin distribution. This document explains how A3IP relates to each, what’s complementary versus competitive, and where the integration points are.
The framing throughout this document: A3IP composes with these standards, it does not replace them.
Cowork Plugins are Anthropic’s first-party packaging surface for the Cowork desktop product. A plugin bundles skills, connectors, slash commands, sub-agents, and MCP integrations into an installable unit. Plugins are loaded by Cowork’s plugin system, distributed through Anthropic-governed channels, and run inside Cowork’s runtime.
Where A3IP and Cowork Plugins overlap. Both formats let an author package a multi-component AI workflow as a single installable unit, both pre-declare dependencies, both support skill-shaped contents, both let an install AI (or installer UI) walk the user through setup. The packaging discipline is the same: bundle the workflow so a recipient can install it cleanly without manual file-shuffling.
Where A3IP differs. A3IP is cross-platform by design. The same
.a3ip.bundle installs identically on Cowork, Claude Code, Codex, or
Cursor; runtime-specific install mechanics live in adapter files
inside the package. A3IP also adds explicit permission
declarations (every filesystem path, network domain, MCP server,
and shell command pre-declared in the manifest, presented to the user
as an install plan before any side effects fire) and a normative
uninstall protocol with per-key data-preservation policy. Cowork
Plugins handle these implicitly via the Cowork UI and Anthropic’s
trust model; A3IP makes them explicit so the same package can install
safely on any compliant AI runtime.
Where A3IP and Cowork Plugins compose. An A3IP package targets
Cowork as a first-class runtime — the adapters/runtime/cowork/
folder in every A3IP package contains the platform-knowledge an
install AI needs to install correctly into Cowork (Personal Skills UI,
mcp__cowork__create_artifact, the .skill zip flow). A planned
a3ip export --format cowork-plugin adapter will allow an A3IP
package to be repackaged for distribution through Cowork’s plugin
marketplace, retaining the A3IP manifest as the source of truth and
generating the Cowork plugin metadata as a derived artifact. The
direction is intentionally one-way: A3IP is the broader contract,
Cowork Plugins are a derived target.
Adapter status: authored. The Cowork runtime adapter is included in every A3IP package as part of Creator v3.0’s bundled templates.
APM specifies what agent context to load — which prompts, which context blocks, which dependencies. It’s positioned as the “npm for agents”: a way to declare dependencies between agent contexts and resolve them at runtime.
Where A3IP and APM overlap. Both declare external dependencies (APM context blocks, A3IP MCPs / tools / other skills), both support a manifest-based declaration of what’s needed, both can be consumed by an AI runtime to compose a working agent.
Where A3IP differs. APM solves the dependency resolution problem; A3IP solves the install protocol problem. APM specifies what to load; A3IP specifies how to set it up on a specific machine, with this user’s secrets, against this user’s tools. A3IP adds: a CONFIGURE.md wizard the install AI walks the user through, an INSTALL.md the AI follows step by step, a permissions block the user confirms before anything runs, and a normative uninstall protocol.
Where A3IP and APM compose. An APM context block can live inside
an A3IP package as a dependency — declared in manifest.yaml under
dependencies.apm: (proposed for spec v1.11). The install AI then
fetches the APM context as part of its install plan, after the user
has confirmed permissions. An A3IP export --format apm adapter is
planned for the inverse direction.
Adapter status: planned. The export adapter is on the v1.11 spec roadmap.
SKILL.md is the open standard for describing a single skill’s invocation contract: a markdown file with frontmatter declaring the skill’s name, description, trigger phrases, and tool requirements, followed by the procedure the AI follows when the trigger fires.
Where A3IP and SKILL.md overlap. Every A3IP skill is a SKILL.md
file. The standards are compatible by design — A3IP adopts SKILL.md
exactly as the skill component format. An existing SKILL.md file can
be dropped into an A3IP package’s components/skills/<name>/SKILL.md
slot and shipped without modification.
Where A3IP differs. SKILL.md describes a single skill; A3IP packages a complete workflow that may include multiple skills, artifacts, protocols, prompts, and scripts. SKILL.md says nothing about how the skill gets onto a user’s machine in the first place; A3IP is the install protocol that delivers it. SKILL.md doesn’t declare external dependencies, configuration keys, or permissions; A3IP does.
Where A3IP and SKILL.md compose. A3IP is a strict superset of SKILL.md. The platforms that support SKILL.md (Claude Code, Codex, Cursor, GitHub Copilot, Windsurf) automatically support the skill component inside any A3IP package — the runtime adapter just copies the SKILL.md into the platform’s skills directory and the existing SKILL.md infrastructure does the rest.
Adapter status: native. SKILL.md is A3IP’s primary skill format; no adapter needed.
MCP is the wire protocol an AI uses to call external tools at runtime: filesystems, databases, APIs, third-party services. MCP defines a JSON-RPC contract between an AI client and an MCP server; servers expose tools (functions the AI can call); the client invokes them during a session.
Where A3IP and MCP overlap. Both involve external integrations the AI needs to talk to. Both declare those integrations in a machine-readable form.
Where A3IP differs. MCP is a runtime wire protocol. A3IP is
a packaging format. They operate at completely different layers:
A3IP packages declare which MCPs the workflow requires in
manifest.yaml under dependencies.mcp:, but A3IP itself does not
implement MCP. The install AI uses A3IP’s manifest to verify
the required MCPs are connected, configure them if missing
(prompting the user during INSTALL.md), and then the workflow runs
against those MCPs at runtime via MCP’s own protocol.
Where A3IP and MCP compose. An A3IP install plan typically includes “verify MCP X is connected, prompt user to install if missing.” A3IP adds the missing layer above MCP: the user-confirmed install of the workflow that uses MCPs, with permissions pre-declared. The two are complementary — A3IP makes MCP installs auditable; MCP makes A3IP workflows useful.
Adapter status: native. MCP dependencies are declared in the
manifest’s dependencies.mcp: block; no separate adapter needed.
| Standard | What it does | A3IP relation | Adapter status |
|---|---|---|---|
| Cowork Plugins | Packaging + install for Cowork-native plugins | Cross-platform sibling; A3IP packages target Cowork first-class | Authored (cowork runtime adapter) |
| Microsoft APM | Agent context dependency resolution | Composes — APM context blocks as A3IP dependencies; A3IP adds install layer | Planned (v1.11 spec roadmap) |
| SKILL.md | Single-skill invocation contract | Superset — A3IP adopts SKILL.md as native skill component format | Native |
| MCP | Runtime wire protocol for AI-tool calls | Composes — A3IP declares MCP dependencies; MCP delivers them at runtime | Native |
For clarity, A3IP does NOT aim to compete with or replace:
A3IP’s contribution is the install protocol layer — manifest with explicit permissions, CONFIGURE.md wizard, INSTALL.md plan, user confirmation gate, normative uninstall flow, plain-text bundle format, cross-runtime portability via adapter files. Existing standards remain valid inside A3IP without modification.
A3IP is an independent open standard and claims no affiliation with or endorsement by any of these organizations. Compatibility with these standards is technical, not contractual.
A3IP Specification v1.10 · © 2026 Maksym Prydorozhko · a3ip.dev