We rebuilt the same agent skill three separate times this quarter. Once for a client running Claude Code, once for a team on Cursor, once for a Grok bot pilot. Same task, same logic, three incompatible formats. That is not a one-off annoyance. It is the actual state of AI agent tooling right now, and it changes how we scope every automation project for a 10 to 50 person company.
The fragmentation nobody warned operators about
Every serious AI coding and agent tool now ships something it calls a skill. Claude Code has skills. Cursor has its own tool and rules format. Grok's agent bot has a version too. On paper this sounds like progress: reusable, packaged capabilities instead of one giant system prompt. In practice, a skill you write for one tool does not run in another. The folder structure is different, the way instructions get loaded is different, the way tools get registered is different. You are not copying a file across platforms. You are rebuilding it.
This matters more than it sounds like it should, because most operators assume that once they have paid to build an AI workflow, it is portable. It is not, at least not yet. Anthropic's own documentation for Claude Code skills describes a specific format built around a SKILL.md file plus supporting scripts and resources, designed to work across Claude Code, the Claude apps, and the API (see Anthropic's skills documentation and the original Agent Skills announcement). That is genuinely useful if you are staying inside Anthropic's ecosystem. It solves nothing the moment a client wants the same automation running against a different model or a different coding agent.
What actually differs between these tools
The differences are not cosmetic. They show up in three places: how a skill is packaged, how the model decides to invoke it, and how much context budget it eats before your actual task even starts. Claude's models, for reference, run with context windows large enough to hold substantial reference material alongside a skill definition, which is documented directly on Anthropic's model overview page. Other harnesses budget that differently, which means a skill tuned for one tool's context handling can behave worse, not just differently, when it is ported.
| Layer | Claude Code | Cursor | Grok agent |
|---|---|---|---|
| Skill packaging | SKILL.md plus resource folder | Rules and project instructions files | Learned via task demonstration or config |
| Invocation | Model decides when to load a skill | Rules applied per context or always-on | Bot-specific task and tool config |
| Portability today | Native across Claude surfaces | Not directly compatible | Not directly compatible |
The underlying protocol layer, the Model Context Protocol that lets an agent call external tools and data sources consistently, is the closest thing to a shared standard right now (see the Model Context Protocol specification). MCP solves the tool-calling handshake. It does not solve the skill format problem, which sits one layer up, in how the reasoning and instructions themselves get packaged.
The infrastructure ceiling nobody budgets for
Portability is the first wall. The second one hits agencies and internal teams once they are running several client or department environments in parallel. We have watched this pattern directly: a team self-hosting agent environments on their own container infrastructure runs fine for a handful of clients, then hits a wall where deployment, monitoring, secrets, and access control all break down at roughly the same time. The build-vs-buy line moves earlier than most people plan for, well before the operation feels large.
The mistake is treating that wall as a scaling problem you solve later. It is a design decision you make on day one. Every AI Operations Agent or automation system we build gets scoped assuming the underlying tool will change format, get deprecated, or get replaced by something better within a year. That assumption is not pessimism. It is just the current base rate for this category, and it is the same reason we do not let clients get locked into a single vendor's proprietary skill format for anything load-bearing.
What we build differently because of this
Our answer is not to pick a winner and bet the business on it. It is to separate the two layers that keep getting collapsed into one. The business logic, the decision rules, the prompts, the escalation paths, the tone, all of that lives in plain, version-controlled files the client owns outright. The harness-specific wiring, the part that actually talks to Claude Code or a browser agent or a voice pipeline, is a thin adapter on top. When a platform changes its skill format, we update the adapter. The logic underneath does not move.
- Core prompts and decision logic live in a client-owned repo, not locked inside one vendor's proprietary skill format.
- Every automation gets a written escalation boundary: what the agent handles alone, what it flags for a human, mirroring the read-review-permission split that any serious agent setup needs.
- We default to managed infrastructure until usage numbers force a real build-vs-buy conversation, not before.
- Clients keep 100% of the code and files, so a tool swap is a migration, not a rebuild from zero.
This is the same discipline behind our automation builds and the voice agent systems we ship: the first working version goes live in days to weeks, not months, precisely because we are not waiting on a platform to standardize anything. If a client's admin team is currently burning 10 or more hours a week on manual follow-up and handoffs, that is exactly the layer we target first, independent of which underlying tool ends up running it.
What to do this quarter
If your company is running or planning any agent-based system, three moves protect you regardless of which tool wins the format war.
- Audit what is currently locked inside one tool's proprietary skill or rules format, and separate the reusable business logic from the platform-specific wrapper.
- Write your core prompts and decision rules as plain files you control, not buried inside a vendor's UI or config you cannot export.
- Before adding another self-hosted environment, run the numbers on managed infrastructure. The point where self-hosting stops paying off arrives earlier than most teams expect.
- Treat every AI agent handling a live channel, like inbound leads, the same way you would treat a new hire: a clear read/write boundary, and a human in the loop for anything touching money, contracts, or production data.
None of this requires guessing which company wins the agent tooling race. It requires building so that whoever wins does not matter as much as it currently feels like it should. We run this exact playbook on our own product line and in every client build, and it is the first thing we check in a luup assessment, which starts at €999 and is credited straight into the build if you move forward. If you want a fast read on where this kind of fragmentation is already costing your team hours, our revenue leak heatmap is a free way to see it mapped against your actual funnel before you commit to any one tool's ecosystem. The tools will keep changing shape. The business logic underneath them should not have to.
We keep coming back to the same rule with every client engagement, whether it is a voice pipeline, a lead-response agent, or an internal ops assistant covered in our broader blog: build the thinking once, own it completely, and treat every specific tool as a replaceable front end. That is the only version of this we have seen hold up when a platform changes its rules six months into a build.