By Michael Domenic, Section Head of AI

AI is inherently individual. It runs on your machine, in your context window, shaped by your prompts. That’s what makes it powerful for personal productivity, but it's also a real problem for organizations – because the value too often stays trapped with the person who built the thing.

This is one of the core challenges for any AI leader right now: figuring out how to move from individual AI wins to shared organizational capability. 

Claude's plugin feature in Cowork has changed what's possible here. A plugin lets you take something one person built and make it installable by anyone in the organization. 

For anyone unfamiliar, a plugin in Cowork is essentially a bundle of skills – instructions, data connections, and commands – that gets packaged up and published to a shared marketplace. 

Once it's published, anyone in the organization can install it in a few clicks and start using it immediately, with access to the same underlying knowledge base and the same set of commands. The person who built it maintains the logic and the data inputs, and everyone else uses it. 

How to identify work that’s ready for a Claude plugin 

Not every workflow is a good fit for a plugin. The ones that are tend to share a few qualities:

• Multiple people need the same thing. If three people on different teams are all trying to get up to speed on client accounts before meetings, that's a plugin. If one person has a personal writing workflow, that's a skill.
• The underlying data is shared, not personal. If the data source is inherently shared, the tool that accesses it should be too.
• The task benefits from consistency. When everyone needs to get information in the same format with the same depth, a plugin ensures that. Personal workflows drift over time.
• There's a maintenance burden worth centralizing. One person maintaining the knowledge base and the logic is better than ten people each building their own version of the same thing.

Our Director of CS Ops, Doug Devereaux, recently rolled out a plugin that the whole team at Section uses. Here’s how he did it. 

How to share client insights via a Claude plugin

Section serves 150+ clients, and multiple teams need to be up-to-date on their status, from CS to product to our CEO. But until now, most client intelligence was trapped in the heads of the main client contacts, which meant people were Slacking each other for updates (often at the last minute). 

At the same time, Section records many of our client conversations in Fathom. That means we have a wealth of information sitting in our call transcripts, but because Fathom’s search functionality is limited, it sits untapped.

Six months ago, Doug might have solved this problem by throwing an expensive, feature heavy CS platform at the problem. But today, he saw that this is a great fit for a Claude plugin. 

Multiple people across the company needed the same thing: current, structured account intelligence before a client conversation. The underlying data was shared via Fathom. The task benefits from consistency, because everyone needs account briefings with the same depth and format. And having one person maintain the knowledge base and the logic was clearly better than having ten people each build their own version.

The plugin went through four phases – I’m breaking them down because it’s useful to see where things broke and how Doug worked through it.

Phase 1: Connect the data. Doug connected Fathom's API via Claude Code and started pulling transcripts. Two problems surfaced quickly: Too much unstructured data created noise and inconsistent outputs, and older calls were getting equal weight to recent ones, which made results worse. 

Phase 2: Build the knowledge graph. To fix these issues, Doug built a local knowledge graph: one document per account, one per call, one per contact, all linked together and dated so recent information ranked higher. Outputs became dramatically more reliable, but the whole thing only lived on his computer.

Phase 3: Move it to Google Drive. Making it shareable meant moving it somewhere the rest of the team could access. Markdown files in Google Drive didn't work. Cowork couldn't read them and native linking between files didn't work in Drive. Doug instead translated everything into Google Docs, which Cowork could read, and rebuilt the same linked architecture there. 

Phase 4: Package it as a Cowork plugin. The obvious path was building a custom app – Doug had done it before. He decided against it because building an app means maintaining an app. The Cowork plugin model meant anyone on the team could install it, the knowledge base stays in Google Drive, and there's no codebase to maintain. 

He packaged this as a Cowork plugin with six commands:

Brief Me: Account briefing going back three to five calls, weighted toward recent conversations

Meeting Prep: Reads your calendar and briefs you for every client meeting

Voice of the Customer: Extracts verbatim client quotes on any topic or feature

Renewal Prep: Surfaces revenue signals and risk indicators

Account Status: Quick top-line summary

Who Is: Everything on record about a specific contact

What started as a CS tool is now used by Sales, Advisory, and our CEO. 

The bigger pattern

Doug is not a product manager. But building and maintaining this tool is now part of his job in a way it wouldn't have been two years ago. He owns a roadmap for the plugin the same way he'd own a vendor relationship or an internal process in the pre-AI era.

This pattern is repeating across Section and our customers. People build something useful, the whole company wants access, and the question becomes how to share it. Our CTO described it as: “We have a number of examples where people have created awesome plugins and the first question every single person asks is, how do I share this with my team?”

The line between business operator and product owner is blurring. The organizations making the most of AI right now are the ones where functional leaders are expected to cross it – and where the tooling makes that crossing possible without turning everyone into a software engineer.

Steal this idea: How to build a Claude Plugin for client intelligence

If your organization records client calls and your team uses Claude, you can build a version of this. Here's the checklist:

• Identify your data source – all recordings, CRM notes, support tickets – and confirm API and/or MCP access
• Structure the data as linked Google Docs: one per account, one per call, one per contact
• Date everything and build recency into the structure so recent information ranks higher
• Set up a nightly script to pull new data and rebuild the docs automatically (use a three-day buffer)
• Build your first skill in Claude Cowork and get it working for yourself
• Package it as a Cowork plugin – start with Brief Me and Meeting Prep as your first two commands
• Publish to your organization's marketplace

Known limitations going in: Same-day calls won't be available until the following morning. Domain mismatches between your CRM and your call tool will create gaps that need manual fixes. And the whole system is only as good as your team's recording consistency. But this is a good place to start. Let us know if it works.