LegionEdge
All articles
PerspectiveJun 26, 20261 min read

AI-native applications need protocols, not plugins

Plugins bolt intelligence onto software built for humans. Protocols let software and models meet halfway.

CategoryPerspective
PublishedJun 26, 2026
Reading time1 min
Sections01
SourceField guides
00

Overview

The first wave of AI features shared a shape: take an application built for humans, bolt a model onto the side, and route its output through interfaces designed for hands and eyes. That's a plugin. It works, briefly, and then you hit the ceiling.

The ceiling is structural. A model driving a human interface pays a translation tax on every interaction — screenshots parsed back into meaning, generated text re-parsed into structure, state guessed from pixels. Every hop loses information and burns tokens.

A protocol removes the hops. When an application exposes its state as a structured, validated representation — a component tree, a typed context interface, a scoped file view — the model reads and writes the same structure the application uses internally. Nothing is guessed; everything is checkable.

This is the bet behind our protocol research: the Virtual DOM Protocol gives models a UI representation they understand natively, the Model Context Protocol structures what applications feed them, and the W0rkTree Protocol scopes source control to what a task needs. Same idea, three surfaces.

The practical difference shows up in our own products. Nokuva doesn't screenshot a browser to check its work — it verifies a VNode tree against a spec. The efficiency gains aren't an optimization; they fall out of the architecture.

Plugins were the right way to explore. Protocols are the right way to build. The specs are open — the whole point of a protocol is that nobody owns the interface.

Read next

All articles

Putting this into practice?

Articles are practical guides from teams running AI-native tooling in production. If you're weighing an approach, the people who wrote them will talk it through.