Agent-Native Apps
//THE AGENT-NATIVE DISPATCH

Why we are defining the agent-native app in public

Last updated: 2026-08-07

This is the first dispatch, so it should answer the obvious question: why does a company that wants to build products spend its first public move on a definition?

Because the category is forming right now, and it is forming vaguely. Agent-native gets used to mean a UI framework, an architecture pattern, a directory listing, and a mood. All of those usages point at something real. None of them gives a builder a contract to build against or a user a package they own. A definition precise enough to test is the cheapest piece of infrastructure a category can get, and someone has to write it down.

So we wrote it down: an agent-native application is a portable, inspectable, user-owned package that gives a capable AI model its identity, judgment, governance, workflows, and durable state. Every word in that sentence is load-bearing, and the explainer on this site walks through it clause by clause.

What we deliberately did not launch: a marketplace, a registry, a certification badge. Those are on the roadmap, in that order, and they only mean something if the specification underneath them earns adoption first. Shipping the trust layer before the standard would be selling inspection stickers for a building code that doesn't exist.

What building in public commits us to is simple and uncomfortable: the record. When the definition changes, this dispatch says what changed and why. When something we build against the spec fails, the failure gets written up with the same care as a win. A standards author's only real asset is being worth citing, and you don't get cited for press releases.

Next dispatch: what we learn taking the first real app from package to mount. If you're building something in this shape, the builder list is where to say so; what real builders need decides what we ship next.

Get the next one when it exists.