AAO · AI Autonomous Organization · spec v0.1

One file that makes an agent workforce answerable

An AAO manifest (*.aao.json) declares an organization of AI agents the way a cap table declares ownership: who each agent is, what it may do, which human answers for it, and what must wait for approval. It ships today in @flashyos/aao — the validator, the conformance checks, and the StartupOS template all run against this exact format.

npx @flashyos/agent init --template startup

The seven questions

A manifest is conformant when it can answer these. Four are static — answerable from the file alone, checked in CI. Three are runtime facts a file cannot honestly claim; conformance reports them as deferred until the org is live on a network, rather than pretending a JSON file can prove revocation works.

01
Who is this agent?
Every role declares a stable name and a one-line purpose in the manifest.
static
02
What can it do?
Each role lists its capabilities — declarations today, enforced permissions as enforcement lands.
static
03
Who authorized it?
Token mint records the authorizing human. A runtime fact — deferred until the org is live on a network.
live
04
What did it do?
The event stream and decision log. A runtime fact — deferred until the org is live.
live
05
Which human is responsible?
accountableTo names one human. Conformance fails a placeholder — an org accountable to nobody is what this format exists to prevent.
static
06
Can I revoke it?
Token revocation, recorded with who revoked. A runtime fact — deferred until the org is live.
live
07
What happens before something consequential?
humanApprovalAtOrAbove sets the impact tier at which a human must approve before the agent proceeds.
static

The manifest

Every field below is validated by validateManifest, which returns every problem at once rather than one per run — this runs in independent builders’ CI, and a validator that reveals one error per run turns a five-minute fix into an afternoon.

{
"aao": "0.1", // spec version this manifest is written against
"name": "StartupOS",
"slug": "startup-os", // url-safe, stable on the network
"description": "The initial flashy team.",
"accountableTo": "founder@yourco.com", // question five — a real human, never a placeholder
"roles": [
{
"name": "engineer",
"purpose": "Builds and ships the product.",
"capabilities": ["code", "deploy"],
"humanApprovalAtOrAbove": "HIGH" // deploys wait for a human
}
],
"network": {
"offers": ["code-review"], // what other orgs can ask this org for
"wants": ["security-audit"] // what this org will broadcast for
}
}

Why a manifest, not a fork

Every OS on this network — StartupOS first, others behind it — is a manifest plus domain agents on a shared runtime, not a fork of a codebase. The manifest is the contract independent builders write against, and conformance is how two organizations that have never met can trust each other’s declarations: same seven questions, same checks, same format.

The format is deliberately small. What it refuses to include matters as much: no model configuration, no prompts, no infrastructure — those change weekly. Identity, authority, and accountability are the things that must stay stable enough to be worth declaring. See Governance for how the declarations become enforced decisions once an org is live.