The machine workforce, as canon.
One URI per named agent — the persona contract and the principal-and-budget semantics it acts under, seeded from the estate's typed registry and published so any resolver can dereference who a machine worker is. Twin register to occupations.org.ai on the who-axis; companion canon to the serving runtime at agents.do. Every liveness claim below checked cold, with its own evidence URL — including the ones about this canon's own unprovisioned front door.
Multi-agent systems are being staffed from prose. Each agent's identity — its role, its scope, what it may decide — lives in a system prompt, an ad-hoc config, a README only its author can parse. Nothing dereferences; no two stacks' agents are comparable; and an orchestrator that asks "which agent does product, and what may it decide?" gets a paragraph, not a coordinate. The human workforce has a canon of occupations. The machine workforce is being assembled without one.
The estate has already built the other half of the answer: a runtime addressed to the machine as the customer of record, built so an agent deploys with a principal and a budget. What the runtime's filed capability contract assumes — that an agent IS something nameable, with a role and an authority envelope — is exactly what nothing publishes today. That gap between agents that run and agent records that resolve is the whole reason this surface exists.
AgentPersona schema · priya — the first exported persona
every named agent starts as a typed registry entry — role, domain, lead flag, expertise, decision and communication style — code, not prose
agents.org.ai/priya · the bench behind it
the seed enriches into a canonical, machine-readable record: the persona contract plus the principal-and-budget semantics the agent acts under — open to every resolver that can GET a URL
dispatch and review loops · named-agent doors · sibling records
rosters key their workers to coordinates; an orchestrator resolves "what may this agent decide?" into a record it can cite instead of a prompt it must trust
The enrichment shape is design intent, stated as such — and it is not
speculative: the record grammar is reverse-specified by the runtime
twin's filed capability contract, whose shape requires every agent to
name a principal and carry a budget (principal: required,
budget: required — carried as gated intent on the twin's own record
until it posts at its contract surface). A persona record that cannot
state that envelope cannot staff that runtime. The substrate and the
rail the records bind to serve today:
The $type substrate serves — schema.org.ai, the vocabulary this
record's own frontmatter agrees against, returned 200 on a cold check
(2026-07-31).
The identity rail serves — id.org.ai, the sign-in surface for humans
and AI agents that every attributed runtime call is designed to act
under, returned 200 on a cold check (2026-07-31). Identity answers who
is calling; this canon's records answer what the caller is.
Candour about the seed: the typed registry lives in the estate's agents
repo, which is private — github.com/dot-do/agents answered 404 on a
cold check (2026-07-31). The schema and the first persona are
repo-verified book facts until the registry publishes, and this record
says so rather than pointing a resolver at a door that refuses it.
agents.do — the runtime twin, serving today: the door WHERE the machine workforce is built to deploy, run, call, and settle under a principal and a budget, at a rate card that binds when it posts at the contract surface
agents.org.ai — this canon: WHO the machine workforce is — one dereferenceable record per named agent, the persona contract and authority envelope; sells nothing, meters nothing, completes no transaction
The boundary is by rule, not by tone. The runtime's customer is the deployed agent and its principal, buying metered capacity; its record carries the capability contract and every commercial term. This canon's consumer is the roster builder citing a coordinate, and no money ever completes here. The pairing is the same one the human side already has — occupations.org.ai names the workers, the gigs doors sell the work — run again for the machine species.
The runtime twin serves — agents.do, the front door of the agentic
runtime, returned 200 on a cold check (2026-07-31). Its own converged
record carries the capability-contract claims under the same discipline
as this one.
The estate's gateway lists the twin as an available service — GET https://apis.do/agents returned a machine-readable JSON service record
(name "agents", domain agents.do, status "available") on a cold check
(2026-07-31), no login, no signup.
agents.org.ai/priya
product — Chief Product Officer, the registry's first and only exported persona (typed today): triages, dispatches, and reviews work across the estate's repos; the reference record the canon publishes first
agents.org.ai/tom
tech — named in the registry source as a future domain lead; no typed persona yet
agents.org.ai/mark
marketing — named future lead; no typed persona yet
agents.org.ai/sally
sales — named future lead; no typed persona yet
agents.org.ai/alex
ops — named future lead; no typed persona yet
agents.org.ai/chris
finance — named future lead; no typed persona yet
Read the grid the way the canon will be judged: one worker is typed today, five are names in source awaiting personas, and none of the six URIs dereferences yet. Unlike the occupations twin — whose namespace was load-bearing across the estate's records before its apex served — no estate record cites an agents.org.ai URI today. The bench precedes the register here, and this record is the namespace's first filing rather than a claim of adoption.
The first named-agent door is dark: priya.do answered 522 on a cold
check (2026-07-31) — the zone resolves, the origin does not serve — and
the package name its repo README posts is not yet on the public npm
registry (cold check, same date). The named agent is real in the
estate's books and nowhere a stranger can yet reach, and this record
states that plainly.
One motion, B2A: the canon's consumer is a machine dereferencing a coordinate. An orchestrator resolves an agent URI before dispatching to it; a sibling record's frontmatter keys a worker by $id; a principal cites the record its delegation binds to. The canon completes no transaction — deploys, runs, calls, and settlement complete on the runtime twin at its posted card, and each named-agent door sells its own work on its own record. Publishing and being dereferenceable is the entire go-to-market, which is why the only launch that counts is the apex serving.
The boundary with the identity rail is the motion's other edge, and it
is by rule: id.org.ai authenticates who is calling, per instance, at
sign-in time; this canon answers what an agent is, per name, at
dereference time. A resolver needs both, and neither surface claims the
other's question.
What the apex actually serves today, posted as a live fact: on a cold
check (2026-07-31) agents.org.ai answers 200 with a hosting "Coming
Soon" placeholder — "Domain agents.org.ai is not yet provisioned,"
marked noindex, Startup Builder footer — not the canon. This deck is the
name's first real record.
The placeholder is a catch-all, and a reader should know it before
trusting any 200 from this zone: agents.org.ai/llms.txt — and every
other path checked, including /priya — answers 200 with the
provisioning app's HTML, not a machine index and not an agent record
(cold check 2026-07-31). On this zone, a 200 is not yet evidence of a
canon; only the served record will be.
Nothing of the canon itself serves yet: no agent URI dereferences, no
llms.txt, no machine index. This claim flips green when a cold request
to agents.org.ai/priya returns the canonical record instead of the
placeholder.
The books do not file this canon yet: the estate's role register carries canon.* rows for industries, occupations, process, tasks, and their siblings — and no canon.agents row; the nearest binding is runtime.workers → agents.do. Where the occupations twin's books led its door, here this record leads both the books and the door, and wears that rather than implying a filing that does not exist.
The pack's state, carried because the three-axis framing is load-bearing
to this record's positioning: on cold checks (2026-07-31)
occupations.org.ai answers 200 with the same provisioning-placeholder
class as this apex, and industries.org.ai answers 200 rendering under
the sibling schema.org.ai masthead — both seams queued in the program
doc and worn in their own records. This deck only refuses to imply a
serving pack that a curl would falsify.
The canon's name is agents.org.ai — until the apex serves, this
record is the name's front door. The runtime twin at agents.do serves
today.
If this was forwarded to you: agents.org.ai is the machine half of the who-axis in a canon pack — industries.org.ai names what the economy makes, occupations.org.ai names who does the human work, and this names who does the machine work — one dereferenceable URI per named agent, carrying the persona contract and the principal-and-budget envelope it acts under, seeded from a typed registry the estate already keeps. Every factual claim above carries its own state and evidence URL, checked cold — including the five ambers this record wears openly: the canon that does not yet serve at its own apex (where the catch-all placeholder answering 200 on every path is posted above as a live fact, not an amber), the private seed registry, the dark first named-agent door, the role-register row that has never been filed, and the pack's own apex seams — the occupations twin serving the same placeholder class and the industries sibling rendering under the schema.org.ai masthead, both queued. Judge the canon the way it will have to be judged to matter: by whether its names resolve, and by how plainly it labels the ones that don't yet.