Cross-Unit AI Skill Publishing Platforms With Centralized Approval Workflows

Why sharing AI skills across business units keeps failing

• Role: Opens the argument by naming the real problem — not lack of willingness to share, but absence of the structural infrastructure that makes sharing trustworthy — setting up every section that follows.
• Most cross-unit AI skill programs stall not because teams won't share, but because there is no governed mechanism to make sharing safe, auditable, or repeatable at scale.
• The pattern is consistent across sectors: a team builds a useful prompt or agent workflow, it works locally, and the moment another team tries to reuse it, the questions multiply — which version? approved by whom? does it respect our data access rules? — and no one has answers
• The structural root: AI adoption has outpaced governance infrastructure, so skills circulate as shared drives, Slack links, and word of mouth rather than through any system that enforces ownership or controls
• The consequence is duplication: multiple teams rebuild functionally identical skills independently because there is no single place to find, vet, or trust what already exists
• The Agentics' enterprise MCP guide finds that only 11 to 14% of enterprise agentic AI pilots reach production, identifying the most common blocker as the absence of a registry, approval workflow, or audit layer before agents touch anything consequential — alongside technical complexity and change management, which the guide also names as real obstacles.
• Note: Open on the intuitive but wrong diagnosis ("teams just need to share more willingly") and pivot quickly to the structural one; this section is brief — one or two tight paragraphs in the article — its job is to name the real problem so the rest of the piece can solve it.

What a governed registry actually is and how it differs from a shared folder or prompt library

• Role: Establishes the first piece of the solution architecture — the registry — precisely enough that readers understand what separates it from the informal sharing they already do; this definition carries the argument forward.
• A registry is not a repository of files: it is a system of record that makes each skill findable, versioned, scoped by access, and owned — properties a shared drive structurally cannot provide.
• The functional distinctions that matter in practice:
  • Discoverability: skills are catalogued so any team can search and find what exists before rebuilding it
  • Versioning: every change is recorded; teams consuming a skill know which version they depend on and can pin to a stable release
  • Ownership: each skill has a named owner — typically the domain team that built it — who controls updates and is accountable for its behavior
  • Access scoping: the registry enforces who can see and invoke each skill, inheriting the permissions of the underlying data sources rather than requiring each consumer to redefine them
• The registry-gateway distinction matters for implementation: a registry lists which skills exist and which are approved; a gateway sits in the request path and enforces whether each call is actually permitted under whose credentials — enterprises typically need both, not one or the other
• The Agentics' enterprise MCP guide frames this precisely: the strongest governance combines a per-agent tool allowlist, identity binding, a central gateway, and human approval for irreversible actions
• The MCP protocol gives this architecture a concrete implementation path: each skill or capability is exposed as an MCP server; the registry tracks those servers; the gateway routes and authorizes calls on each request
• Note: Keep this section definitional and concrete — resist turning it into a product survey; the goal is that a reader finishes knowing exactly what a registry does that a shared drive does not, and why that difference is structural rather than cosmetic.

How MCP makes a single governed registry work across every AI surface a team uses

• Role: Connects the registry concept to the protocol infrastructure that makes it practical at enterprise scale — showing that MCP is not a product but the plumbing that lets the registry architecture function across clients, models, and teams.
• MCP resolves the N×M integration problem that made cross-unit skill sharing impractical: without a standard, each new AI client connecting to each new enterprise capability required a custom connector; MCP reduces that to build-once, use-everywhere.
• The practical consequence for publishing: a skill built once as an MCP server can be invoked by Claude, ChatGPT, Cursor, Slack's agent layer, or any other MCP-compatible client — the registry publishes one artifact, not one per surface
• The 2026-07-28 MCP specification made this architecture substantially easier to operate at scale: by moving to a stateless protocol core, a remote MCP server is now no different from any other HTTP workload, meaning it can be hosted and load-balanced on existing infrastructure without shared session state
• Header-based routing introduced in the same release means gateways can authorize and meter on HTTP headers — method and tool name travel in Mcp-Method and Mcp-Name — without parsing JSON bodies, which is directly relevant for approval workflows that need to inspect and log specific tool calls
• List results are now cacheable with cache hints and deterministic ordering, so clients can maintain stable tool catalogs across reconnects — a registry's published skill list stays consistent for consuming teams without constant re-fetching
• The MCP roadmap published August 2026 confirms the protocol's next priority areas include agent identity and enterprise-ready security — specifically standardizing how agent workloads authenticate without pasted API keys or long-lived tokens — which is the identity infrastructure a cross-unit approval workflow depends on
• MCP was donated to the Linux Foundation's Agentic AI Foundation in December 2025, backed by OpenAI, Google, Microsoft, AWS, Cloudflare, and Bloomberg — removing single-vendor risk for enterprises building long-term registry infrastructure on the protocol
• Note: Explain the stateless shift in plain terms — the point for a non-protocol reader is that MCP servers can now scale horizontally like any web service, which means the registry architecture is operationally mainstream, not experimental; keep technical detail in service of that business point.

What the approval workflow must do before any skill is published to another team

• Role: Introduces the second mechanism — the approval gate — and argues for its specific requirements; this is the section where the governance architecture becomes concrete and actionable rather than conceptual.
• An approval workflow is not a bureaucratic checkpoint: it is the moment the organization establishes that a skill is safe, scoped correctly, and auditable before it acquires the trust of another team's agents.
• The minimum requirements a credible approval workflow must satisfy:
  • Identity verification: who submitted the skill, and under what organizational authority — approval without identity binding produces records no compliance team can use
  • Access scope review: does the skill's data access match what the consuming team is actually permitted to see, or is it silently broadening access by wrapping a privileged connection in a shareable interface
  • Version commitment: the approval applies to a specific version; a subsequent change to the skill requires a new approval cycle, not an implicit re-approval of prior trust
  • Auditability of the approval itself: who approved, when, and what they reviewed — not just that the skill is in the registry
• EMA-supporting servers as named in the specification release include Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, with Slack listed as in progress
• The security consequence of skipping this layer is concrete: unapproved servers configured by individual employees — sometimes called shadow MCPs — create an attack surface that central IT cannot see, let alone govern
• The August 2026 MCP roadmap lists agent identity and delegation as a top priority, specifically covering Workload Identity Federation and token exchange standards — the approval workflow depends on this infrastructure being in place so that approvals bind to verifiable agent identities, not just user accounts
• Note: The strongest version of this section argues that without approval gates that cover all four requirements above, the registry is a catalog of risk, not a catalog of trust; frame the requirements as what "approved" has to mean for the label to carry weight, not as a checklist to complete.

How teams are building and operating cross-unit registries in practice

• Role: Moves from architecture to evidence — showing that the registry-and-approval model is not theoretical but already running in production organizations, with named outcomes that ground the argument.
• The organizations that have moved from pilot to governed production share a consistent pattern: a central registry combined with line-of-business publishing rights, scoped so each team owns its domain skills while the organization maintains a discoverable, trusted catalog.
• Workato Enterprise MCP Registry:
  • Workato launched its Enterprise MCP Registry in July 2026, combining MCP Composer for building servers, MCP Gateway and MCP Proxy for securing and governing AI interactions, and a catalog of more than 60 production-ready MCP servers
  • The design allows organizations to build, publish, discover, secure, and operate AI capabilities through a single platform
  • 43% of customer-published Enterprise MCP servers start from Workato's pre-built servers before being extended for organization-specific needs, which illustrates the reuse pattern a governed registry enables
  • Kevin Wolf, Senior Director of IT Operations at Swanson Health, described the governance requirement directly: knowing an agent is connected is not enough — organizations need to know who authorized the action, what capability was invoked, and whether every step can be audited
• AWS open-source MCP Gateway and Registry:
  • The open-source MCP Gateway and Registry (Apache 2.0) addresses both central IT governance and line-of-business publishing: central IT maintains a list of approved servers and skills; each line of business also publishes its own assets to its team and, where appropriate, to the wider organization
  • One enterprise running it in production described going from "which MCP servers or skills exist?" to finding, vetting, and consuming the right AI capabilities in minutes — the discoverability outcome a registry is designed to produce
• GetYourGuide:
  • Built an MCP server for internal services lookup — answering questions such as which team owns a given service and which team an individual belongs to
  • A separate MCP implementation for customer support runs over their GraphQL gateway, letting customer care agents answer questions such as how many participants were in a booking and whether previous refunds exist for a booking ID
  • After initial testing, the team found it useful and moved to broader rollout — a practical example of a skill moving from one team's build to multi-team use
• Salesforce Hosted MCP Servers went generally available in April 2026 for Enterprise Edition and above, handling hosting, authentication, and permissions centrally so AI clients can query and act on CRM data without each team configuring access independently
• Note: Let each case make one concrete point — Workato on the audit and ownership requirement, AWS on the central-plus-LOB publishing model, GetYourGuide on the natural lifecycle of a skill from local build to shared tool, Salesforce on centrally managed permissions as a governance primitive; don't summarize each case generically.

Department-specific patterns for publishing skills through a governed registry

• Role: Grounds the architecture in the domain expertise that actually produces skills worth sharing — showing that the registry model works because domain teams own their skills, not because central IT mandates them.
• The value of a cross-unit registry comes entirely from what domain teams put into it: a registry without domain-owned skills is an empty catalog, and domain teams only contribute when the publishing process respects their ownership and expertise.
• RevOps and pipeline intelligence:
  • The governance requirement specific to RevOps: keep data servers read-only and route writes through the CRM's server, where permissions and audit trails already exist — allowing an agent to write enriched records back through a read-oriented data server corrupts the system of record
  • Pipeline intelligence queries that pull from CRM activity, email engagement, intent signals, and website behavior in a single query eliminate the manual data-stitching work that consumes significant analyst time each week
• Engineering:
  • Engineering teams adopt MCP-based skills fastest because the integration surface — GitHub or GitLab, Jira or Linear, Datadog or Sentry, cloud infrastructure — is rich and the productivity outcomes are measurable
  • Using the Linear MCP, developers can pass an issue link to an AI like Cursor or Claude Code and ask it to complete the ticket — the skill is self-contained and publishable to any team using the same toolchain
  • Engineering also produces the skills most likely to benefit other departments when published: service catalog lookups, deployment status checks, and incident queries are useful across Support, IT, and Product
• Customer support:
  • Support ticket triage and routing is a proven cross-team use case — a skill built by the support team that queries booking history, refund status, or account context (as at GetYourGuide) has direct reuse value for sales, success, and billing teams
  • The MCP-over-GraphQL-gateway pattern GetYourGuide used is replicable anywhere a team already has a GraphQL API: the skill adds an AI-accessible interface without rebuilding the underlying data layer
• Note: The editorial point here is that domain teams are the right owners of their skills — not central IT — and the registry's job is to make domain-owned skills available company-wide without requiring central IT to understand or rebuild them; keep this section grounded in the named examples and resist turning it into a generic "here are the departments" inventory.

What multi-surface deployment means for a registry: one skill, every agent interface

• Role: Extends the argument to the deployment reality most enterprises face — multiple AI clients in use simultaneously — and shows that a governed registry is the mechanism that makes one approved skill available consistently across all of them without re-approval or re-scoping.
• The strategic payoff of a registry-and-approval architecture is that an approved skill does not have to be re-approved for each AI surface: one governed artifact works with Claude, ChatGPT, Cursor, Slack, and any other MCP-compatible client.
• Slack operates bidirectionally with MCP: its official MCP server exposes Slack tools to compatible AI systems, while Slackbot can act as an MCP client for approved external MCP servers — meaning a skill approved in the registry is reachable from within Slack conversations without a separate integration
• The model-agnostic consequence: because business context, permissions, and governance travel with the skill in the registry rather than being tied to any single LLM, organizations avoid the lock-in risk of rebuilding governance every time they adopt a new model
• Memory and context portability across clients — connecting multiple LLM clients to shared context via MCP — solves a problem model providers will not solve themselves, because their incentive runs toward lock-in; a registry that holds shared context serves the organization's interest, not any individual vendor's
• The scoped MCP approach means each team gets its own governed interface into the registry — one that plugs into whatever agent or chat surface the team uses — without requiring a custom UI to be built or maintained for each surface
• Note: This section reinforces the model-agnostic positioning without naming competitors as targets; the argument is that the registry architecture protects the organization from model churn, not that any specific model is better or worse.

The governance requirements the approval workflow must satisfy as the EU AI Act takes effect

• Role: Raises the compliance dimension as a concrete reason the approval workflow's auditability requirements are not optional — tying the architectural argument to regulatory obligations that apply to any organization operating agents on regulated data.
• Cross-unit AI skill publishing is not just an operational challenge: for organizations using agents on regulated data, the approval workflow is the mechanism that satisfies legal obligations around logging, human oversight, and auditability.
• The approval workflow closes this loop: because every approved skill carries a record of who reviewed it, what access scope was confirmed, and which version was approved, the registry becomes the audit trail the regulation requires rather than a separate compliance layer
• This is the practical meaning of "every agent action should be auditable": if the approval workflow cannot produce a record of who authorized what and when, the organization does not have governance — it has a catalog
• Note: Keep this section focused on what the regulatory requirement means for how the approval workflow must be designed — not on EU AI Act compliance as a standalone topic; the point is that the same architectural choices that make cross-unit trust possible also satisfy what regulators require of high-risk agent deployments.

How to structure a registry and approval workflow for an organization building this now

• Role: Closes the argument with actionable architecture — translating the editorial through-line into a concrete sequence that a team can follow, so the piece ends with practical direction rather than abstract principles.
• Building a cross-unit registry with approval gates is a sequenced infrastructure problem, not a policy problem: the governance follows from the architecture, not the other way around.
• Phase one — inventory before publishing:
  • Before publishing anything, audit which AI skills exist across teams: shadow MCPs, locally configured servers, and informal prompt libraries are all in scope — the registry cannot govern what it doesn't know about
  • Identify which skills have cross-team reuse potential, which are safely read-only, and which touch write access or sensitive data — this determines which approval tier they require
• Phase two — registry and gateway setup:
  • Stand up a registry that tracks approved MCP servers with versioning, ownership, and access scope as required fields — not optional metadata
  • Deploy a gateway in the request path that routes on Mcp-Method and Mcp-Name headers (now standard in the 2026-07-28 spec) so every tool call is inspectable and loggable without parsing request bodies
  • Integrate with the organization's identity provider using Enterprise-Managed Authorization where supported, so access provisioning is centralized and does not require per-app OAuth for each consuming team
• Phase three — approval workflow design:
  • Define at minimum two tiers: read-only skills with lower friction approval, and write-access or cross-system skills requiring security and data-governance review
  • Bind each approval to a version: a new version of a skill does not inherit the prior approval
  • Make the approval record — who reviewed, what scope was confirmed, when — a first-class field in the registry, not a comment in a ticket system
• Phase four — domain-team publishing with central visibility:
  • Let domain teams publish their own skills to the registry without requiring central IT to build or understand each one — central IT sets the approval criteria; domain teams own the skills
  • Publish approved skills to a governed, searchable catalog so teams can find and consume what exists before rebuilding it — the discoverability function is what turns a registry into a force multiplier rather than a compliance filing cabinet
• Note: Close the section — and the article — on the compounding return: every skill that reaches the registry instead of being rebuilt independently is a unit of organizational capability that grows rather than fragments; the governance architecture is what makes that compounding possible.