Anthropic released Claude Skills. Then Plugins. Then Connectors. Then managed Agents - all within a relatively short window.
If you're a developer, this is exciting. You read the docs, spin up a proof of concept, and by the afternoon you've wired together something interesting. You iterate. You break things. You try again. That's the job.
If you're a Finance Director, a Head of Operations, or a VP of HR - this is not exciting. This is anxiety-inducing.
Not because the technology isn't impressive. It clearly is. But because adopting it isn't a technical problem. It's an organizational one.
The gap between capability and adoption
There's a pattern playing out right now that the AI industry keeps glossing over.
On one side: a rapid, compounding release cadence. New primitives, new APIs, new product surfaces, new paradigms. Each one genuinely useful. Each one requiring a different mental model to understand what it is, when to use it, and how it fits with everything that came before.
On the other side: businesses that run on processes. Processes that have been refined over years. Processes that touch multiple teams, multiple systems, and multiple people whose jobs depend on understanding exactly what is expected of them and when.
Changing a process is not like updating a library. You don't just merge a PR and redeploy. You document it, you communicate it, you train people on it, you handle the exceptions, you manage the anxiety of the people whose routines are being disrupted. Then, three months later, you do it again - because there's a new capability that changes the calculus.
The developer can absorb a new paradigm in a weekend. The organization cannot.
The "junior engineer" problem
There's an implicit assumption in how AI tools are being marketed to businesses: that the people who will use them are willing and able to think like engineers.
Configure your workflow. Set your system prompt. Define your tool calls. Connect your MCP server.
For a CTO, this is a Tuesday. For a controller at a mid-sized accounting firm, or an operations manager at a logistics company, or a compliance officer at a bank - this is asking them to become something they are not, and something they were not hired to be.
This isn't a criticism of those people. It's a criticism of the assumption. Most of the value in an organization sits with people who have deep domain expertise - who know exactly how accounts receivable works in their industry, or what a clean audit looks like, or how to handle a vendor dispute - but who have zero interest in becoming junior engineers.
The gap isn't capability. The gap is translation.
What's actually needed: domain expertise meets AI expertise
The companies that successfully implement AI across departments are not doing it by training everyone to understand the technology stack. They're doing it by finding - or building - people and partners who can sit in the middle.
People who understand the domain deeply enough to know which processes are worth changing and which ones shouldn't be touched. And who understand the AI stack well enough to know which primitives to reach for and how to compose them into something a non-technical person can actually use.
This is, historically, what good systems integrators and implementation partners have done. The difference is the speed of the underlying platform.
A firm that implemented SAP in 2005 could build expertise in that system and deploy it for clients for a decade before the platform changed in any meaningful way. The implementation methodology could stabilize. The playbook could mature.
Today, the platform changes every few weeks. The Skills model ships. Then Plugins. Then managed Agents. The implementation partner doesn't just need domain expertise and technical expertise - they need to be continuously learning a platform that is itself in rapid evolution.
That's a new kind of professional. And there aren't enough of them yet.
Speed is a feature for developers. It's a tax on businesses.
This is the uncomfortable truth.
Anthropic's release velocity is, from a developer's perspective, a competitive advantage. More capabilities, faster. More surface area for builders to work with. An accelerating platform is an exciting platform to build on.
From a business's perspective, that same velocity is a carrying cost. Every new release is a decision: do we evaluate this? Do we pilot it? Do we wait until it stabilizes? Do we rebuild the thing we just finished building on the previous version?
Most businesses, rationally, choose to wait. Not because they're slow or resistant to change. But because the cost of changing a process - the training, the communication, the exceptions management, the productivity dip during transition - is real and measurable. The benefit of a new AI primitive, for a non-technical operator, is abstract until someone builds the bridge.
The bridge-builders are the opportunity.
What this means if you're in services
If you're an accounting firm, a law firm, a consulting practice, an operations consultancy - the businesses that sell domain expertise in some form - you are sitting on a significant and underpriced asset.
You already know the processes. You already have the client relationships. You already understand where the pain is. You just need the AI fluency to translate that knowledge into the new stack.
The firms that figure this out early won't just be delivering services differently. They'll be building proprietary capabilities - Skills that encode their methodology, Plugins that automate their most repeatable workflows, Agents that handle the high-volume work overnight - that become a structural advantage over competitors who are still doing everything manually.
The firms that don't figure this out will face a different problem. Not that AI will replace them directly. But that a competitor with the same domain expertise and better AI fluency will be able to serve twice as many clients, at the same quality, for a lower cost. The math on that gets uncomfortable quickly.
The window is real, but it's not infinite
There's a window right now where the gap between AI capability and business adoption is wide. Businesses need help. The help doesn't exist at scale yet. The people who can provide it - who can sit between the platform and the organization and translate - are scarce.
That gap will close. The platforms will mature. The tooling will simplify. The abstractions will get better. At some point, implementing AI across a finance department will be as routine as implementing a new accounting system.
But right now, it's not routine. It's complex, it's fast-moving, and it requires a kind of expertise that most organizations don't have internally.
The businesses that find the right partners now - and the partners who build genuine depth in both domain and AI - will be the ones who end up ahead when the gap closes.
Everyone else will be catching up.
The hardest part of AI adoption in most organizations isn't the technology. It's the change management, the process translation, and the organizational trust required to hand work to a system that wasn't there last quarter. If you're working on that problem - from either side - I'd like to hear how you're approaching it.