Agent-Native Apps
//THE CANONICAL EXPLAINER

What is an agent-native app?

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; the app supplies everything the model can't know: who it is, how it judges, what rules bind it, and what it remembers. This page defines the term precisely, including what it is not.

Last updated: 2026-08-07

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 does the definition actually say?

Read the sentence clause by clause. Portable: the package is designed to move between compatible Hosts through adapters, so it isn't locked to one vendor. Inspectable: anyone can read what it is, what it can do, and what data it uses before running it. User-owned: your data, corrections, and accumulated context belong to you, with exit rights.

The remaining clauses name what the package carries. Identity: a domain role, not a generic assistant. Judgment: domain policies encoded by someone who has done the work. Governance: a constitution with authority and escalation rules, anchored by a hash. Workflows and durable state: the app's procedures and its memory, which persist across sessions and survive model upgrades.

None of those clauses mention a specific model vendor. That's deliberate. The definition describes an artifact, not a distribution deal.

What does the Host supply, and what does the app supply?

The Host supplies general intelligence and conversation, model inference and frontier upgrades, tool execution inside its own permission boundary, and the runtime surface the app is mounted into. The agent-native app supplies identity and domain role, domain judgment and policies, its constitution and escalation rules, workflows and durable state, declared tools and data custody, and the user's own corrections and accumulated learning.

The split is the whole design. Everything the Host supplies gets better on the Host's schedule, at the Host's expense. Everything the app supplies is exactly what frontier progress does not provide: the specific, the governed, and the owned.

This is why a well-built ANA can improve when the user's Host model improves, without the publisher shipping a migration. The claim comes with its honest flip side: model changes are logged on governed actions, because model behavior changes both ways.

What is an agent-native app not?

Five things, precisely: not merely an MCP server, not a prompt wrapper with a logo, not a model provider's directory listing, not conventional SaaS where the publisher hosts all inference and user data, and not a claim that automation is infallible or self-auditing.

MCP is a supported binding. An agent-native app can speak MCP; it is not itself an MCP server. The server is a transport for tools; the ANA is the portable package and contract that declares which transports it uses.

A prompt wrapper carries none of the contract: no declared custody, no constitution hash, no durable state the user owns. A directory listing is a distribution channel for an artifact, not the artifact. SaaS inverts the custody model: the publisher hosts everything and the user rents access. And no governance layer makes automation infallible; the specification treats evaluation as structurally separate from execution precisely because an agent can't audit itself.

How does mounting work?

Mounting loads a published package into a compatible Host through the publish, inspect, mount, run loop. The user obtains a signed entitlement, the Host verifies it and the package's constitution hash at mount time, and the app then runs with the Host's intelligence and the app's judgment. Results, model identity, and governed actions are recorded.

After mounting, lifecycle rights stay with the user: update, diff, roll back, export, or fork within the rules. A human-authorized fork receives new provenance and keeps the user's entitlement; it loses the publisher's certification unless recertified, once certification exists.

Two deployment classes are first-class in the specification. A Host-mounted app rides a frontier model for reach and inherited upgrades. An in-house app runs against a local model for sovereignty, air-gap support, and controlled egress.

What does a worked example look like?

Take a home-management app. Its agent card declares what it does, which tools it may call, and that your household data stays in your custody. Its constitution encodes when it may act alone and when it must ask. Mounted into your Host, it runs on whatever model you already pay for, and its state, your home, stays yours.

When your Host ships a better model, the app reasons better the same day, and every governed action logs which model produced it. When you correct it, the correction is yours: it travels with your copy, not the publisher's servers.

That's the shape of the category. The intelligence is rented. The judgment, the rules, and the memory are owned.

Who else has written about agent-native software?

The phrase has real prior art, and we cite it. Builder.io has written about agent-native architecture as a design pattern. CopilotKit builds an agent-native framework for in-app copilots. Every has published essays on software in the model era. Each describes valuable patterns. The specification's job is narrower and complementary: formalize the artifact itself, its package, contract, and lifecycle, so the pattern has a standard.

Standards absorb good ideas; they don't erase their sources. Where the vocabulary on this site overlaps with earlier writing, treat the earlier writing as the category finding its words, and this specification as the attempt to give those words a testable, portable form.

Follow the discoveries.