Anthropic open-sourced 11 production plugins that show how enterprise agent systems structure domain knowledge, tool boundaries, and human handoff points. The repository exposes the plumbing behind Claude Cowork’s ability to orchestrate role-specific agents across sales, finance, legal, and product management workflows.
The repository reached GitHub trending rank 3 for Python on May 25, 2026. The architecture reveals patterns for building domain-specific agent orchestration layers on top of Claude’s API, with particular focus on how the finance plugin handles journal entries, compliance workflows, and cross-system data reconciliation.
Plugin Directory Structure
Each plugin follows a consistent layout. The README states that plugins include .claude-plugin/plugin.json for capabilities and routing, .mcp.json for MCP server configuration, and separate directories for commands/, agents/, and skills/.
The plugin.json file defines three core concepts:
- Skills: Atomic functions that call external APIs or process data
- Connectors: Authentication and session management for SaaS tools
- Commands: Slash command entry points that route to skills or sub-agents
The finance plugin bundles connectors with skills and slash commands. The routing logic lives in plugin.json, which maps user intent to execution paths.
The Pattern Across 11 Plugins
The repository includes plugins for productivity, sales, customer support, product management, marketing, legal, and finance. Each follows the same architectural pattern but with different connector sets and domain-specific sub-agents.
| Plugin | Connectors | Primary Use Case |
|---|---|---|
| Productivity | Slack, Notion, Asana, Linear, Jira, Monday, ClickUp, Microsoft 365 | Task management and calendar orchestration |
| Sales | Slack, HubSpot, Close, Clay, ZoomInfo, Notion, Jira, Fireflies, Microsoft 365 | Prospect research and pipeline review |
| Customer Support | Slack, Intercom, HubSpot, Guru, Jira, Notion, Microsoft 365 | Ticket triage and knowledge base updates |
| Product Management | Slack, Linear, Asana, Monday, ClickUp, Jira, Notion, Figma, Amplitude, Pendo, Intercom, Fireflies | Spec writing and roadmap planning |
| Marketing | Slack, Canva, Figma, HubSpot, Amplitude, Notion, Ahrefs, SimilarWeb, Klaviyo | Content drafting and campaign planning |
| Legal | Slack, Box, Egnyte, Jira, Microsoft 365 | Contract review and compliance navigation |
| Finance | Slack, Box, Egnyte, Jira, Microsoft 365 | Journal entries and risk assessment |
The README excerpt lists these seven plugins but states that 11 plugins are included in the repository. The remaining four plugins are not detailed in the provided excerpt.
The finance plugin is representative of the pattern. The same sub-agent orchestration structure appears in the legal plugin (contract review agent, compliance navigator) and the sales plugin (prospect research agent, pipeline analyzer). The architecture scales across domains by keeping the orchestration logic generic and pushing domain knowledge into skills and prompt templates.
MCP Server Configuration and Connector Integration
The repository shows that plugins use MCP (Model Context Protocol) servers. The README states that plugins are “built for Claude Cowork, also compatible with Claude Code,” indicating the MCP layer provides cross-product orchestration.
The repository includes .mcp.json files that configure how Claude Cowork connects to plugin servers. The README does not detail the protocol specification, process isolation model, or request format. The full plugin.json schema and finance plugin implementation are available in the repository but not detailed in the public README excerpt.
The finance plugin connects Slack, Box, Egnyte, Jira, and Microsoft 365. The README excerpt ends mid-sentence at “Prep journal entries,” leaving the specific finance workflows incomplete in the provided evidence.
Sub-Agent and Skill Separation
The directory structure separates agents/ from skills/. The README states that “each plugin bundles the skills, connectors, slash commands, and sub-agents for a specific job function.”
Skills are atomic tool calls that interact with external APIs. Sub-agents are execution contexts that chain multiple skills together. The README does not provide implementation details for how sub-agents invoke skills or manage state across multi-step workflows.
The finance plugin’s sub-agent architecture for journal entries and compliance workflows is not detailed in the provided excerpt. The repository structure suggests these are defined in the agents/ directory, but the specific orchestration logic and approval gates are not documented in the README excerpt.
Slash Command Routing
The README indicates that plugins expose slash commands as deterministic entry points. Commands bypass intent classification and jump straight to the appropriate sub-agent or skill. Command handlers live in the commands/ directory and parse arguments before invoking skills or sub-agents.
The specific slash commands exposed by the finance plugin are not listed in the README excerpt. The pattern suggests commands like /finance journal-entry or /finance compliance [topic] based on the stated use cases, but these are not explicitly documented in the provided evidence.
Security and Approval Gates
The README emphasizes that plugins let teams “tell Claude how you like work done, which tools and data to pull from, how to handle critical workflows.” The plugin.json schema includes declarations for which operations require human review, but the README does not detail the security model or approval gate implementation.
Expected security boundaries for the finance plugin include OAuth2 for connector authentication (standard for Slack, Box, Jira, Microsoft 365), audit logging of tool calls, and data residency controls for sensitive fields. The finance plugin, dealing with journal entries and compliance data, requires explicit approval gates before modifying financial records. The implementation details are in the plugin.json and skill definitions, which declare approval requirements per operation type, but these are not exposed in the README excerpt.
Architecture Trade-offs
| Aspect | Benefit | Cost |
|---|---|---|
| Domain-specific plugins | Clear tool boundaries, reusable patterns across roles | Requires separate plugin for each job function |
| MCP server isolation | Credential isolation, independent deployment | Added latency from inter-process communication |
| Slash command routing | Deterministic entry points, no intent ambiguity | Users must learn command syntax |
| Approval gates | Human oversight for critical operations | Workflow interruption, async execution required |
| Multi-connector workflows | Unified interface across SaaS tools | 500ms+ latency from OAuth refresh and API round trips |
The architecture assumes asynchronous operations and human intervention at approval points. Multi-connector workflows add latency due to OAuth token refresh, API round trips, and approval gate checks. The pattern works when you can define clear connector boundaries and want to avoid building monolithic agents.
Technical Verdict
Use the finance plugin if your team operates Slack, Box/Egnyte, Jira, and Microsoft 365 and wants to automate journal entry prep and compliance lookups without building custom integrations. The plugin architecture works for teams that need to orchestrate multi-step workflows across multiple SaaS tools with role-specific knowledge and approval gates.
Avoid it if your workflows require sub-100ms response times or real-time transactional consistency across systems. The architecture assumes asynchronous operations and human intervention at approval points. Multi-connector workflows add 500ms+ latency due to OAuth token refresh, API round trips, and approval gate checks.
The finance plugin is not a replacement for accounting software. It is a layer that reduces context switching between tools for tasks like journal entry preparation and compliance policy lookups. Teams building custom plugins should review the actual plugin.json schemas and skill implementations in the repository, as the README provides architectural overview but not implementation details.
The repository is a reference implementation showing architectural patterns. Production deployments will need to adapt the connector authentication, state management, and approval workflows to specific infrastructure and security requirements.