Agent-Native Apps
Specification in open drafting//AGENT-NATIVE APPLICATIONS: AN OPEN SPECIFICATION

The agent-native app is the application model for the agent era.

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. This site defines the term, publishes the open specification, and documents what we learn building them, in public.

USERownershipData and corrections · Extensions and learning · Exit rights
Agent-native app
01Identity and judgment
02Constitution and escalation
03Workflows and durable state
04Declared tools and custody
HOSTthe runtimeModel and inference · Tool execution · Permission boundary
// 01THE DEFINITION

First, the definition.

We state it once, precisely, so it can be quoted. Everything else on this site elaborates on this sentence.

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.
via agentnativeapps.com

What the Host supplies

  • General intelligence and conversation
  • Model inference and frontier upgrades
  • Tool execution and the Host's permission boundary
  • The runtime surface the app is mounted into

What the agent-native app supplies

  • Identity and domain role
  • Domain judgment and policies
  • Constitution, authority, and escalation rules
  • Workflows, artifacts, and durable state
  • Declared tools, bindings, data custody, and compatibility
  • User-owned corrections, extensions, and accumulated learning
// 02THE SHIFT

The model is the new runtime. Applications have to change shape.

01

Frontier models keep absorbing generic capability.

Each model generation swallows another layer of what used to be application code: parsing, formatting, orchestration, interface glue. Building your product out of the parts the model is about to absorb is building on sand.

02

What survives is specific.

Domain judgment, governance, and owned state don't come with the next model release. They're earned in a domain, encoded deliberately, and owned by someone. That's the part worth packaging.

03

An agent-native app packages exactly that.

So it can improve when the user's model improves, without the publisher shipping a migration. Model changes are logged on governed actions, because model behavior changes both ways and regressions are real.

// 04HOW IT WORKS

Publish. Inspect. Mount. Run.

01

Publish

A builder packages the app: agent card, constitution, declared tools, custody, and compatibility.

agent card
02

Inspect

Anyone can read what the app is, what it can do, what data it uses, and verify the version against its constitution hash.

constitution hash
03

Mount

The user obtains an entitlement and mounts the app into a compatible Host, which checks it at mount time.

entitlement
04

Run

The app runs with the Host's intelligence and the app's judgment. Results, model identity, and governed actions are recorded.

Host

The user can update, diff, roll back, export, or fork within the rules. The trustworthy loop is the product.

// 05THE SPECIFICATION

An open specification, authored in public.

The specification defines the package format, the agent card, the constitution hash, declared data custody, and Host bindings. It is being drafted in the open, and we publish artifacts as they reach draft status, on the standards track we are building toward. The spec is a gift to the category. The registry and certification program that make conformance legible are on the roadmap.

5

Specification areas in open drafting

8

Vocabulary terms defined and citable

3

Category comparisons published

1

Dispatches in the public record

Structural counts of our own artifacts. We don't publish vanity metrics.

// 06FOR BUILDERS

The people who define a category are the ones who build in it first.

Building early gets you three things: fluency in a vocabulary most builders haven't met yet, work that enters the public record of the category, and first position when certification and distribution arrive. All of that is intent, not guarantee. What we can promise today: we reply to every builder.

// 07THE DISCOVERIES

We are figuring this out in public. Follow along.

This space moves weekly. We publish what we learn as we learn it.

What we learn building agent-native apps, as we learn it. No schedule theater. We send when there is a discovery worth your time.

// 08QUESTIONS

The questions everyone asks first.

What is an agent-native app?

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. The model supplies intelligence and tool execution; the app supplies the domain role, the rules, and the memory. The full explainer covers the definition clause by clause.

Is an agent-native app an MCP server?

No. MCP is a supported binding: an agent-native app can speak MCP; it is not itself an MCP server. The server transports tools; the ANA is the package and contract that declares which transports it uses, under which rules, with whose data.

Who runs the model?

The Host does. A Host is the AI system an ANA mounts into: it supplies the model, inference, tool execution, and the permission boundary. The publisher of an agent-native app doesn't have to host frontier inference at all, which is a core economic property of the category.

Do agent-native apps work offline?

The in-house deployment class exists for exactly this. An ANA mounted on a local model can run with air-gap support and controlled egress, for domains that require sovereignty. A Host-mounted ANA on a frontier model needs whatever connectivity that Host needs.