The Behaviour-Change Tax Is Killing Most AI Rollouts. Claude Skills Are the First Real Team Operating System

AI rollouts aren't failing because of the AI. They're failing because leadership keeps reaching for the same two levers that bump against the barriers of change management: throw more money at tools, run more training.

Both look good in a board pack and have the right intent. Neither moves what actually has to move: what happens inside the workflow itself.

Across dozens of projects we've worked inside in New Zealand and Australia, the pattern is brutally consistent.

That's the real tax on every AI rollout most mid-market businesses face.

The behaviour-change tax: the assumption that 80 people will open a different tool, trust the output, and route work through it by Tuesday. They don't, and they were never going to because these aren't the roles they were hired for. To be super clear, general AI training to become AI fluent is much needed, it's a core skillset every worker to be relevant moving forward, but more training doesn't change the way work gets done. The tax is structural, and the only way past it runs through not building it into the rollout.

Late in 2025 Anthropic shipped Skills (write up here for how Skills work) across its Team and Enterprise plans. On the surface people often think they're similar to custom GPTs or a Copilot declarative agent. Underneath, it isn't the same thing in any way, shape or form.

A Skill is invoked automatically by Claude. The user doesn't need to pick it from a menu, although they can via slash command ('/').

Anthropic calls this progressive disclosure: only names and summaries load at session start, and the right Skill loads when the request matches.

The practical effect is that expertise, workflows and tools (the AI component) find the person, rather than the person having to go find the 'AI'.

That single shift is the one thing no other mainstream primitive does today. Custom GPTs, Gemini Gems, Copilot declarative agents all sit inside the same pattern where I need to actively seek out the aforementioned tool. Skills are the first shared-assistant primitive where Claude does the reaching for the user, not the user for the AI.

That isn't to say GPTs / Agents / Gems are wrong, by the way. These tools fit structured task work with structured input and output. Skills fit expertise showing up organically across unstructured work. Most mid-market businesses pay for the platform already, and have both kinds of work running side by side. This isn't necessarily a swap conversation, it's a "which primitive is missing from the stack" discussion.

Once expertise flows organically through the chat interface people already use, it stops mattering whether certain colleagues, specialists and knowledge are readily available (or in the room).

A Skill can help one person run a personal workflow, and that's the obvious version (more here if you need an explainer). Not the interesting one.

The interesting version most leaders haven't seen yet and are questioning is that Skills are the connective tissue between teams.

Four live examples from work my own team at Allexive has built:

The pattern across all four is the same. Expertise gets authored once by the owner, invoked automatically inside work people already do, and connected to existing systems of record through MCP. The data perimeter stays the one the team already works inside. Not the old "paste confidential docs into external chat" problem.

The deeper shift is also worth calling out. Expertise that lived in meetings, DMs, coaching sessions, and "quick syncs" moves into infrastructure. Specialists stop being the bottleneck on access to their knowledge, and become the architects of how it flows.

Forrester's Copilot Reality Check (Feb 2026) put most enterprises 12 to 18 months from scaled deployment. Gartner's most recent IT leader survey (Aug 2025) had around 15% actively piloting autonomous agents. Enterprise IT moves at the speed its governance committees allow. Not a criticism of any individual CIO, more the nature of 200-stakeholder decisions they are required to navigate.

The opposite pattern is showing up in the NZ/AU mid-market. Businesses in the 20 to 300 person range already paying for Copilot and ChatGPT are picking up the phone and asking about Anthropic specifically. They connect Skills into Slack, M365, Google Workspace, HubSpot, and Xero through MCP. No twelve-month procurement cycle, and governance runs through Team and Enterprise admin controls. The security baseline is what leaders would expect: SOC 2 Type II, ISO 27001, zero-data-retention options on the right tier.

The asymmetry is genuinely big. When a large enterprise finishes its Copilot pilot review in late 2027, a mid-market operator who started in 2026 already has eighteen months of encoded institutional knowledge compounding. A gap that is difficult to close.

Building a Skill is easy. The file can stand up in a morning, which is the trap. Anthropic even provides an out-of-the-box 'Skill-creator' for anyone to talk to in natural language to explain their workflow.

The real work is the context architecture the Skill sits on top of.

A Skill is best thought of as an orchestrator. In simple terms, its job is to call the right tools and pull the right context at the right moment.

The harder truth is that if the knowledge underneath is a mess, the Skill returns wrong information or breaks quietly. A mess means duplicated files, no frontmatter (fancy word for properties / meta attributed of a file, typically markdown files, which agents prefer to work with), overlapping Skills pointing at stale context (e.g. your sales process updates → if that's loaded into an individual Skill, that doesn't scale to other Skills that need to access your sales process guide), and authentication wired up badly. Multiply across 500 Skills and 20 teams, and the result is institutional confusion with a chat interface on top.

Per the above sales process example, the single biggest mistake is loading huge blocks of context directly into the Skill file itself. It works fine on day one, and six months later the business has evolved, the context has gone stale, and every Skill referencing it quietly returns the wrong answer. The right approach is modular, and keeping the Skill evergreen. Let the underlying knowledge (pricing, onboarding playbooks, proposal language, escalation rules) live in a maintained wiki-style structure. YAML frontmatter, single purpose per file. Update the file once, and every Skill that references it stays current.

Portability is important here too. The institutional knowledge that makes a business distinctive lives in markdown files and YAML, inside the system of record the business already runs. Orchestration can be rebuilt on a different platform (e.g. ChatGPT's Codex, or a new harness agent toolset) if the market shifts in three years.

The knowledge architecture invested in doesn't evaporate. The thing most teams are building on custom GPTs or declarative agent libraries does evaporate (or a real pain to migrate to another platform). Seeing that ahead of time, and designing for it, is the bit that genuinely takes some experience.

Lastly, and most importantly, creating learning loops. If someone uses a Skill and it provides a response that's 80% of the work, that's a win itself compared to the traditional workflow. Yet, why not improve the underlying Skills or its context on the fly to improve it for the next user? Easily done using various techniques within Skills.

A five-minute readiness check before budget gets approved for a Claude license to build a single Skill.

If the honest answer is "in a Drive folder somewhere, or the last person who knew left", the business isn't ready to build Skills. It's ready to first build the knowledge layer Skills will sit on.

The challenge is that layer is the genuinely hard, unsexy work of a team operating a system. Everyone talks about the Skills layer because it's the visible bit. The knowledge layer underneath is the part that has to be there first for any of it to compound.

The second question to ask: every Skill is authored alongside the specialist who owns the knowledge, not for them. It has to sound like how the specialist actually thinks. Questions they ask, signals they watch for, templates they start from, places they push back.

A thirty-minute recorded conversation or a video recording of their workflow workflow pumped into Gemini to review the video and create a step-by-step guide, where the specialist thinks out loud through a real problem, is most of the Skill. The underlying files are the rest. That investment pays back inside the first week, and your teams will start feeling the power of AI as it materialises in-front of them in their current workflow. The first-pass pile blocking the specialist's Monday clears overnight, and the time comes back as hours every week, not fuzzy future ROI.

The last question decides whether any of this compounds. What would specialists do with the hours this gives back, if they stopped being the bottleneck on access to their own knowledge? If the honest answer is "higher-value work we haven't been able to get to", the business case has already made itself. The catch is being specific about what that really means, are we focused on doing More, New or Better? More here on that.

Mid-market businesses starting now on a properly architected knowledge base will have eighteen months of compounding institutional knowledge by the end of 2026. They'll have removed the behaviour-change tax, turned specialists from bottlenecks into architects, and done it through the same chat interface everyone already uses.

The two levers most leaders are still reaching for can't get a business there. The one that can has been sitting quietly next to them for about six months.