{"id":23658,"date":"2026-08-30T20:20:30","date_gmt":"2026-08-30T20:20:30","guid":{"rendered":"https:\/\/scannn.com\/agent-package-manager-for-ai-azure-engineering\/"},"modified":"2026-08-30T20:20:30","modified_gmt":"2026-08-30T20:20:30","slug":"agent-package-manager-for-ai-azure-engineering","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/agent-package-manager-for-ai-azure-engineering\/","title":{"rendered":"Agent Package Manager for AI Azure Engineering"},"content":{"rendered":"\n
\n

AI coding tools are getting better quickly. The setup around them is still too often a pile of local files, copied prompts, one-off MCP servers, and tribal knowledge.<\/p>\n

One developer has custom GitHub Copilot instructions. Another has Claude agents. Someone else has Cursor rules. The platform team wants approved Azure patterns, Microsoft Learn grounding, cost guidance, security checks, and repeatable onboarding.<\/p>\n

Six months later, the audit question is simple and uncomfortable:<\/p>\n

\n

What agent context was installed, where did it come from, and who allowed it?<\/p>\n<\/blockquote>\n

Agent Package Manager<\/a>, or APM, addresses that gap.<\/p>\n

APM is a dependency manager for AI agents. The official project describes the core model as declaring the skills, prompts, instructions, plugins, and MCP servers a project needs in one apm.yml<\/code>, then running apm install<\/code> to deploy the supported primitives to each agent harness. It also positions the lockfile as the reproducibility artifact, with exact versions and content hashes, and apm-policy.yml<\/code> as the install-time governance control for dependencies, MCP servers, and targets.<\/p>\n

Agent configuration needs this kind of mundane, reviewable plumbing.<\/p>\n

<\/p>\n

Why this matters for Azure teams\u200b<\/a><\/h2>\n

Azure engineering work rarely happens in one tool.<\/p>\n

A realistic cloud engineering repo might use:<\/p>\n

In my own Coding<\/code> repo, the APM manifest now declares the active agent targets explicitly:<\/p>\n

\n
\n
targets<\/span>:<\/span><\/p>
  <\/span>-<\/span> copilot<\/span><\/p>
  <\/span>-<\/span> claude<\/span><\/p>
  <\/span>-<\/span> cursor<\/span><\/p>
  <\/span>-<\/span> opencode<\/span><\/p><\/code><\/pre>\n<\/div>\n<\/div>\n
It also declares local primitives and reusable agent-skill packages:<\/p>\n
\n
\n
dependencies<\/span>:<\/span><\/p>
  <\/span>apm<\/span>:<\/span><\/p>
    <\/span>-<\/span> DietrichGebert\/ponytail<\/span><\/p>
    <\/span>-<\/span> microsoft\/skills\/.github\/plugins\/azure<\/span>-<\/span>sdk<\/span>-<\/span>python<\/span><\/p>
    <\/span>-<\/span> microsoft\/skills\/.github\/plugins\/azure<\/span>-<\/span>sdk<\/span>-<\/span>dotnet<\/span><\/p>
    <\/span>-<\/span> microsoft\/skills\/.github\/plugins\/azure<\/span>-<\/span>sdk<\/span>-<\/span>typescript<\/span><\/p>
    <\/span>-<\/span> microsoft\/skills\/.github\/plugins\/azure<\/span>-<\/span>sdk<\/span>-<\/span>rust<\/span><\/p>
    <\/span>-<\/span> microsoft\/skills\/.github\/plugins\/microsoft<\/span>-<\/span>foundry<\/span><\/p>
    <\/span>-<\/span> <\/span>\"microsoft\/hve-core#c7ee5b9642ab1877a6b5ce5336ebc448b89b2708\"<\/span><\/p>
    <\/span>-<\/span> dotnet\/skills<\/span><\/p><\/code><\/pre>\n<\/div>\n<\/div>\n
The workflow is familiar: declare dependencies, lock the result, and validate it.<\/p>\n
<\/p>\n
MCP servers are dependencies too\u200b<\/a><\/h2>\n
The part I like most is that MCP servers sit in the same dependency story.<\/p>\n
That matters because MCP is a tool boundary. If an agent gets access to a server, it gets access to whatever that server exposes. For Azure work, that is powerful and useful, but it should never be invisible.<\/p>\n
The repo manifest declares the MCP surface. These are representative entries; the complete manifest is linked in the references.<\/p>\n
\n
\n
dependencies<\/span>:<\/span><\/p>
  <\/span>mcp<\/span>:<\/span><\/p>
    <\/span>-<\/span> <\/span>name<\/span>:<\/span> microsoft.learn.mcp<\/span><\/p>
      <\/span>registry<\/span>:<\/span> <\/span>false<\/span><\/p>
      <\/span>transport<\/span>:<\/span> http<\/span><\/p>
      <\/span>url<\/span>:<\/span> https<\/span>:<\/span>\/\/learn.microsoft.com\/api\/mcp<\/span><\/p>
    <\/span>-<\/span> <\/span>name<\/span>:<\/span> context7<\/span><\/p>
      <\/span>registry<\/span>:<\/span> <\/span>false<\/span><\/p>
      <\/span>transport<\/span>:<\/span> http<\/span><\/p>
      <\/span>url<\/span>:<\/span> https<\/span>:<\/span>\/\/mcp.context7.com\/mcp<\/span><\/p>
    <\/span>-<\/span> <\/span>name<\/span>:<\/span> azure<\/span><\/p>
      <\/span>registry<\/span>:<\/span> <\/span>false<\/span><\/p>
      <\/span>transport<\/span>:<\/span> stdio<\/span><\/p>
      <\/span>command<\/span>:<\/span> npx<\/span><\/p>
      <\/span>args<\/span>:<\/span><\/p>
        <\/span>-<\/span> <\/span>-<\/span>y<\/span><\/p>
        <\/span>-<\/span> <\/span>'@azure\/mcp@latest'<\/span><\/p>
        <\/span>-<\/span> server<\/span><\/p>
        <\/span>-<\/span> start<\/span><\/p><\/code><\/pre>\n<\/div>\n<\/div>\n
This moves MCP from \u201cwhatever is configured on my machine\u201d into the repo contract.<\/p>\n
The manifest declares the active targets and approved MCP servers:<\/p>\n
\"APM-declared<\/p>\n
Governance without ceremony\u200b<\/a><\/h2>\n
I would not start with a giant enterprise policy.<\/p>\n
The smallest useful version is an allowlist:<\/p>\n
\n
\n
name<\/span>:<\/span> Hypervelocity APM baseline<\/span><\/p>
version<\/span>:<\/span> 1.0.0<\/span><\/p>
enforcement<\/span>:<\/span> block<\/span><\/p>
dependencies<\/span>:<\/span><\/p>
  <\/span>allow<\/span>:<\/span><\/p>
    <\/span>-<\/span> DietrichGebert\/ponytail<\/span><\/p>
    <\/span>-<\/span> dotnet\/skills<\/span><\/p>
    <\/span>-<\/span> microsoft\/hve<\/span>-<\/span>core<\/span><\/p>
    <\/span>-<\/span> microsoft\/skills\/<\/span>**<\/span><\/p>
mcp<\/span>:<\/span><\/p>
  <\/span>allow<\/span>:<\/span><\/p>
    <\/span>-<\/span> azure<\/span><\/p>
    <\/span>-<\/span> context7<\/span><\/p>
    <\/span>-<\/span> foundry<\/span>-<\/span>mcp<\/span><\/p>
    <\/span>-<\/span> iseplaybook<\/span><\/p>
    <\/span>-<\/span> microsoft.learn.mcp<\/span><\/p>
    <\/span>-<\/span> microsoft<\/span>-<\/span>docs<\/span><\/p>
    <\/span>-<\/span> microsoft.mrc.mcp<\/span><\/p>
  <\/span>transport<\/span>:<\/span><\/p>
    <\/span>allow<\/span>:<\/span><\/p>
      <\/span>-<\/span> http<\/span><\/p>
      <\/span>-<\/span> sse<\/span><\/p>
      <\/span>-<\/span> stdio<\/span><\/p>
  <\/span>self_defined<\/span>:<\/span> allow<\/span><\/p>
compilation<\/span>:<\/span><\/p>
  <\/span>target<\/span>:<\/span><\/p>
    <\/span>allow<\/span>:<\/span><\/p>
      <\/span>-<\/span> claude<\/span><\/p>
      <\/span>-<\/span> copilot<\/span><\/p>
      <\/span>-<\/span> cursor<\/span><\/p>
      <\/span>-<\/span> opencode<\/span><\/p><\/code><\/pre>\n<\/div>\n<\/div>\n
The policy allowlists dependency sources, MCP servers and transports, agent targets, and required manifest metadata. It is install-time governance, not a runtime sandbox: it enforces declarations before files are written, while runtime behaviour remains with the agent harness and exposed tools.<\/p>\n
<\/p>\n
From one repository to an organisation\u200b<\/a><\/h2>\n
The interesting part of APM is not just what happens in one repository.<\/p>\n
It is what happens when ten, fifty, or five hundred repositories need the same agent engineering baseline.<\/p>\n
An organisation might have separate platform, data, security, application, and AI engineering teams. They should not all have to independently discover the same skills, MCP servers, policies, and agent configuration.<\/p>\n
The model can instead be layered:<\/p>\n
\n
\n
                         GitHub Organisation<\/span><\/p>
                                \u2502<\/span><\/p>
                       Organisation policy<\/span><\/p>
                                \u2502<\/span><\/p>
                \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510<\/span><\/p>
                \u2502               \u2502               \u2502<\/span><\/p>
             Platform          Data          Security<\/span><\/p>
               team            team             team<\/span><\/p>
                \u2502               \u2502               \u2502<\/span><\/p>
          shared skills    shared skills    shared skills<\/span><\/p>
                \u2502               \u2502               \u2502<\/span><\/p>
                \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518<\/span><\/p>
                                \u2502<\/span><\/p>
                         Team repositories<\/span><\/p>
                                \u2502<\/span><\/p>
                    \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510<\/span><\/p>
                    \u2502           \u2502           \u2502<\/span><\/p>
                  Repo A      Repo B      Repo C<\/span><\/p>
                    \u2502           \u2502           \u2502<\/span><\/p>
                  apm.yml     apm.yml     apm.yml<\/span><\/p>
                    \u2502           \u2502           \u2502<\/span><\/p>
                    \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518<\/span><\/p>
                                \u2502<\/span><\/p>
                               APM<\/span><\/p>
                                \u2502<\/span><\/p>
                       Agent-specific output<\/span><\/p><\/code><\/pre>\n<\/div>\n<\/div>\n
The important distinction is that teams do not need identical agent configurations.<\/p>\n
They need a common starting point<\/strong>.<\/p>\n
A platform team might provide Azure architecture, AKS, networking, monitoring, reliability, and cost guidance. A security team might provide security and identity guidance. An AI engineering team might provide Foundry and Agent Framework skills.<\/p>\n
Individual application teams can then add their own domain-specific context.<\/p>\n
That gives the organisation a useful division of responsibility:<\/p>\n
\n
\n
Organisation<\/span><\/p>
    \u2502<\/span><\/p>
    \u2514\u2500\u2500 What is allowed and required?<\/span><\/p>
Team<\/span><\/p>
    \u2502<\/span><\/p>
    \u2514\u2500\u2500 What capabilities does this team need?<\/span><\/p>
Repository<\/span><\/p>
    \u2502<\/span><\/p>
    \u2514\u2500\u2500 What does this workload specifically require?<\/span><\/p>
APM<\/span><\/p>
    \u2502<\/span><\/p>
    \u2514\u2500\u2500 Resolve, lock, install, and audit the result.<\/span><\/p><\/code><\/pre>\n<\/div>\n<\/div>\n
This is where APM starts to look less like a developer convenience and more like an organisational distribution mechanism for agent context.<\/p>\n
GitHub makes this practical\u200b<\/a><\/h3>\n
For organisations using GitHub, APM can work alongside the existing repository and organisation model rather than creating another management hierarchy.<\/p>\n
The organisation can maintain an APM policy in its GitHub organisation configuration. APM can discover that organisation-level policy from the repository’s Git remote, allowing the same baseline to apply across participating repositories.<\/p>\n
For example, the organisation could establish rules around:<\/p>\n