I was reading a piece about OpenAI's Agent Plugins and the new shared language around skills. At first it looked like a technical announcement. A new folder format. A manifest. A place to put MCP configuration.

Then I thought: hang on. This is not just a technical detail.

If we can package a useful way of working so that an agent can load it, another person can install it, and a company can reuse it, professional know-how starts to look less like something that lives in somebody's head and more like a product category.

A consultant's method. An accountant's checklist. A recruitment process. A client-onboarding routine. A security review. A particular way of turning a messy meeting into a clear next action.

All of that can start to travel.

Which brings us to the slightly mischievous question: will we be getting skill patents?

The answer is more useful than a simple yes or no.

Portable skill packages make expertise easier to distribute. They do not make a method automatically ownable.

CrewAI was useful. But it was not a common parcel

I used CrewAI as a way of thinking about agents, roles and workflows. It was useful. It gave a shape to a crew and a flow: who does what, in which order, with which tools and state.

But CrewAI is a framework. A useful system inside its own ecosystem is not automatically a portable thing that every other agent product can understand.

That is what interests me about the current skills and plugins direction. The emerging Agent Plugins specification describes an open, vendor-neutral package structure for Agent Skills and MCP configuration. It is a working draft, not a finished global constitution. But it is an attempt to create a shared parcel.

OpenAI is part of the wider skills-and-plugins moment rather than its sole owner. Its own documentation describes skills and plugins for ChatGPT and Codex. The Agent Plugins specification is a separate working draft; its technical steering group lists OpenAI alongside other organisations.

That distinction matters. We are not talking about a magical new OpenAI file that every system must obey, nor should we assume that similarly named plugin systems are interoperable without checking. We are talking about an emerging common way to package something useful.

Three words worth separating

These terms get thrown together, but they do different jobs.

  • A skill holds reusable procedural knowledge: instructions, examples, references, and sometimes scripts or supporting assets.
  • MCP connects an agent to tools and data. Whether the route is approved, what it can do and how credentials are stored depends on the client, workspace and server.
  • An Agent Plugin is a portable package that can include skills, optional MCP configuration and metadata so a compatible client can discover and load the components consistently.

Anthropic makes a similarly helpful distinction: skills carry procedural knowledge; MCP connects external services and data. They can work together, but they are not the same thing.

A diagram explains that a skill contains a procedure, a plugin packages it for portable distribution, and optional MCP configuration connects approved tools and data.
Skills describe how to work. MCP describes a route to tools and data. The client and server still decide permission. A plugin is the parcel that can carry both.

That is a bigger deal than it sounds. Once a method can move cleanly between compatible tools, it can be shared, sold, licensed, adapted, tested, reviewed and copied much more easily than a conversation trapped in someone's chat history.

A portable package makes expertise more commercial

For years, professional firms have sold people, time, documents, workshops and software. The actual working method has often remained partly implicit: the thing a very good person does when they know what questions to ask, what evidence to request and what to ignore.

Skills make part of that method explicit.

That does not mean the skill replaces the professional. A great onboarding skill will still need a good operator, good data, sensible permissions and someone who knows when the situation is unusual. But it does mean the useful, repeatable part can become a recognisable asset.

And once it is recognisable, people will quite reasonably ask: who owns it?

A skill is a package, not a patent

Here is the blunt UK-first answer.

Copyright arises automatically in original material such as written instructions, code, templates, images and other assets. It is useful protection for the expression you created. You do not need a UK copyright register before your original work has copyright.

But copyright does not give you ownership of the abstract idea. The UK government's own IP guidance says copyright protects the expression of an idea, not the idea itself. Someone may be able to create a different checklist, in different words, for the same professional problem without copying your protected expression.

That is why a copied skill and a competing skill are not necessarily the same legal question.

A licence is the next layer. It says what a recipient may do: use the package internally, adapt it, redistribute it, use it commercially, or keep it within a named organisation. Agent Skills supports an optional licence field, and Agent Plugins recommends licence metadata. But a field in a manifest is not a forcefield. Clear terms, a real licence file and sensible contracts do the actual work.

Confidential know-how is different again. A private method, pricing rule, prompt library, operating sequence or client-specific insight may be protected under the law of confidence when it remains confidential and reasonable safeguards are in place. Publicly publishing the full recipe and later calling it a trade secret is not a very robust plan.

Finally, there are patents. In the UK, a generic business method or way of thinking is not normally patentable, and neither is non-technical software as such. A particular technical invention may be different, but it must meet conditions including novelty, inventiveness and industrial applicability, with technical-process questions needing specialist advice. Public disclosure can also harm novelty before an application is filed. That is a question for a patent attorney, not a label we should casually stick on a well-written workflow.

So no: a common skill format does not suddenly make a generic workflow patentable.

A five-layer diagram distinguishes copyright, licence, trade secret, hash or signature, and patents when protecting a professional skill package.
Different layers answer different questions. The useful move is to use the right layer for the thing you are actually trying to protect.

What a hash can and cannot tell you

I also think hashes will become normal professional hygiene for serious skills.

A SHA-256 checksum can establish byte-for-byte equality when someone compares a package with an authentic reference digest. A signed release can add integrity and source-authentication evidence after the signature is verified against a trusted signing identity.

That is valuable. It is not the same as a legal ownership certificate.

A hash cannot settle whether someone independently recreated the method. It cannot prove they read yours and rewrote it. It cannot decide whether a rival package infringes copyright. And it certainly cannot turn a generic workflow into a patent.

Think of a hash as a release receipt, not a courtroom.

The Skill Ownership Receipt

Here is the lightweight pattern I would use for a serious professional skill package. It is not a new proprietary standard. It is simply a tidy evidence trail built around the emerging common format.

client-onboarding-skill/
  plugin.json
  LICENSE
  CHANGELOG.md
  PROVENANCE.md
  skills/
    client-onboarding/
      SKILL.md
      references/
      assets/
  mcp.json                 # only when a tool or data route is needed
  • plugin.json identifies the package, version, author, repository and licence reference.
  • SKILL.md holds the actual instructions and can point to references, assets and scripts.
  • LICENSE says what other people may do with the package.
  • CHANGELOG.md makes the evolution of the method visible.
  • PROVENANCE.md records the source, release date, SHA-256 checksum, optional signature and any material dependencies.
  • mcp.json is only for tool configuration. The Agent Plugins specification is explicit that it must not embed credentials; permission, scopes and credential storage remain client-managed.

That is enough to make a professional package clearer, easier to audit and more defensible in a commercial conversation. It does not replace legal advice, contracts or a decision about whether the thing should be public at all.

Choose the commercial posture before you publish

Before releasing a skill, I would make a conscious choice. If a genuine technical invention might be involved, speak to an IP professional before public disclosure. Otherwise, there are at least three sensible routes.

  1. Open: publish it under a permissive licence because adoption, reputation and community learning matter more than exclusive control.
  2. Licensed: make it available under commercial or restricted terms, with a clear recipient, permitted use, support boundary and update route.
  3. Confidential: keep the differentiating method inside the company or client relationship, using access controls and confidentiality terms rather than public distribution.

There is no universal right answer. The mistake is publishing first and only then asking what you meant to protect.

The next market may be for professional methods

The exciting part here is not a land grab around patents. It is that more people will be able to turn hard-won professional judgement into something reusable and inspectable.

That can be brilliant for small firms. It can preserve quality. It can help clients receive a repeatable service. It can give a new recruit a real starting point. It can make an organisation's best practice less dependent on one person remembering a clever trick on a Thursday afternoon.

It also makes the terms of trust more important. Who wrote the skill? Which version is running? What can it connect to? What data may it see? What happens when it is copied, adapted or wrong?

We are not getting skill patents by default.

We are getting the beginning of something more practical: portable instructions, visible terms, provenance receipts and clearer permission boundaries.

That is not quite as catchy. It is much more useful.

Sources and notes

This article is UK-first public information and commentary, not legal advice. Rights, licences, employment terms, confidentiality and patentability depend on the specific work, jurisdiction and facts. Evidence and specification status checked on 9 August 2026.