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.

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.

Six months later, the audit question is simple and uncomfortable:

What agent context was installed, where did it come from, and who allowed it?

Agent Package Manager, or APM, addresses that gap.

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, then running apm install 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 as the install-time governance control for dependencies, MCP servers, and targets.

Agent configuration needs this kind of mundane, reviewable plumbing.

I was wiring up the Drasi SyncVectorStore reaction against Azure AI Search when it crash-looped on startup with what looked like a straightforward Azure AI Search naming restriction. The reaction contains a one-character bug in two places, with no YAML setting, secret reference, or config flag that routes around it. Getting it working meant reading the reaction's source, proving the exact constraint with a live REST test, and building the fix as network infrastructure rather than waiting on an upstream release.

LLM context is a snapshot. Ask an agent "what's the status of order 47?" and it answers from whatever it retrieved minutes ago, because Model Context Protocol solved tool access but not the other half of the problem, knowing when the underlying data has actually changed. MCP resources are usually read-on-demand: the client asks, the server answers, and nothing happens in between unless the client asks again.

Drasi has an MCP Reaction that closes that gap. It exposes each continuous query as an MCP resource that a client can subscribe to, and the server pushes a notification the moment the result set changes, no polling, no re-fetching on a timer. I wanted to see whether that actually held up with a real client rather than trusting the resource model on paper, so I connected the official MCP Inspector to a live reaction and watched what happened.

Every RAG pipeline I have looked at has the same quiet flaw: embeddings generated at index time go stale when the source system changes, and the standard fix is a nightly reindex job. The job polls and re-embeds the entire corpus every night regardless of how little changed. I tested whether Drasi's SyncVectorStore reaction could invert that with a small products catalogue in Azure Database for PostgreSQL, a continuous query for "in-stock products with a description," and a vector store.

Every AKS cluster running GitOps already has tools watching for drift. Gatekeeper or Kyverno block bad configuration at admission time. Flux or Argo tell you when the live cluster has drifted from git. Prometheus alerts fire on metrics with a for: duration. None of them are wrong to have, and I am not going to pretend Drasi replaces any of them. What they all share is a boundary: each one is good at the specific thing it watches, and none of them answers a question that cuts across a few resource types at once.

Drasi answers relational questions about live cluster state after admission: is this Deployment still under-replicated after five minutes, and is that Pod running an unapproved image? I tested standing queries over a live AKS resource graph. Only two of the six rules I set out to build survived unchanged; the gap between what looked right on paper and what ran was the useful result.