OpenAI, Anthropic, Gemini: which concepts are converging?

The last two posts were all about Skills. Following the thread further, I found that some very similar things keep appearing in OpenAI’s, Claude’s and Gemini’s agent products:

Skills, MCP, Plugins / Extensions, Hooks, Subagents, and AGENTS.md, CLAUDE.md, GEMINI.md.

At first it’s easy to get bogged down in the terms. Looking at them together later, I found something more interesting:

the more basic a capability is and the more it needs reusing across tools, the more it’s converging; the higher up you go — how things are combined, installed and managed — the more the three still keep their own approaches.

What has truly started to converge: Skills and MCP

The two clearest examples right now are Skills and MCP.

Both came from Anthropic, and both later became open standards.

Skills: saving how a kind of thing is done

What a Skill solves is:

for this kind of task, how should AI do it?

At its most basic it’s one SKILL.md; a bit more complex, it can carry references, scripts and assets.

make-photo-stamp-archive, which I took apart earlier, is a very simple example: the author organized the design method — composition, choice of stamp, what mustn’t be changed, how to check at the end — into a Skill.

Claude Code, Codex and Gemini CLI now all support Agent Skills.

That means the same way of doing things can start being used across agents.

Of course, the same Skill doesn’t mean the three will produce the same result in the end.

For example, a stamp Skill can hand the same design rules to Codex, Claude Code or Gemini CLI, but the final images still depend on which image model and editing tools the host provides, and how the model itself interprets the rules.

So a Skill is more like a portable “method,” not something that packs up the underlying model’s capabilities too.

MCP: connecting outside capabilities to AI

MCP (Model Context Protocol) solves a different problem:

how does AI use outside data and tools?

For example, a GitHub MCP server can provide an agent with:

• reading repos
• searching issues
• viewing PRs
• modifying certain resources

Before, every AI product might build its own GitHub integration separately.

With MCP, outside services can expose capabilities according to a common protocol, and agents that support MCP can then call them.

So Skills and MCP are easy to understand together:

Skill = how it should be done

MCP = what can be called while doing it

A refund Skill can specify: look up the order first, then check the rules, then decide whether to refund; the ability to actually read the order and execute the refund can be provided by an outside system through MCP.

These two layers are the most suited to standardization, because they naturally have value in being reused across platforms.

One layer up, everyone is starting to look alike, but hasn’t fully converged

Skills and MCP are only components.

As agents can do more and more, the next question naturally arises:

how are these capabilities combined and given to users?

Here the three companies’ answers are already very similar, but not yet one standard.

OpenAI calls it a Plugin.

Claude Code also calls it a Plugin.

Gemini CLI calls it an Extension.

They can all bundle several capabilities together, such as:

• Skills
• MCP servers
• Hooks
• Subagents
• configuration and resources

But how to write the manifest, how to declare permissions, how to install, how to display, how to manage the lifecycle — each still has its own design.

Now I actually think that makes sense.

Because at this layer, it’s no longer just a technical interface; it also involves:

product UI, permissions, security, the marketplace, authentication, the local runtime and user experience.

These are exactly where platforms want to differentiate.

So what’s more likely to happen in the future isn’t:

OpenAI, Claude and Gemini ending up with identical plugin folders.

But:

more and more shared components inside, while the way they’re combined outside can still differ.

A fairly ideal structure might be:

the portable core

├── Skills

├── MCP

├── scripts

└── assets

packaging for different platforms

├── OpenAI Plugin

├── Claude Plugin

└── Gemini Extension

Share as much as possible underneath, with a thin layer of adaptation on top.

AGENTS.md / CLAUDE.md / GEMINI.md differ in more than name

All three files solve a very practical problem:

some project rules shouldn’t have to be told to AI again every time a new session starts.

For example:

• how the repo runs
• what the test commands are
• which directories mustn’t be touched
• coding conventions
• what to focus on in review

Codex uses AGENTS.md, Claude Code uses CLAUDE.md, Gemini CLI uses GEMINI.md.

But the differences aren’t only the file names.

For these files, agents differ in:

• where they start reading from
• how rules in subdirectories are inherited
• which rule takes priority
• whether imports are supported
• when they’re loaded dynamically

Each has its own mechanism.

So what’s really worth unifying isn’t “everyone eventually renaming the file AGENT.md.”

The same file name doesn’t mean much.

What’s more valuable is whether project rules can be reused across agents as much as possible, instead of maintaining three copies that slowly drift apart.

Hooks and subagents are yet another case

These two concepts are also increasingly common across the three, but right now they’re closer to shared design patterns than a unified standard.

Hooks

solve:

when a certain event happens, what action must be taken.

For example:

run a formatter automatically after code changes; a security check must run before committing.

This is an especially good place for things that shouldn’t be left to the model to “remember to do.”

Subagents

solve:

when a task is too big, how to hand part of it to a more specialized agent.

For example, the main agent owns the whole development task, while handing code search, testing and research to different subagents.

The three companies’ basic thinking is getting closer, but configuration, permissions, context and scheduling still differ.

So this isn’t a “unified standard,” but:

facing the same agent-engineering problems, everyone naturally arrived at similar design patterns.

Why do some things converge and others don’t?

Having researched this far, I think the underlying pattern is actually quite clear.

If something needs to be used jointly by many different systems, standardization is very valuable.

For example:

“how do you describe a method of working for AI?” → Skill

“how does AI communicate with outside tools?” → MCP

Without convergence, every builder has to redo it for every platform.

But once you get to:

“how are these capabilities combined, displayed and authorized in my product?”

you’re already in product design.

Keeping differences here is actually valuable.

So I now roughly see the whole agent ecosystem as two layers:

lower-level components more worth standardizing

• Skill: method
• MCP: connections to tools and data

higher-level orchestration that can stay different

• Plugin / Extension: how things are packaged
• Project instructions: how long-term context is managed
• Hooks: how the lifecycle is managed
• Subagents: how tasks are orchestrated
• UI / Workspace: how it’s ultimately given to people

The boundaries will of course keep shifting, but the direction is already fairly clear.

For builders, what I think is really useful here

isn’t finally memorizing six new terms.

It’s being able to start consciously distinguishing, when making your own things:

put core capabilities somewhere portable

Methods you’ve built up can be organized into standard Skills first.

When AI needs outside tools, consider MCP first where it fits.

That way, if you change models or agents in the future, the core is still there.

keep the platform-specific parts thin

If it’s only to fit how Codex, Claude Code or Gemini CLI installs things, there’s no need to hard-code all the real product logic into that layer.

Platforms change fast; the packaging can be redone.

Don’t leave everything to the model’s judgment

What needs experience and judgment:

→ Skill + Model

What must happen reliably:

→ scripts / hooks

What needs outside capabilities:

→ MCP

What needs a division of labor:

→ subagents

Getting these boundaries clear matters more than which company’s agent you pick.

So my most practical reminder for builders from this research is:

try to make sure the things you really build up don’t depend on one particular AI product to exist.

Models will change, agents will change, plugin formats may keep changing too.

But if your methods, knowledge, tools and workflows are put in portable layers from the start as far as possible, switching hosts may only mean reconnecting the outer layer.