Writing an AAO charter for a regulated firm

The manifest a machine reads you by

The representation layer answers "how is this organisation shown to machines", and its format is the AAO charter — the manifest that makes an organisation an Agentic Autonomous Organization rather than a product with some agents bolted on. For a regulated firm the charter is not marketing; it is the governance record every other machine surface derives from, and getting it right is the difference between a firm a counterparty’s agent can reason about and one it cannot.

The manifest names the organisation, a slug, a description, the human it is accountable to, an escalation path, the repositories it works in, and its roles. Two conventions carry most of the value, and both are enforced rather than encouraged — which is what a regulated firm needs, because a convention that is merely encouraged is one an auditor will find has drifted.

Capabilities name actions, not departments

The first convention is that a role’s capabilities name actions, not departments: deploy and review, never engineering. A capability that names an org unit can never be enforced, because there is no action to check an agent against — "engineering" is not something an agent does, it is somewhere it sits. For a regulated firm this is the property that makes the charter auditable: every capability is a verb a policy can allow or refuse, so "what is this agent permitted to do" has a checkable answer rather than an org-chart answer.

{
  "aao": "0.1",
  "name": "MLG Blockchain",
  "slug": "mlg-blockchain",
  "accountableTo": "michael@gda.capital",
  "roles": [
    {
      "name": "operations",
      "purpose": "Runs the books, the calendar and the vendors.",
      "capabilities": ["schedule", "bookkeeping", "procure"],
      "humanApprovalAtOrAbove": "LOW"
    }
  ]
}

Approval gates where a mistake would hurt

The second convention is that approval thresholds go where a mistake would actually hurt, not everywhere. A read-only research role needs no gate; anything touching money needs one at every level. Uniform gates are how governance becomes theatre that people route around — if every action needs sign-off, sign-off stops meaning anything and gets rubber-stamped. A regulated firm’s charter places its gates deliberately: at the actions where an error is expensive or irreversible, and the human-approval level on each role is the field that says so.

This is the same discipline this practice applies when it designs an authority model for an agent deployment: the decision boundary — automated, recommended, human — is written as policy and implemented as code, and the charter is where a firm declares that boundary at the organisational level so a counterparty can see it before dealing.

An accountable human, and an empty family left empty

The charter’s fifth question is a real, reachable human the organisation is accountable to — not a role, not a distribution list, a person. A charter without one is refused, because an organisation of agents that answers to nobody is the thing the format exists to prevent. Roles are grouped into families, and the discipline a regulated firm should copy is that a family with no genuine role in it is left empty rather than filled: inventing a role to fill a family is roster inflation, and the reference charter deliberately leaves families empty rather than manufacture a responsibility nobody holds.

Conformance is answered, not asserted

The last property that matters for a regulated firm is that conformance is answered, not asserted. The charter is checked by a conformance suite that reads it from one well-known path and nowhere else — a charter committed to a repository but not served where the checker reads is not held, however correct it is. A role name is capped in length; a top-level key that is neither a spec field nor x- prefixed fails every static question. One manifest per organisation, checked at the domain rather than in the tree, which is exactly the "committed is not served" discipline the rest of this practice’s work runs on.

A note on where this sits relative to the platform this charter format grew up beside: FlashyOS, the mesh execution platform, is a proof of concept in its own documentation, and this practice describes it at that status and never above it. The charter format is useful on its own terms — a firm can write and serve an AAO charter without adopting any particular runtime — and that is how a regulated firm should approach it: adopt the representation, evaluate the runtime separately and on its own evidence.

• The lab’s view (planned)FlashyLabs is preparing an engineering companion to this piece at https://flashylabs.com/insights/writing-an-aao-charter-for-a-regulated-firm — planned, not yet published.
• The studio’s view (planned)The 4 Ventures thesis desk is preparing an investor-lens companion at https://4.ventures/thesis/writing-an-aao-charter-for-a-regulated-firm — planned, not yet published.