The Last Mile Problem of Enterprise AI

When an organization finds a better way to do something with AI, the instinct is to scale it. Build a skill, configure an agent, package the workflow, and distribute it across the teams that would benefit. The promise is that institutional knowledge becomes a shared capability instead of a personal one.

The problem is that distributing these capabilities at scale is not a small task, and often as difficult to track as general adoption of AI.

What is a skill, and why is distribution harder than it sounds?

A skill, in practical terms, is a pre-configured AI workflow often inclusive of a system prompt, a set of instructions, and defined context that packages a repeatable task so a user can execute the same actions consistently. A marketing team's competitive brief template. A legal team's contract review workflow. A developer's code review agent. The idea is that once someone builds the best version of a process, you don't have to restart it from scratch every time in a new chat or context window.

The challenge is that skills travel informally through Slack, screenshots, or shared file links. There is rarely a package manager, deployment tracker, or version control that can be managed from a centralized vantage point at scale. There is no way to verify, from a centralized vantage point, who has the skill, which version they're running, whether it's been modified, or whether they're using it at all.

As KPMG found in their Q4 AI Pulse Survey, 65% of enterprise leaders cite agentic system complexity as the top barrier to scaling AI and that's before you account for the distribution problem on top of the technical one. The governance challenge isn't just building the skill. It's knowing what happens to it after you let it go.

A practical scenario

In this example, consider working with a marketing team that built a skill for drafting campaign briefs that includes the necessary brand voice guidelines, audience definitions, competitive framing, approval criteria, all baked into the agent configuration. That way they don’t need to share this information for each project. The skill is then distributed throughout the team via Google Drive to drive consistent output across the team.

Later, though, it’s unclear if the same skill is being used across each team member, if that skill has been updated by certain users and operates with different context on a local device, or if people are performing the same actions from scratch each time. Are the outputs clustering around the topics and tone the skill was designed to produce, or has the usage drifted?

The only way to find out is to ask. That means the answer ends up being filtered through whatever people remember, estimate, or think was the best answer to give. Like any enterprise software adoption, manually validating usage and expectations is a wildly inefficient way to ensure positive results.

What should have been possible in this scenario is visibility into which users were running that agent configuration, what they were prompting it with, whether the output clusters matched the intended use case, and where usage had dropped off or deviated. That picture of who has the skill, who's using it, and whether it's working as designed is what makes distribution a real capability instead of a faith-based initiative.

A threat scenario

The same opacity that makes skill adoption hard to track makes skill drift hard to detect, and this drift isn't always accidental.

In this scenario, a sanctioned skill gets distributed across a development team. It's configured to assist with code review and documentation. At some point, through a malicious prompt, a compromised configuration file, or an exploited trust relationship between agent and tooling, the skill's behavior changes. It still looks like the approved workflow from the outside. Users invoke it the same way. But what it's actually doing has shifted.

This is not a hypothetical. Researchers have documented that Cursor's one-time MCP approval creates a permanent trust relationship—all future modifications to that configuration are trusted without re-validation. A crafted repository opened in an agent can silently modify configuration files that function as an execution layer. The skill you approved last quarter may not be the skill running today, and without visibility into behavioral patterns, there's no way to know.

The detection question isn't "did someone change the configuration file?" It's "is this agent doing what it's supposed to be doing?" That requires knowing what normal looks like, including which topics the skill should be working on, what kinds of outputs it should produce, and being able to identify when the pattern changes. Signature-based detection doesn't work here. The skill isn't behaving anomalously in any technical sense. Its behavior has just changed in ways that matter semantically.

What tracking this looks like

Origin surfaces which agents are running across which devices, who is invoking them, and what the interaction patterns look like over time. For skill distribution, this means:

• Adoption visibility: you can see whether the skill you distributed is actually being used, by whom, and how frequently without having to ask.
• Consistency monitoring: topic clustering shows whether interactions with a given agent are staying within the intended scope or drifting into uses the skill wasn't designed for.
• Intent deviation: when an agent that reliably clusters around one set of topics starts producing outputs that don't fit that baseline, that's a flag, whether the cause is intentional manipulation or gradual configuration drift.

The goal isn't surveillance. It's the same thing every other operational function demands of its tools: visibility into whether the thing you deployed is doing what you built it to do. Skills are how organizations try to standardize AI.