Agent-native app architecture

Shipper's framing is the cleanest short statement I've seen of what changes when you build for agents instead of for a UI.

The four characteristics

Parity — anything the user can do in the app, the agent can do. Not "some workflows expose an API." Everything the UI can do is reachable by the agent.

Granularity — features are prompts, not tools. The agent has access to primitives more atomic than a feature; a feature is what happens when the agent composes several tool calls together. This inverts the usual product direction: you stop defining features and start defining primitives.

Composability — because tools are atomic, the agent can combine them in ways you didn't design. Developers move faster, users customise via prompt, and — critically — the app does things you didn't plan for.

Emergent capability — the consequence of the other three. The app surfaces latent demand. Usage patterns become a roadmap input, not a retro.

Why it matters to a KMS

Most of my principles assume this posture without naming it. Routing is a tool. Compilation is a tool. Ripple sweep is a tool. The Claude primitives (skills, subagents, hooks) only earn their keep if the agent can compose them — which is only possible if every meaningful operation in the system is a primitive the agent can see.

The test I run on any KMS design: is every feature reachable as a prompt, or is some of it hidden behind a button the agent can't reach? If the latter, the architecture is not agent-native — it's a traditional app with an AI wrapper.

The uncomfortable implication

Most software I use day-to-day is not this. Most software being built right now is not this. The majority of "AI features" are a button that calls a model, not a system where the agent has parity with the user. Shipper's bar is higher than the market currently sets it.