OpenAI Adopted Anthropic's Agent Skills Format in 48 Hours — What That Means for Your Deploy Runbooks

Two competing foundation-model vendors agreeing on a wire protocol is common enough that it barely makes news anymore — that's what happened with MCP. Two competing foundation-model vendors agreeing on a file format is rarer, and it just happened again. On December 18, 2025, Anthropic published the Agent Skills specification: a folder of Markdown plus a small YAML header, called SKILL.md. Within 48 hours, OpenAI shipped support for it in ChatGPT and Codex CLI — not a competing scheme, not a rival packaging convention, the same spec. By March 2026, roughly 30 agent clients spoke it, including Microsoft Copilot, Cursor, JetBrains, Google's Gemini CLI, and Block's Goose.

That's the second convergence event in the same quarter. Anthropic also donated MCP itself to the vendor-neutral Agentic AI Foundation under the Linux Foundation in the same window, co-founded alongside OpenAI and Block, with AWS, Google, Microsoft, Cloudflare, GitHub, and Bloomberg signed on as supporters. Protocol and packaging both landed on one shared spec, in the same three months, backed by the same rival vendors. For a team like ours at Bex.co with a roadmapped "how to debug a failed deploy" runbook pack sitting in the backlog, that's not just interesting trivia — it's the fact that decides whether that pack gets written as a portable SKILL.md or a bespoke prompt format only our own agent understands.

What Actually Happened, in Order​

The timeline matters more than the headline, because "OpenAI adopted a Skills format" undersells what was actually adopted.

December 18, 2025 — Anthropic publishes the Agent Skills spec. A SKILL.md file requires exactly two YAML frontmatter fields, name and description; everything else — bundled scripts, reference docs, additional Markdown files — is optional. No SDK, no vendor library, no proprietary loader. It's a folder an agent's harness knows how to read.

Within 48 hours — OpenAI ships support in ChatGPT and Codex CLI. Not a competing .openai-skill format. The same file, the same frontmatter fields, the same folder convention.

By March 2026, roughly 12 weeks later — around 30 agent products support it: Codex CLI and ChatGPT (OpenAI), Copilot (Microsoft), Cursor, JetBrains' AI tooling, Gemini CLI (Google), Goose (Block), and Claude Code (Anthropic's own).

Same window, separate but related — Anthropic donates MCP to the newly formed Agentic AI Foundation, a Linux Foundation directed fund co-founded with OpenAI and Block. MCP itself had already crossed 97 million monthly SDK downloads and roughly 10,000 active servers by that point, up from a standing start at its November 2024 launch.

Put those two events side by side and the pattern is unmistakable: the industry converged on one protocol for how an agent calls a tool, and separately — in the same quarter — converged on one packaging format for how an agent learns a workflow. Those are different problems. MCP tells an agent how to reach a Postgres instance or a deploy API. Agent Skills tell it what to actually do once it's there: which tool to call first, what to check, when to roll back. A team betting on one of these standing alone was making a narrower bet than a team watching both converge together.

How SKILL.md Actually Loads: Progressive Disclosure​

The reason this format travels across vendor clients without friction is a specific technical property called progressive disclosure, and it's worth being concrete about it because it's the whole reason a Skill can be portable instead of a bespoke integration:

1. Discovery — at startup, the agent's harness loads only the name and description of every available Skill. A dozen Skills cost almost nothing in context, because the harness hasn't read their bodies yet.
2. Activation — when a task matches a Skill's description (say, a build just failed), the harness reads that one Skill's full Markdown body into context.
3. Execution — the agent follows the loaded instructions, optionally running bundled scripts or reading referenced files as the task demands.

Nothing in that loop is vendor-specific. There's no OpenAI SDK call or Anthropic API call baked into the format — it's a directory an agent's harness knows how to walk, which is exactly why a client built by a competitor could add support for it in 48 hours instead of months.

What Bex Would Actually Ship: A Worked Example​

Here's the deliverable this convergence unlocks. Below is a real SKILL.md for the runbook we've had on the roadmap — a pack an agent loads only when a build actually fails, not on every deploy:

---
name: diagnose-failed-deploy
description: >
  Use when a bex App's build or deploy fails. Walks through checking build
  logs, common failure classes (missing env var, migration error, port
  mismatch), and when to roll back versus fix-forward.
---
 
# Diagnosing a Failed Bex Deploy
 
1. Fetch the failing build's logs:
   `bex logs --app <app> --build <build_id>`
 
2. Classify the failure:
   - **Build step failed** (compile/install error) → check
     `app.spec.buildCommand` in the `App` CR and the last 50 log lines for a
     missing dependency or syntax error.
   - **Health check failed** (deploy succeeded, service never became ready)
     → check `app.spec.healthCheck.path` responds on the container port
     declared in `app.spec.port`.
   - **Migration error** → check the migration job's logs separately;
     do not roll back the app before checking whether the migration
     already applied partially.
 
3. Decide roll back vs. fix-forward:
   - If the *previous* deploy was healthy and the fix isn't obvious in
     under 5 minutes, roll back: `bex rollback --app <app> --to <deploy_id>`.
   - If this is the first deploy of a new app, there's nothing to roll
     back to — fix-forward is the only option.
 
4. Report back: which failure class, which action taken, and the
   resulting deploy ID.

That file works, unmodified, in Claude Code, Codex CLI, Cursor, Copilot, and Gemini CLI today. Six months ago, writing this same runbook would have meant picking one client to target — most likely Claude Code, since Anthropic's own harness was the only consumer — and accepting that a developer running Codex or Cursor got nothing. The packaging convergence is what turns "a Skill for our Claude users" into "a Skill for anyone running an agent against bex," without us writing five versions of the same instructions.

The Buy-vs-Build Math, Including the Case It Doesn't Hold​

The naive framing is "adopt SKILL.md instead of inventing our own format," but the honest version of that comparison has to account for the possibility that this convergence doesn't stay this clean.

The optimistic case is straightforward. Building a bespoke instruction format means owning a loader, a discovery mechanism, and documentation for exactly one client — the one bex writes it for. Adopting SKILL.md means writing the Markdown once and getting roughly 30 clients' worth of loaders for free, maintained by vendors with far more agent-harness engineering capacity than a deploy platform's own team.

The risk worth naming directly: what if OpenAI's implementation drifts from Anthropic's spec? Two vendors shipping the same file format in month one doesn't guarantee identical interpretation in year two. A vendor could add a proprietary frontmatter extension, support only a subset of progressive disclosure's three tiers, or eventually deprecate support in favor of something else. That's a real possibility, not a hypothetical to wave off.

It doesn't change the math, though, because of where the downside lands. A SKILL.md file is Markdown plus two required YAML fields — there's no proprietary runtime dependency to strand if one vendor's interpretation diverges. Worst case, a Skill written today keeps working in whichever clients still honor the spec as published, which — Codex CLI's 48-hour turnaround suggests — includes at least the two largest agent vendors for the foreseeable future. Best case, it keeps working everywhere.

A bespoke format bex builds instead has no floor that low: it works in zero clients bex doesn't personally maintain a loader for, today or in five years. Adopting the shared spec is the choice with a bounded downside; inventing one isn't.

Where Skills and MCP Actually Sit Relative to Each Other​

It's worth being precise that these solve different halves of the same problem, because they get conflated. MCP is the connection — it's how an agent reaches bex's control-plane API at all: deploy, rollback, get_build_status as callable tools. Agent Skills are the workflow knowledge layered on top of that connection: when a build fails, check logs first, classify the failure, decide rollback versus fix-forward, in that order.

Bex already exposes an MCP surface for exactly this kind of agent-driven operation. A Skill like the one above doesn't replace that surface or duplicate it — it's the runbook that tells an agent how to actually use the tools MCP already exposes, loaded only in the narrow moment a build fails instead of occupying context on every healthy deploy. The two standards converging in the same quarter isn't a coincidence so much as two halves of the same "agents operate infrastructure" problem finally getting settled at the same time.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.