Build agent-native apps
To build agent-native apps is to package domain judgment so a capable AI model can run it: you define the app's identity, write its constitution, declare its tools and data custody, bind it to compatible Hosts, and publish it as one inspectable artifact. This page describes the path honestly, including which tooling exists today and which is still coming.
Last updated: 2026-08-07
What building one involves.
- 01
Package the domain
Start from judgment you actually have: the corrections, defaults, and procedures an expert carries in their head. The package gives that judgment a portable form.
- 02
Write the constitution
State what the app may do alone, what requires the user, and how it escalates. The constitution is hashed, so every version has an immutable anchor.
- 03
Declare tools and custody
List the tools and bindings the app uses and who holds which data. Declaration is what makes the app inspectable before anyone runs it.
- 04
Bind to Hosts
Connect the package to compatible Hosts through adapters. MCP is a supported binding. The package stays one artifact across Hosts.
- 05
Publish and iterate
Ship a version, watch governed actions and model identity in the record, and iterate. Users can update, diff, roll back, export, or fork within the rules.
The tooling, stated honestly.
Today you build with the specification drafts, this site's vocabulary, and your own stack. That's a real constraint and we won't dress it up.
On the roadmap, in the order we expect to ship it: package scaffolding and manifest validation, behavioral tests and cross-Host conformance checks, constitution hashing and provenance tooling, and the registry surface that makes published apps inspectable in one place. Builder-list members get each piece first.
Join the builder list.
Tell us what you're building and where you're starting from. Two selects, thirty seconds, and it shapes what we ship next, because the tooling roadmap follows what real builders actually need.