Agent-Native Apps
//THE OPEN SPECIFICATION

The agent-native app specification

The agent-native app specification is the open standard for agent-native applications: the package format, the agent card, the constitution hash, declared data custody, and Host bindings. It defines what an ANA is so that any builder can create one, any user can inspect one, and any compatible Host can mount one. It is authored in public by Emergent Technologies.

Last updated: 2026-08-07

What the specification covers.

01

Package format

The portable unit itself: structure, versioning, and provenance, so a published app is one inspectable artifact rather than scattered configuration.

02

Agent card

The manifest. Identity, domain role, declared tools and bindings, data custody, and compatibility requirements, readable before anything runs.

Definition
03

Constitution hash

A cryptographic fingerprint of the app's governing rules. An immutable anchor for a given version: if the constitution changes, the hash changes.

Definition
04

Declared data custody

Who holds which data, stated as a verifiable field rather than buried in a policy page. Custody is part of the contract.

Definition
05

Host bindings

How the package connects to Hosts. MCP is a supported binding. Adapters connect the same package to compatible Hosts without forking the app.

Definition

Where the specification stands today.

Honestly: in open drafting. The vocabulary on this site is stable and citable. The normative document is being written and revised in public, and we publish artifacts as they reach draft status, on the standards track we are building toward. When draft artifacts publish externally, this page links to them.

What is not live yet, and is described everywhere on this site as roadmap: the conformance validator, the registry, the certification program, and the marketplace. We name them because they're the plan, and we date nothing we can't ship.

Prior art, credited.

Builder.io's writing on agent-native architecture, CopilotKit's agent-native framework, and Every's essays on software in the model era all precede this specification and inform it. They describe patterns and tooling; the specification formalizes the artifact and its lifecycle. A standard that pretends it has no ancestors isn't a standard, it's a press release.

How to follow or participate.

Two doors. If you want to watch the specification develop, follow the dispatch: every substantive change ships as a discovery. If you want to build against it and shape it with real usage, join the builder list and tell us what you're building.