--- title: Protocol Over Tool synced_from_vault: true vault_source: 03-living-docs/patterns/Protocol-Over-Tool.md public: true type: pattern category: design-philosophy tags: - pattern - architecture - protocol - interoperability created: 2026-02-19T00:00:00.000Z --- ## Core Concept When you find yourself building a tool that bridges two systems, stop and ask: **should this be a protocol instead?** A tool solves your problem. A protocol solves a category of problems. The effort to build either is often similar, but a protocol compounds — it lets other people solve their own version of the same problem without you. --- ## The Two Approaches | | Build a Tool | Build a Protocol | |-|-------------|-----------------| | **Solves** | Your specific problem | A category of problems | | **Integration cost** | N tools x M systems = N*M integrations | N tools x 1 protocol + M adapters = N+M integrations | | **Who benefits** | You | Everyone with the same problem | | **Adoption** | You use it | Others can adopt independently | | **Extensibility** | You maintain every integration | Others write their own adapters | | **Lock-in** | Tied to your architecture | Architecture-agnostic | The math is the key insight: **N*M vs N+M.** Five agents and four PM systems is 20 bespoke integrations or 9 protocol-conforming pieces. At scale, the protocol wins by orders of magnitude. --- ## When to Reach for a Protocol Not everything should be a protocol. Use this heuristic: 1. **Multiple producers and consumers exist** — if only one system will ever serve this data and one system will ever consume it, a direct integration is simpler 2. **The schema is more stable than the systems** — "a unit of work has a title, status, and description" is stable. Specific PM tools come and go. 3. **You'd otherwise build the same adapter twice** — the moment you think "I need a Linear integration AND a Jira integration," you need a protocol 4. **Interoperability is a feature, not an accident** — if you want other people to plug into your system (or you want to plug into theirs), a protocol is the only way ## When NOT to Reach for a Protocol 1. **You're the only consumer.** A protocol with one adapter is an over-engineered tool. Build the tool, extract the protocol later if demand appears. 2. **The problem is too novel.** You don't know the right abstractions yet. Build the tool, learn, then standardize. (This is why WCP starts as a tool and becomes a protocol in Phase 3.) 3. **Speed matters more than interoperability.** Ship the direct integration, refactor later. --- ## Intellectual Ancestry **TCP/IP** — didn't try to be a better network. Defined how ANY network could talk to any other network. Every proprietary network protocol lost. **HTTP / REST** — didn't try to build a better file transfer tool. Defined how any client could talk to any server. The web is a protocol, not a product. **LSP (Language Server Protocol)** — Microsoft didn't build a better IntelliSense for every editor. They defined how any editor could talk to any language server. One protocol replaced hundreds of editor-specific integrations. **MCP (Model Context Protocol)** — Anthropic didn't build integrations between Claude and every tool. They defined how any model could talk to any tool server. Same pattern. **RSS** — a protocol for "here's what's new." Simple, decentralized, composable. Worked for two decades despite every platform trying to replace it with proprietary feeds. --- ## Where I've Seen It - **WCP (Work Context Protocol)** — the originating insight. Instead of building a Linear integration for pipeline-skills (ROAD-08), build a protocol for work context that any PM system can serve and any agent can consume. The filesystem-backed MVP is the reference implementation. A Linear adapter comes later. The protocol IS the product. - **[Augmentation-Over-Automation](/patterns/augmentation-over-automation)** — related but different axis. Augmentation is about human/machine collaboration design. Protocol-over-tool is about system interoperability design. Both are about designing the *interface* rather than the *implementation*. --- ## The Trap: Premature Protocol The biggest risk is designing a protocol before you understand the problem. Every failed XML schema and abandoned W3C spec is evidence of premature standardization. The antidote is **Phase 1 → Phase 3 thinking:** 1. **Build the tool you need.** Use it. 2. **Discover what's stable** (the schema) vs. what's incidental (the storage, the UI). 3. **Extract the protocol** from what survived real use. This is why successful protocols almost always come from working implementations, not committee specifications. HTTP came from Tim Berners-Lee's working hypertext system. MCP came from Anthropic's working tool-use infrastructure. WCP should come from a working task tracker. --- ## Cross-References - [Augmentation-Over-Automation](/patterns/augmentation-over-automation) — companion pattern (human/machine interface design) - [Software-Laws](/patterns/software-laws) — Zawinski's Law, Gall's Law (complex systems that work evolved from simple systems that worked) - [Integration-vs-Composition](/patterns/integration-vs-composition) — protocols are compositional by nature; the tension between integration and composition is resolved by choosing protocols - [Context-Over-Interface](/patterns/context-over-interface) — same structural insight applied to AI workflows: the context layer (protocol) beats the input device (tool) because it's composable across any interface