What Building a Claude Plugin Taught Us About Productizing Expertise

A confession to open with: for most of our consulting life we sold hours, and we told ourselves that was a feature. Every engagement was bespoke, every client special, every invoice a small monument to how much thinking we had done on their behalf. Then we tried Claude plugin development for one of our own repeatable workflows, and the whole comfortable arrangement fell apart in the best possible way. This is a case study about what building a plugin taught us, written for anyone who suspects their expertise is more repeatable than their billing model admits.

Why We Packaged a Workflow as a Plugin

We packaged the workflow as a plugin because we kept solving the same problem twice and charging for it three times. That is a fine business until a client asks why the thing you did for them last quarter cannot simply be installed, and you discover you have no good answer.

The honest reason most experts resist productizing is that hours feel safe. A product can be judged on its own merits. An hour cannot, because by the time anyone evaluates it, it is already spent. Selling time is the consulting equivalent of refusing to be measured, and the whole industry has quietly agreed to call that professionalism.

The market is making the old arrangement harder to defend. According to McKinsey's State of AI in 2025, 88% of organizations now report using AI in at least one business function, up from 78% a year earlier. And yet only 39% say AI has made any measurable dent in enterprise profit, with most of those reporting an effect under five percent. Everyone has adopted. Almost no one has captured value. That gap is not a technology problem. It is a packaging problem, and it is exactly the gap a well-built plugin is designed to close, because a plugin ships the reliable version of a workflow instead of the heroic one-off version.

We had written about this tension before in build, buy, or both, but writing about it and living it are different animals. Building the plugin was the first time we had to decide, concretely, which parts of our expertise were repeatable enough to encode and which parts genuinely needed a human in the room.

Skills vs MCPs: The Line We Drew

The single most useful thing Claude plugin development taught us was where to draw the line between a skill and an MCP server, because that line is the line between judgment and plumbing. Skills decide. MCP does. Get that backwards and you will build something that is both fragile and confused about its own purpose.

A skill, in the Claude sense, is a directory with a SKILL.md file inside it. At the start of a session the agent sees only the skill's name and a short description, roughly a hundred tokens, and it loads the full instructions only when a task actually matches. Skills are instructions. They hold procedure and judgment, the if-this-then-that reasoning a senior person carries in their head. What a skill cannot do, on its own, is reach out and touch the world. It cannot call an API or pull a record.

An MCP server is the other half. The Model Context Protocol, which Anthropic open-sourced on November 25, 2024, is a standard way for an agent to discover and use external tools. An MCP server exposes tools, resources, and prompts over a common protocol, and the agent connects to it and asks, in effect, what can you do here. MCP is the plumbing. It is how the agent reads a database, posts to a CMS, or files a record.

The trap we fell into first was stuffing judgment into the plumbing. We tried to make an MCP tool that was clever, that decided things. It worked until it didn't, and when it broke we could not tell whether the failure was a bad decision or a bad connection, because we had welded the two together. Pulling them apart, putting all the deciding in skills and all the doing in MCP, made the whole system legible. When something goes wrong now, we know which half to look at. That legibility is worth more than any single clever feature.

The Architecture, End to End

The architecture is a library of composable skills sitting over shared state, with MCP servers as the hands. It is not an assembly line, which surprised us, because we had assumed automating a workflow meant building a pipeline with a start and an end.

In practice the pieces are these. A set of skills, each one a focused unit of judgment, holds the procedure for a single job. Shared state, a few structured files, lets those skills hand work to each other without being hardwired together. MCP servers give the agent its reach into the outside systems the workflow depends on. And a plugin wraps all of it, skills plus MCP servers plus slash commands plus subagents, into a single versioned, installable bundle. Plugins arrived in public beta in late 2025 and shipped with Claude's Cowork environment in early 2026, which is the same machinery that distributes them through marketplaces.

The composability is the part worth dwelling on. Because each skill is self-contained and reads from shared state, the agent can enter the workflow at any point. It can do step four without re-running steps one through three, because the state from those steps is already on disk. This is what lets a packaged workflow behave like a colleague instead of a macro. You can ask it to redo one thing without resetting the whole job, which is precisely the flexibility you lose with a rigid pipeline and precisely the flexibility a human expert offers without thinking about it.

This non-linear shape is not unique to us. It is roughly where the whole agent ecosystem has landed. MCP went from a single-vendor proposal to industry-wide adoption within a year, backed by OpenAI, Google, Microsoft, and AWS, and by late 2025 there were more than 10,000 active public MCP servers. The standard won because the architecture it implies, decisions in one layer and tool access in another, is simply the right way to build these things.

What Broke and What We'd Redo

The thing that broke most often was the handoff between skills, not the skills themselves, which matches an uncomfortable pattern we have watched kill other people's pilots. We wrote about that failure mode in why most agentic pilots die in the handoff, and then we went and proved the point on our own build.

Early on, two skills disagreed about the shape of the state they shared. One wrote a field one way, the next read it expecting another, and the workflow failed quietly in the seam between them. Nothing threw an error. The work just came out wrong, which is worse, because a loud failure gets fixed and a quiet one gets shipped. The fix was boring and essential. We wrote down the contract for the shared state, the exact names and shapes, and made every skill honor it. Boring contracts prevent exciting outages.

The second lesson was about images and external systems generally, which is to say about MCP's domain. Our CMS silently stripped any image whose source was not hosted on its own domain. We learned this the way everyone learns it, by publishing posts with invisible images and wondering why. The redo was to host every asset on the destination platform first and only then reference it. The general principle, which we would tattoo on the next build if skin allowed, is that an external system's quiet rules will bite you exactly once per rule, and the only defense is to encode each rule the moment it draws blood.

If we started over, we would write the state contract first, before any skill, and we would treat every external integration as hostile until proven otherwise. Both lessons are really the same lesson. The expertise worth productizing is not the happy path. It is the accumulated scar tissue of every quiet failure, and a plugin is just a convenient container for scar tissue.

Productizing Expertise Without Selling Hours

Productizing expertise means encoding the repeatable workflow and reserving your judgment for the parts that genuinely need it, not flattening everything you do into a fixed-scope box. This is the distinction that keeps productizing from becoming self-erasure.

Satya Nadella made the structural version of this argument on the BG2 podcast, when he predicted that business applications will collapse in the agent era because most of them are really just databases with business logic stacked on top, and that logic is migrating up into an agent tier. Whether or not he is right about every SaaS app, the direction is the one we felt while building. The value is moving from the interface to the encoded workflow, from the screen to the judgment behind it.

Here is the contrarian caveat, because anti-hype is the house style and the hype on this topic is thick. Not everything should be productized. When your edge is genuinely bespoke judgment, the strange, hard-won read on a specific situation, turning it into a flat product can sand off the very thing clients pay for. The resolution is not to pick a side. It is to productize the repeatable ninety percent so your scarce attention can go to the ten percent that actually requires you. The plugin does the job the same way every time. You do the part that has never happened before.

That reframing is the whole return on the exercise. Selling hours, we were paid for motion. Productizing the workflow, we are paid for the encoded result, and our hours are freed to chase the genuinely novel problems that no plugin can hold yet. The asset compounds while we sleep, which an hour has never once done.

Frequently Asked Questions

What Is a Claude Plugin?

A Claude plugin is a versioned bundle that packages skills, MCP servers, slash commands, and subagents into a single installable unit. It is distributed through a marketplace, so an entire encoded workflow can be installed in seconds rather than rebuilt per client.

When Should You Build a Plugin Instead of a Custom App?

Build a plugin when the value is a repeatable expert workflow you want to install, version, and reuse, rather than a one-off interface for a single client. If you would otherwise solve the same problem more than twice, the workflow wants to be a plugin.

How Do Skills and MCPs Work Together?

Skills hold the judgment and procedure, while MCP servers give the agent the ability to touch tools, data, and APIs. Skills decide what should happen; MCP does the reaching out and acting. Keeping the two cleanly separated is what makes the whole system debuggable.

What Is the Claude Agent SDK?

The Claude Agent SDK is the toolkit for building agents that run multi-step workflows, maintain state across steps, and call external tools or MCP servers. It goes beyond single request-and-response API calls to support agents that actually carry a job from start to finish.

What Is an MCP Server?

An MCP server is a small service that exposes tools, resources, and prompts to an AI agent over the Model Context Protocol, a standard built on JSON-RPC 2.0. It is the layer that lets an agent read from and act on external systems in a consistent, discoverable way.

References

• McKinsey, The State of AI in 2025
• Model Context Protocol: One Year Anniversary
• Thoughtworks: The Model Context Protocol's Impact on 2025
• Satya Nadella on SaaS in the Agent Era (BG2 podcast, via OfficeChai)
• Automata Intelligentsia: Build, Buy, or Both
• Automata Intelligentsia: Why Most Agentic Pilots Die in the Handoff