Domain Expert Ownership of AI Workflows in Large Organizations

Large organizations keep shipping AI workflows that underperform because the model underneath them is rarely the reason the workflow fails. The cause sits upstream, in who builds the workflow and what that person knows. Central IT and platform teams build agents without deep familiarity with the workflows, data relationships, exceptions, and edge cases that practitioners in legal, finance, RevOps, or engineering carry in their heads every day. The agent runs. It answers queries. It knows the surface form of an answer but lacks the context that makes that answer usable.

Enterprise MCP deployments run into three obstacles that compound on each other: technical complexity in mapping AI tools to internal systems, change-management friction across IT, security, and business users, and the work of staying aligned with regulatory requirements. A centralized team can work through one of these for one department. Doing it for every department, at the same time, with the same ten engineers, is a different problem.

The structural issue is simple to state and hard to fix. When AI capability sits in one central function, every team that needs a workflow built or adjusted has to get in line and wait its turn. Meanwhile, the team doing the building, however skilled, doesn't hold the operational context to get the workflow right on the first few tries. Waiting and guessing happen at the same time, and the organization absorbs both costs.

What domain experts know that central IT does not

The people who should own these workflows are the ones already living inside them. Domain experts carry the tacit, operational knowledge, the actual reasoning behind a workflow, that decides whether an AI agent's output is something a team can act on or something that gets quietly discarded. None of this lives in a wiki page or a process document. It lives in practice: which data fields people actually fill in, which exceptions the official process pretends don't exist, which approvals are real checkpoints versus rubber stamps, which edge cases break a rule that looks airtight on paper.

Picture a RevOps lead who knows precisely which CRM fields sales reps fill in honestly and which ones get populated with hopeful guesses to satisfy a dashboard. An agent built without that distinction will treat every field as equally trustworthy, and the pipeline report it generates will be garbage dressed up as insight. An engineering lead knows which internal APIs are stable in practice and which ones are technically documented but quietly deprecated. A generic integration built straight from the documentation will work in testing and fail on the first real task that touches the deprecated path.

None of this points to incompetence at the center. No central team, no matter how strong, can hold the operational context of every domain in the business at once. The cost is the time every other team spends waiting for the center to acquire context that already exists, fully formed, inside the department that needs the workflow. That's the case for giving ownership to the people who already hold the knowledge, rather than routing every request through a team that has to learn it from scratch each time.

Ownership without infrastructure produces shadow AI, not governed agents

Ownership on its own doesn't solve the problem. Handing domain experts the ability to build AI workflows without a governance layer produces fragmentation, not empowerment. It produces fragmentation, duplicated effort, and agents operating on sensitive data with no one able to account for what they're doing.

The pattern repeats the same way shadow IT always has. Teams build workflows in isolation, on personal laptops, in local configuration files, in shared drives nobody else checks. There's no versioning, no access scoping, no visibility for security or compliance teams into what's running or what it touches. Five different teams end up solving the identical problem, summarizing customer calls, enriching CRM records, triaging support tickets, each building its own version from nothing, with no shared skill any of them can inherit or improve together. That's five times the engineering effort for one capability, repeated across the organization indefinitely.

The protocol layer itself doesn't escape this risk by default. The people who maintain the MCP specification have pointed out that per-user, per-server authorization creates manual onboarding work, makes policy enforcement harder for security teams, and blurs the line between personal and work accounts, specifically in enterprise deployments of the standard MCP authorization model. Without a registry entry, an approval record, or a versioned change history, an organization loses the ability to answer the questions governance exists to answer: who approved this agent, what data has it touched, who has the authority to shut it down. Domain ownership needs a structure that makes those questions answerable by default, not after an incident forces someone to go looking.

How MCP changes the structural equation for domain expert ownership

The Model Context Protocol gives domain experts a way to encode their context once, as a governed, reusable server, and make it available to every AI surface the organization uses, without rebuilding the integration for each new model or team that wants it.

Before a shared protocol existed, connecting multiple AI applications to multiple enterprise systems meant a custom integration for every single pair: an N×M problem that turned every new AI deployment into its own engineering project, and every new domain workflow into something that had to wait in the platform team's backlog. MCP acts as a standardized bridge between enterprise systems and the fast-growing landscape of AI models and assistants, cutting that integration count from N×M down to N+M. The math changes what's actually possible to build and maintain.

An MCP server encodes three things: tools, the functions an agent can call; resources, the data it can read; and prompts, the workflow templates that shape how it responds. These are exactly the three categories where domain experts hold the advantage over central IT, because tools, resources, and prompts are where operational knowledge lives.

The model-agnostic design matters just as much as the integration math. The 2026-07-28 specification makes MCP stateless at the protocol layer, so any MCP-compatible client, Claude, ChatGPT, Cursor, a custom-built agent, can reach any MCP server without a dedicated integration built for that specific client. A sales ops expert who builds a server encapsulating her team's CRM context has built something that works across Claude, Cursor, and Slack, not just the one tool she happened to be using when she built it. MCP is also heading toward becoming the standard for how AI applications talk to enterprise data infrastructure generally, and its donation to the Linux Foundation's Agentic AI Foundation removes the single-vendor risk that would otherwise make a multi-year investment in the protocol a riskier bet.

Connection-level governance versus action-level governance

Letting the right people connect to an MCP server addresses only who can get in, not what they can do once inside. Who can get in and what an agent does once it's inside are two separate problems, and treating them as one leaves the more consequential risk unmanaged.

Enterprise-Managed Authorization handles the first half. The MCP team promoted EMA to stable status, replacing per-server consent prompts with a zero-touch flow: users sign in once through their enterprise identity provider and inherit access to the servers their organization has approved. Anthropic, Microsoft, and Okta have adopted it. On the server side, Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase support it, with Slack added as of August 24, 2026. The practical effect is that security teams define access policy once, in the identity provider, and that policy propagates to every connected server without manual onboarding for each one.

EMA stops there by design. It doesn't govern individual agent actions once a token has been issued. An agent authenticated to a CRM MCP server can read, write, or delete records depending on what that server exposes, and without per-action controls, what the agent can actually do is bounded only by the server's permissions, not by the specific task someone gave it. The 2026-07-28 specification adds real hardening on the authorization side: RFC 9207 issuer validation, client credentials bound to the issuer that minted them, and the continued move away from Dynamic Client Registration toward Client ID Metadata Documents, first introduced in the 2025-11-25 release. These changes strengthen the transport layer. They don't add runtime control over what an agent does with the access it already has.

For domain experts publishing a server, this means the ability to connect isn't the ability to control. What's needed is the ability to specify which tools a connected user can call and under what conditions, tool by tool, not just server by server. That requires a registry built for scoped permissions. That registry is the next layer of infrastructure.

What a governed MCP registry makes possible for domain-owned skills

A governed registry is what turns domain expert knowledge from something that lives on one laptop into something the whole company can use. It's the structural difference between a skill one person built for their own team and a skill any team in the organization can find, trust, and run without rebuilding it.

A shared drive doesn't do what a registry does. A registry tracks versioning, so every change to a server is recorded and a team can roll back if something breaks. It assigns ownership, so each server has a named person accountable for keeping it accurate. It scopes access at the tool level, not just at the level of who knows the server exists. And it keeps an audit trail of which agents connected, which tools they called, and when, the record that makes a governance review possible.

Enforcement is what separates a real registry from a catalog. A discovery-only registry publishes metadata about what exists but still lets agents connect to servers outside the catalog. It never actually stops an ungoverned connection from happening. A registry built for enforcement blocks that path at runtime: an agent can't reach a server that isn't approved, even if it tries.

Several products already operate in this space, each on its own terms. Workato introduced its Enterprise MCP Registry on July 16, 2026, offering a system of record for more than 60 production-ready MCP servers, with lifecycle management and a gateway that enforces security policies, identity verification, and audit trails. Kong announced its MCP Registry in February 2026, a new enterprise directory inside Kong Konnect Catalog built for registering, discovering, and governing MCP servers, extending the role Kong's API Catalog already played as a system of record for enterprise tools. JFrog's MCP Registry, part of the JFrog AI Catalog, applies the same artifact management discipline JFrog built its name on to MCP servers: versioning, security scanning, access control, and auditability, treated the same way JFrog already treats any other software artifact.

The payoff of a registry is reuse. Once a domain expert publishes a skill, any team in the organization can find it and inherit it. One RevOps team's CRM enrichment workflow becomes available to every region's sales ops team without a second engineering effort, and the governance controls travel with the skill rather than needing to be reconstructed by whoever picks it up next. The operating discipline that makes this sustainable is the same discipline security teams already apply elsewhere: track which agents connect to which servers, what permissions each connection carries, who owns it, when credentials were last rotated, and review access on a regular schedule with the same rigor applied to IAM role grants. A registry built specifically around inherited permissions enforces scoped MCP access defined per team, servers that enforce the permissions of the system they connect to, and a shared catalog where a published skill is version-controlled and available company-wide the moment it's published, without anyone rebuilding it for the next team that needs it.

How permissions inheritance changes what domain experts can safely publish

What actually stops a domain expert from publishing a skill company-wide is a legitimate concern about data exposure: a skill that can reach sensitive records, made available to everyone, turns into a liability the moment permissions aren't scoped correctly, and manually redefining permissions for every new deployment doesn't scale past the first few teams that try it.

The fix is inheritance. When an MCP server connects to a source system, it should inherit and enforce the permissions already set in that system. If a user doesn't have access to a given Salesforce record, the agent acting on that user's behalf shouldn't be able to see it either, and none of this should require someone to manually redefine access rules for the new deployment.

This is what actually lets a sales ops expert publish a pipeline-analysis skill to the entire company without worrying that it will expose restricted data to someone who was never supposed to see it. The source system's own access controls do the enforcement, automatically, every time the skill runs. The alternative, requiring every new AI deployment to manually redefine its own permissions, turns every published skill into a security review backlog. That backlog is the same central bottleneck domain ownership was supposed to remove, just relocated to a different desk.