The Missing Layer: Why Your AI Agents Need a Package Manager

The dependency nobody is managing

Here's something that should bother every engineering leader deploying AI coding agents: your developers are all using different ones.

Not different models. Different configurations. Different instructions. Different skills. Different MCP servers. Different hooks. Different rules about what the agent should and shouldn't do.

One developer has a carefully tuned CLAUDE.md with coding standards, security guardrails, and domain-specific knowledge. The developer sitting next to them has a bare default. A third copied a configuration from a blog post three months ago and hasn't updated it since. Your newest hire has nothing at all.

This is the dependency management problem of 2015, replaying in fast-forward. We've seen this movie before. And Microsoft just shipped an open-source tool that solves it the same way npm and NuGet solved it for code: APM (Agent Package Manager). One manifest. Transitive resolution. Lock files. Reproducible agent configurations across your entire org.

Before I walk through what APM does and why it matters, it's worth understanding the pattern it's built on — because this isn't a new problem. It's a solved problem being applied to a new domain.

We solved this problem 15 years ago (for code)

Software engineering went through an identical maturation cycle with code dependencies. The timeline is instructive.

In the early days, developers managed libraries by hand. You'd download a JAR file, drop it in a /lib folder, and pray that everyone on the team had the same version. It worked for small teams. It collapsed at scale. Version conflicts. Missing transitive dependencies. The infamous "works on my machine" problem that consumed entire sprints.

Then package managers arrived. npm for JavaScript. pip for Python. Maven for Java. NuGet for .NET. Cargo for Rust. Each brought the same core innovation: declare your dependencies in a manifest, resolve them automatically, lock versions for reproducibility. package.json. requirements.txt. Cargo.toml. Different ecosystems, identical principle.

The effect wasn't incremental. It was foundational. Package managers didn't just save time. They made entire categories of problems disappear. They enabled open-source ecosystems to scale from dozens of libraries to millions. They made CI/CD pipelines possible by guaranteeing build reproducibility. They turned "dependency management" from a skill into a solved problem.

AI agent configuration is sitting right where code dependencies sat before package managers arrived. Manual setup. Configuration drift. No version pinning. No transitive resolution. No reproducibility guarantees. No security scanning.

The only difference is the speed. Code dependency management took a decade to mature. Agent configuration needs to get there in months, because the adoption curve is steeper and the blast radius of a misconfigured agent is larger than a mismatched library version.

Enter APM

Microsoft's Agent Package Manager is an open-source project (MIT licensed, 710+ stars, 33 releases as of March 2026) that applies the package manager pattern to AI agent configuration. The creator, Daniel Meppiel, a Software Global Black Belt at Microsoft, built it on a straightforward premise: if package.json works for code dependencies, apm.yml should work for agent dependencies.

The comparison is more than metaphorical. APM implements the same lifecycle that made code package managers transformative:

Declare. Your project's apm.yml specifies what your agents need. Not how to configure them manually, but what packages of configuration to install.

name: my-enterprise-project
version: 1.0.0
dependencies:
  apm:
    - org/coding-standards
    - org/security-guardrails
    - org/api-review-skill#v2.1
    - anthropics/skills/skills/frontend-design

Resolve. apm install pulls packages from any git host (GitHub, GitLab, Bitbucket, Azure DevOps, GitHub Enterprise), resolves transitive dependencies, and places files in the correct directories.

Lock. apm.lock.yaml pins every dependency to an exact commit. The same lock file produces the same agent configuration on every machine, every time.

Compile. A single manifest generates native configuration files for multiple tools. AGENTS.md for Copilot. CLAUDE.md for Claude Code. .cursor/rules/ for Cursor. One source of truth, many deployment targets.

Distribute. apm pack bundles resolved dependencies into portable artifacts that work without APM, Python, or network access. This covers CI pipelines, air-gapped environments, and dev container setups.

This isn't a prototype. APM is at v0.8.4 with 18 contributors, 772 commits, and a GitHub Action for CI integration. It's built on established open standards: the AGENTS.md specification (a Linux Foundation AAIF founding project alongside MCP), the Agent Skills framework, and the Model Context Protocol.

Seven primitives, one manifest

APM manages seven types of agent configuration that together define how AI coding agents operate in your codebase:

Instructions are coding standards and guardrails scoped to file patterns. A Python standards instruction applies only to **/*.py files. A security policy applies everywhere. These replace the ad-hoc "paste your coding standards into the system prompt" approach that most teams use today.

Skills are reusable AI capabilities: code reviewers, form builders, deployment assistants, security scanners. If you've read my previous article on Agent Skills as the missing link, this is the distribution mechanism that was absent. APM makes skills installable, composable, and version-pinned instead of manually copied between repositories.

Prompts are slash commands for common tasks. /review, /deploy, /test. Standardized across the team instead of each developer inventing their own.

Agents are specialized personas with defined roles, tools, and behavioral boundaries. Your security review agent. Your architecture advisor. Your documentation generator.

Hooks are lifecycle event handlers that fire on specific triggers: before a commit, after a file edit, on session start. These automate quality gates and organizational workflows.

Plugins are pre-packaged bundles that combine multiple primitives into a single installable unit. Think of them as meta-packages.

MCP Servers are external tool integrations that give agents access to databases, APIs, file systems, and other services through the Model Context Protocol.

Without APM, configuring all seven of these for a new developer on your team is a multi-hour manual process that nobody documents and everyone does differently. With APM, it's git clone && apm install.

The problem that's hiding in plain sight

Most organizations don't realize they have an agent configuration problem because they haven't tried to standardize yet. The moment you do, the scale of the issue becomes obvious.

Imagine a financial services firm with 200 developers using AI coding agents. Some teams use Claude Code. Others use Copilot. A few use Cursor. Each team has its own coding standards, security requirements, and compliance guardrails. Some teams have encoded these into their agent configurations. Most haven't.

Without a dependency manager, you're left with two options. Option one: a wiki page titled "How to Set Up Your AI Agent" that's perpetually out of date and that new hires follow maybe half of. Option two: a senior engineer spends an afternoon with each new team member walking them through the setup, which means the configuration is as good as that engineer's memory on that particular day.

Neither option scales. Neither option is auditable. Neither option gives you confidence that the agent writing code for your regulated application has the same security guardrails as the agent that passed your last compliance review.

APM's lock file changes this equation. apm.lock.yaml is a diffable, version-controlled artifact that proves every developer on your team is running the same agent configuration. When your compliance team asks "how do we know the AI agents are following our security standards?", you show them the lock file.

Supply chain security for agent configuration

Here's where it gets serious. AI agent configurations aren't just preferences. They're instructions that shape what code gets written, what security patterns get followed, and what guardrails get applied. A compromised agent configuration is a supply chain attack on your entire codebase.

APM includes apm audit, which scans packages for hidden Unicode vulnerabilities and blocks compromised configurations before they reach your agents. This is the agent equivalent of npm audit or GitHub's Dependabot alerts. It's table stakes for any organization that takes software supply chain security seriously.

CIO.com recently identified AI agent versioning as "the CIO's next big challenge," noting that "a minor API update could significantly alter an agent's behavior, even if the agent's core logic remains unchanged." The article recommended treating agent versioning as "a first-class discipline" alongside traditional software release management.

APM makes that recommendation actionable. Version pinning. Lock files. Auditing. Reproducible builds. These aren't new concepts. They're proven infrastructure patterns applied to a new domain.

Where this fits in the agent-first enterprise

Throughout this series, I've argued that the organizations seeing transformational results with AI aren't just using agent tools. They're building infrastructure around agent capabilities.

Skills gave us composable, portable organizational knowledge. MCP gave us a standard protocol for connecting agents to external tools. Progressive disclosure solved the context window scaling problem.

APM is the layer that was missing between all of these. It's the composition and governance infrastructure that answers questions the other standards don't address:

• Which skills should this project use? (Declared in apm.yml)
• What version of those skills? (Pinned in apm.lock.yaml)
• Are all developers using the same setup? (Reproducible via apm install)
• Are the configurations safe? (Verified via apm audit)
• How do we distribute this to new team members? (Automated via apm pack)

The progression looks like this: first you adopt agents, then you customize them with skills and MCP servers, then you realize you need a way to manage and distribute those customizations consistently. APM is what you reach for at that third step.

What to do this week

If you're already using AI coding agents in your organization:

Start by auditing what you have. How many different agent configurations exist across your teams? Are coding standards encoded in those configurations? Security guardrails? If you can't answer these questions, you've confirmed the problem.

Install APM. It takes less than a minute. On Windows: irm https://aka.ms/apm-windows | iex. On Mac/Linux: curl -sSL https://aka.ms/apm-unix | sh. Run apm init in a project to see the manifest structure.

This month:

Pick one team as a pilot. Have them declare their existing agent configuration in apm.yml, including their coding standards, security rules, and any skills or MCP servers they've configured manually. Install from a shared git repository so the entire team gets the same setup.

Track two things: time saved on new developer onboarding, and the number of configuration inconsistencies you discover during the migration. Both numbers will surprise you.

This quarter:

Build an organizational package library. Your coding standards. Your security guardrails. Your compliance requirements. Your domain-specific skills. Publish them to internal git repositories that any team can install from. Establish a review process for changes to these packages, the same way you review changes to shared libraries.

Integrate apm audit into your CI pipeline. Make agent configuration a first-class artifact alongside your code.

The infrastructure maturity curve

Every technology goes through the same maturation arc. First comes capability: the thing works. Then adoption: people start using it. Then chaos: everyone uses it differently. Then infrastructure: tooling emerges to manage the chaos. Then standardization: the tooling becomes an expected part of the stack.

AI coding agents are somewhere between chaos and infrastructure. The capability is proven. Adoption is accelerating (96% of enterprise IT leaders plan to expand AI agent use in the next 12 months). The chaos is real but largely unacknowledged. The infrastructure is arriving.

APM is one of the first serious attempts to move agent configuration from artisanal to industrial. It won't be the last. But it's built on the right foundations (open standards, proven patterns, multi-tool support), and it's solving a problem that gets worse with every developer you add to your team.

The organizations that figure out agent infrastructure early will compound their advantages over those that don't. That's not speculation. It's exactly what happened with code dependency management, with CI/CD, with containerization, with every infrastructure layer that made software engineering more reproducible and reliable.

Agent configuration is infrastructure. Treat it accordingly.

References

1. Microsoft. "APM - Agent Package Manager." GitHub. github.com
2. Microsoft. "What is APM?" Agent Package Manager Documentation. microsoft.github.io
3. Microsoft. "Pack & Distribute." Agent Package Manager Documentation. microsoft.github.io
4. Raman, NJ. "Why Versioning AI Agents Is the CIO's Next Big Challenge." CIO.com, 2026. cio.com
5. BrightCoding. "AGENTS.md: The Essential Tool for AI Coding Agents." March 2026. brightcoding.dev
6. Kruczek, Matthew. "The Agent-First Enterprise: Why Skills Are the Missing Link." matthewkruczek.ai. matthewkruczek.ai
7. Kruczek, Matthew. "Progressive Disclosure for MCP Servers." matthewkruczek.ai. matthewkruczek.ai

This article is part of "The Agent-First Enterprise" series exploring how organizations can transform their operations around AI agent capabilities. Connect with me on LinkedIn or Substack to discuss agent infrastructure strategy for your organization.

Matthew Kruczek

Managing Director at EY

Matthew leads EY's Microsoft domain within Digital Engineering, overseeing enterprise-scale AI and cloud-native software initiatives. A member of Microsoft's Inner Circle and Pluralsight author with 18 courses reaching 17M+ learners.