Protocols are horizontal. Products are vertical.

A protocol solves a general connectivity problem: how do you make A talk to B in a standard way? Once the protocol exists, anyone can build tools that speak it. The protocol itself doesn’t care what domain you’re in or what problem you’re solving. It’s infrastructure.

But the products built on that infrastructure aren’t infrastructure. They solve specific problems for specific people. They know things the protocol doesn’t — the vocabulary of a particular field, the workflow practitioners actually follow, the output format that makes sense for the job being done.

This distinction matters for understanding where value accumulates when a new protocol lands.

When a new connectivity protocol gets adopted, there’s usually a wave of generic tools first.

Developers build the obvious implementations: “connect your AI to your files,” “query your database with natural language,” “access web content from your assistant.” These tools are useful, they’re easy to build because the problem domain is clear, and they attract attention because the category is new.

But generic tools have a ceiling. They work for everyone at a surface level and for no one at a deep level. The person who needs generic file access is well served by a generic file access tool. But the person who needs domain-specific synthesis — specific document types, specific output formats, specific professional vocabulary — isn’t served by the generic tool. The generic tool gives them raw access. They still have to do the hard work of synthesis themselves.

This is where vertical products emerge.

Vertical products know the domain. They know that a specific category of professional document follows a specific structure. They know the questions that matter for this type of analysis. They know what output format is actually useful — not “a summary,” but a specific structured output that plugs directly into an existing workflow.

That knowledge isn’t in the protocol. The protocol provides the connectivity layer. The vertical product provides the domain intelligence layer on top.

The domain intelligence layer is what’s hard to build and hard to copy.

A generic file access tool can be built by anyone who understands the protocol spec — which is public and well-documented. A vertically-specific synthesis tool requires understanding the domain at the level of a practitioner: what questions matter, what makes an analysis credible to this audience, what gets missed if you skip certain steps.

That knowledge accumulates through attention and iteration, not through reading specs. It’s the kind of thing that improves as more users use the tool and give feedback, and it’s harder to replicate than the code itself.

The other reason vertical products have durability: they embed in professional workflows.

A generic tool is adjacent to the workflow. A practitioner uses it when they want to do something the tool supports, then returns to their existing process.

A vertical product is inside the workflow. It’s part of how the practitioner does the job. When it improves, they get faster. When it fails, they’re blocked. That level of integration creates a very different kind of stickiness than a generic utility.

The switch decision for an embedded workflow tool isn’t “is there a better tool?” It’s “is the better tool worth disrupting my process to adopt?” That’s a much higher bar.

Protocols win by becoming ubiquitous. Products win by becoming indispensable.

The protocol creates the opportunity. But the opportunity isn’t to own the protocol — that’s already done. The opportunity is to build the layer on top that knows something the protocol doesn’t: what a specific professional needs, in their specific context, done in their specific way.

Generic tools capture early attention. Vertical products capture lasting value.