Chapter 15: The Enterprise Agent Blueprint
"Most technology failures in organisations are not technical failures. They are ownership failures. Nobody knew whose job it was. The blueprint solves that problem before the technology has a chance to create it."
Chapter 14 established why the enterprise agentic era arrived when it did, who the central figures are, and which platforms and models apply to which organisational contexts. It left one question deliberately unanswered: what, precisely, is a Cowork plugin? What does it contain, who builds each part of it, and what keeps it operating reliably once deployed? This chapter answers those questions in full.
A Cowork plugin is a bundled package that contains everything a domain agent needs: SKILL.md files that encode the expertise of the knowledge worker, MCP connector declarations (.mcp.json) that wire the agent to enterprise systems, slash commands, agents, hooks, and a manifest (plugin.json). The knowledge worker's contribution is the SKILL.md — the intelligence layer that carries institutional knowledge. Everything else is infrastructure built by developers, the community, or Anthropic. An administrator governs the deployment through organisational settings. These layers are independent by design, and that independence is what makes the system maintainable, diagnosable, and scalable.
This chapter describes the anatomy of a Cowork plugin in terms a knowledge worker can act on. It explains the three-level context system that determines which instructions the agent follows. It walks through a complete, annotated SKILL.md so you can recognise the difference between a production-ready file and an amateur one. It maps the MCP connector ecosystem available for the major professional domains. And it covers the governance mechanisms — permissions, audit trails, shadow mode, and human-in-the-loop gates — that make enterprise deployment of autonomous agents defensible in regulated industries. By the end, you will have the architectural vocabulary that Chapter 16 assumes.
📚 Teaching Aid
What You'll Learn
By the end of this chapter, you will be able to:
- Define a Cowork plugin precisely and name the key components of a plugin package and their respective owners
- Explain the Persona–Questions–Principles Framework — Persona, Questions, and Principles — and describe the function of each section
- Understand the plugin infrastructure: the manifest (plugin.json), connector declarations (.mcp.json), commands, agents, and hooks
- Explain what MCP connectors do conceptually, identify which production connectors exist for your domain, and describe the failure mode when a connector becomes unavailable
- Trace the three-level context hierarchy (platform → organisation → plugin) and diagnose why a SKILL.md instruction might not be honoured
- Distinguish a production-ready SKILL.md from an amateur one using concrete quality signals
- Describe the four governance mechanisms and state the shadow mode protocol for transitioning to autonomous operation
- Map the three-way ownership model and assign any plugin issue to the correct responsible layer
- Distinguish vertical skill packs from connector packages in the marketplace and assess whether expertise is publishable
Lesson Flow
| Lesson | Title | Duration | What You'll Walk Away With |
|---|---|---|---|
| L01 | What a Plugin Actually Is | 20 min | A precise definition of a Cowork plugin and its plugin package structure |
| L02 | The Intelligence Layer — SKILL.md | 30 min | Understanding of the PQP Framework and why each section matters functionally |
| L03 | The Plugin Infrastructure | 25 min | Understanding of the manifest, connectors, and what happens when infrastructure fails |
| L04 | The Three-Level Context System | 20 min | The diagnostic sequence for understanding why an agent behaves as it does |
| L05 | The PQP Framework in Practice | 30 min | The quality signals that distinguish a production-ready SKILL.md from an amateur one |
| L06 | The MCP Connector Ecosystem | 25 min | A map of production connectors for your domain and the process for commissioning custom ones |
| L07 | The Governance Layer | 30 min | The four governance mechanisms and the precise shadow mode protocol |
| L08 | The Division of Responsibility | 20 min | The three-way ownership model and how to assign any problem to the correct layer |
| L09 | The Cowork Plugin Marketplace | 20 min | The distinction between vertical skill packs and connector packages, and the publishing path |
| L10 | Chapter Summary | 15 min | Synthesis of the full plugin architecture, ready for Chapter 16 |
| Quiz | Chapter Quiz | 50 min | 50 questions covering all ten lessons |
Chapter Contract
By the end of this chapter, you should be able to answer these five questions:
- What are the key components of a Cowork plugin package, and who owns each one?
- What are the three sections of the PQP Framework, and what does each section define?
- How does the three-level context system determine which instructions are honoured, and what is the diagnostic sequence when a SKILL.md instruction is overridden?
- What is shadow mode, and what is the standard protocol for transitioning from shadow operation to autonomous operation?
- What distinguishes a vertical skill pack from a connector package in the marketplace, and what makes expertise publishable rather than proprietary?
After Chapter 15
When you finish this chapter, your perspective shifts:
- You see the architecture. A Cowork plugin package is no longer a black box. You can look at any deployment and identify which component governs which behaviour, who owns it, and where to look when something goes wrong.
- You own your layer. You understand that the SKILL.md is yours — not a developer's, not a platform's — and that the quality of the agent's expertise is a direct function of how well you have written it.
- You diagnose before you escalate. When an agent behaves unexpectedly, you run the three-level diagnostic before concluding there is a bug. Most unexpected behaviour has a configuration explanation.
- You govern by design. You understand that shadow mode, audit trails, and human-in-the-loop gates are architectural features, not optional additions — and that deploying without them in a regulated environment is not a shortcut but a liability.
Start with Lesson 1: What a Plugin Actually Is.