The Landscape & What's Next

After this chapter you can place APM on a grounded map of the still-forming category around it — using the book's four properties (Portability, Reproducibility, Provenance / security, and Governance) as the map's coordinates rather than marketing claims. You will name the shared standards layer APM builds on (SKILL.md, AGENTS.md, MCP), distinguish Agent Plugins from the broader OpenAPM draft, compare APM honestly against gh skill, orthogonalhq/apm, TheLarkInn/aipm, and vercel-labs/skills, and make the adopt / watch / build-around call as a decision about scope and governance, not install ergonomics.

Two evidence baselines. Book 1.2 updates APM's capabilities from 0.23.1 to exactly APM 0.31.0. The competitor entries remain the 2026-07-01 historical snapshot; their versions, feature claims, and counts have not been re-researched for this edition. Treat the map as a map, not a current market verdict.

A young category that has not settled

“Agent context management” is an emerging tool category. APM was introduced on the GitHub Blog in October 2025 (How to build reliable AI workflows with agentic primitives and context engineering) and only reached the microsoft/apm organization in early 2026 (microsoft/apm). A category this young has no settled winner and no frozen interfaces: standards, registries, and even the scope of a package (skills only, or every primitive type?) are still being negotiated in public.

So the responsible closing move for this book is not a prediction of who wins. It is a grounded map: what exists, what each tool optimizes, and where the seams are. The four properties you have carried since Chapter 1 are the map's coordinate system. The honest way to compare two agent-context tools is not “which install command is shorter,” but which of the four properties each one actually delivers, and across how many primitive types. That reframing is this chapter's whole job.

Keep the distinction between a map and a prediction in view. A market report ranks vendors and forecasts share; a grounded map plots tools against stable axes so you can locate your own need on it. The goal is that you leave able to place a new tool you meet next year — not to memorize today's leaderboard.

The standards layer underneath the tools

Beneath the competing command-line tools sits a shared standards layer that most of them build on. APM's own framing is that it is “built on open standards” (APM 0.31.0 README) — it does not compete with these formats, it consumes and composes them:

• SKILL.md / Agent Skills (agentskills.io) — the community format for packaging a reusable skill. APM implements it for its skill primitive.
• AGENTS.md (agents.md) — the shared convention for the agent instruction file. APM builds on it as a foundation; the standard's own site is the authority on its stewardship, not the package manager.
• MCP — the Model Context Protocol for tool and data servers (modelcontextprotocol.io). APM declares and governs MCP servers as a primitive rather than reinventing them.
• Agent Plugins 1.0 — a plugin-container schema, with a root plugin.json, skills, and MCP configuration in APM's opt-in implementation. Its 1.0 version does not mean APM or OpenAPM has reached 1.0, nor that every harness can load the same plugin. See the format and native-host boundary below.
• OpenAPM v0.1 (the target-tag OpenAPM spec) — Microsoft's own broader bid. Where SKILL.md standardizes one primitive, OpenAPM tries to standardize the whole manifest + lockfile + policy triad (apm.yml, apm.lock.yaml, apm-policy.yml), dependency resolution, and the primitive type system. It remains an editor's Working Draft with no backward-compatibility guarantee before v1.0. It treats the implemented registry HTTP API as informational in v0.1 and reserves a normative wire contract, publisher signing/attestation, and version withdrawal for v0.2. That is a specification boundary, not a claim that registry implementation is absent.

Hold two distinctions apart, because the rest of the chapter leans on them. First, standard vs. tool: a spec (SKILL.md, OpenAPM) defines a format; a tool (APM, gh skill) implements one. Second, narrow vs. broad: SKILL.md standardizes a single primitive (the skill), while OpenAPM describes the packaging system across multiple primitive types. That makes SKILL.md and OpenAPM not rivals for one slot but two live bids at different scopes — a broad spec that can consume the narrow one. The open question is convergence: whether the broad spec absorbs or aligns with the shared narrow one over time. That is something to watch, not to bet on.

The standards layer is also why the properties are possible at all. Shared formats are what make Portability real: a skill written to SKILL.md or an instruction file written to AGENTS.md moves across harnesses because the format is shared, not the tool — provided the receiving harness supports it. OpenAPM applies shared formats to Reproducibility (the lockfile) and Governance (the policy file). A draft contract makes interoperability possible; it does not certify every implementation or runtime.

Where APM sits on the map

APM's distinctive position has two halves, and honesty requires stating both. The first half is its strength: mixed-context management plus install-time governance. The vocabulary from Chapter 3 includes instructions, prompts/commands, skills, agents, MCP servers, and harness hooks, alongside plugin packages that contain components. APM connects those to a manifest, a lockfile, and apm-policy.yml (Chapter 9). This is broader scope than moving a skill alone, but not a promise that every component has the same deployment, audit, or execution semantics on every harness (package layouts; target matrix).

A concrete example is Agent Plugins 1.0: the opt-in agent-plugin output carries skills and MCP, not Meridian's complete instruction + prompt + skill package. Packing that package in this format is rejected rather than silently discarding its instructions and prompt. The default bundle remains Claude-compatible; the plugin format alias does not select Agent Plugins. Recognized Agent Plugins stay whole under apm_modules for native Copilot registration, rather than being flattened into loose primitives. Loading that registration requires Copilot CLI 1.0.81 or newer; APM need not locate or execute Copilot to register it. Other targets are outside this native route (native consumer contract). Use Chapter 10's format choices and native replay caveat, not a wholesale migration of Meridian's package.

The 0.31.0 target catalog includes Grok Build and Kiro agent support; Hermes is stable but explicit-only, not auto-detected or included in the default all expansion. Grok Cloud remains experimental. Catalog support is not a runtime compatibility test. Meridian still uses Copilot, Claude Code, and Cursor: portability means the same declared intent in supported native forms, not identical files or runtime behavior.

Implemented registries, hosted discovery, and draft standards

The second half is the distribution choice. Git remains the default and needs no central APM service, but APM 0.31.0 ships experimental REST registry consumption and publication. Its implementable HTTP API v1 describes version listing, archive download, and publication. You need an actual compatible backend and the experimental feature enabled (registries guide). Neither the client nor that API is evidence of a Microsoft-operated public searchable hub; the API does not define a search endpoint. Nor does its v1 label deliver the normative OpenAPM v0.2 work reserved by the draft.

Why discovery is not the management core

Here Chapter 2 pays off. The registry is the most optional part of a package manager; the load-bearing parts are the manifest (declared intent) and the lockfile (a pinned result you can check). Git sources can supply the same management core without a public hub. In the supported configurations taught here, a team gets Portability from the manifest and target selection, Reproducibility from the lockfile (Chapter 6), Provenance / security from content-hash pinning and scanning before agent-readable deployment (Chapter 8), and Governance from policy (Chapter 9) — none of which needs a public index. The cryptographic hashes detect changed bytes relative to trusted metadata; they are not publisher signatures or proof of benign content (security boundaries).

The clean line to draw is discovery versus management, not “registry absent versus present.” Git sources, a marketplace catalog, a transport proxy, a REST package backend, and an offline bundle solve different problems. A proxy does not become a discovery index, and a catalog is not the REST server. Follow Chapter 10 for distribution formats and Chapter 11 for their operational boundaries rather than treating any one as a substitute for the others.

Read roadmap evidence as planning. The target-tag project governance document points to an active, issue-backed public roadmap: issues carry scope and evidence, Now / Next / Later horizons express priority, and milestones group plausible release cohorts. Placement is neither implementation approval nor a delivery guarantee. This is contributor planning, not the enterprise apm-policy.yml engine, and it does not turn OpenAPM v0.2's reserved work into a promised release.

The tools, side by side

Several tools overlap with APM, and none of them is a strawman. The historical research mapped different choices of primitive scope, discovery, and governance. Read the table below as “which properties, over how many primitive types” — not “which install command is shortest.”

Mapped onto the four properties, the useful distinction is scope. Portability for one skill is not the same requirement as projecting a mixed package onto several targets. Reproducibility asks what identity and content each tool records and can restore, not merely whether it has a file called a lock. For Provenance / security, the historical gh skill announcement describes immutable releases and tree-SHA checks (April 2026 changelog); APM provides hash-based integrity and install-time scanning, not publisher signing. For Governance, evaluate APM's explicit policy contract against your organization-wide requirements, without inferring a current market ranking.

When a narrow installer is enough — and when it isn't

They do not all do the same thing, so “pick the one with the nicest CLI” hides the difference that actually matters. Use the scope of your need to decide:

• A narrow skill installer is plenty when an individual workflow only needs skills and values discovery or source provenance. The historical entries illustrate those choices: gh skill's GitHub-native provenance, orthogonalhq/apm's searchable index, and vercel-labs/skills' cross-agent skill focus. A skills-only tool cannot express a project's prompts, instructions, agents, and MCP servers as one governed, locked dependency graph, but if you never needed that graph, the ceremony would be overkill.
• You need the full manifest / lockfile / policy / audit story when context is shared, plural, and answerable to someone — a regulated or multi-team context where “which agent configuration was active at release 4.2.1?” must have an answer, and where an organization decides which sources and MCP servers are allowed. That is APM's coverage, and it is the shape Meridian has been building toward for eleven chapters.
• “Build around” is the middle path when you want APM's management contract and have a specific gap: an internal catalog for discovery, a proxy for approved transport, or an operated compatible REST backend. They are different investments, not synonyms for “registry.” Use Chapter 10's distribution guidance and Chapter 11's infrastructure boundaries; do not make the plan depend on an assumed public-hub launch.

The same historical map includes adjacent projects rather than head-to-head managers: anthropics/skills as a SKILL.md reference implementation and content library; and the MCP Registry and Smithery as MCP-server indexes, not APM package registries. Keep those roles distinct.

A different relationship: tools that consume APM

Not every neighbour on the map is a rival. One useful relationship is a consumer: GitHub Agentic Workflows (gh-aw), which compiles markdown workflows into GitHub Actions jobs. The rivals above answer “should I use APM or something else to manage context?” gh-aw answers the question that comes after that one: once context is managed, who runs it? Its execution layer is independent of APM. The shared integration uses microsoft/apm-action to install imported packages, pack a bundle, and restore it before the agent starts (0.31.0 integration guide).

shared/apm.md is a local, vendored import, resolved at .github/workflows/shared/apm.md, not a remote uses reference. For this baseline, use the canonical file at the frozen APM tag, then recompile with a separately reviewed gh-aw compiler. Re-vendoring and recompilation are separate from upgrading the CLI. A Copilot workflow must pair engine: copilot with target: copilot under the import's with:; the shared file rejects all. It still defaults to APM 0.28.0 and selects microsoft/apm-action v1.10.0. To select this book's baseline, explicitly set apm-version: '0.31.0', which reaches both pack and restore. Those pins define the intended combination; they do not prove compatibility.

The import runs isolated with its own manifest and resolved package set. Only its declared packages: supply context; the host repository's apm.yml, apm.lock.yaml, and local primitives are not automatically imported. Pin the imported sources and inspect the resulting bundle rather than claiming the host lockfile governs it. Host policy is not automatically carried over either: establish the policy authority available to the isolated job. For imports without GitHub App credentials, the optional token-source: github-token selects read-only access to private content in the current repository, not other private repositories. For a workflow that intentionally consumes the host manifest, the frozen upstream integration guide describes an apm-action pre-step alternative. That is source-only guidance requiring separate integration validation, not a verified recipe here or an assumption about this isolated import.

Through the four properties, APM is still the context layer: Portability for supported projections, Reproducibility for the imported graph and bundle, install-time Provenance / security, and Governance when the relevant policy is enforced. gh-aw owns workflow execution, sandboxing, and the separation of model activity from permissioned write steps. Those controls reduce risk; they do not make prompt injection impossible. GitHub's Well-Architected guidance explains the complementary roles, not a transfer of runtime safety responsibility to APM.

Recap — the whole arc

This book made one wager: agent context is where application code was before npm, pip, and Cargo — scattered, drifting, “works on my machine.” Every chapter added one layer, and each layer protected one of the four properties:

• Portability — the apm.yml manifest and harness targets (Chapters 4–5) turned Meridian's four scattered per-harness files into one declared source of truth.
• Reproducibility — the apm.lock.yaml lockfile (Chapter 6), forced by a CI break, made locked source identity and restore checks reviewable; Chapter 7 made change deliberate.
• Provenance / security — scanning, content-hash checks, and transitive-MCP admission rules (Chapter 8) checked deployable content and kept an undeclared transitive server out of the agent's configuration. They did not certify runtime safety or publisher identity.
• Governance — apm-policy.yml (Chapter 9) and its warn → block rollout, then fleet-scale ownership and CI gating (Chapter 11), turned rules-in-heads into an enforced, owned contract — after Meridian crossed the ramp to publishing meridian-standards (Chapter 10).

And this chapter turned those four properties into a yardstick: a grounded map of a young category, where APM is a mixed-context, policy-carrying, Git-first option with experimental REST registry support — the make-vs-adopt call reframed as scope and governance, not install UX. The Chapter 2 name collision still matters; so does distinguishing shipped implementation, draft standards, hosted services, and planned work.

Open questions

This is the last chapter, so there is no next one — the “next” is yours. The category is still settling, and the honest close is a set of open questions to carry into your own adoption, not a sales pitch:

• Which registry ecosystem can your team depend on? The experimental client and implementable API exist. A usable hosted discovery service, a normative wire standard, publisher attestations, and version withdrawal are separate questions — not all answered by that implementation (OpenAPM's status and reserved scope).
• Do the standards converge or fragment? Whether the broad OpenAPM bid aligns with SKILL.md and Agent Plugins formats without losing primitives or trust information will shape which packages stay portable across tools. A shared schema alone does not prove native runtime compatibility.
• Does the category consolidate? Whether one broad standard emerges or the space splinters across narrower installers remains an open question. The competitor map here is still the 2026-07-01 historical snapshot; updating APM to 0.31.0 does not supply new evidence about the rest of the market.

Your move is the one Meridian made: adopt APM for the contract you can verify now — the manifest, the lockfile, policy, and your own internal packages on the Git-first path — while you watch services and standards, build around specific operational needs, and guard against installing the wrong “apm.” Start where the drift hurts most (microsoft/apm, the docs), declare one manifest, and carry the open questions above into your own adoption: what will you standardize now, and what will you require evidence for next quarter?