HIP-903: The Agentic Company — Autonomous Firms on Hanzo. Status Draft. Hanzo's own standard — read this before implementing against it.
A company is not a building, a headcount, or a logo. Strip it down and a company is a state machine with a bank account: it comes into existence by filing, it holds property, it signs agreements, it takes money in and pays money out, it ships something, and it distributes the surplus to holders of record.
Every one of those states is already an API call. Not aspirationally — on this cluster, today, under api.hanzo.ai/v1.
Once every transition is an API call, the question of who makes the call is an implementation detail. It has been a human for four hundred years because the transitions were paper and paper needs hands. They are not paper anymore.
This document is the argument that autonomous companies are a build, not a research problem, an account of which organs Hanzo already provides, and an honest ledger of what still requires a person and why.
The instinct when handing work to agents is to reach for permissions — to enumerate what the agent may do and trust it inside the fence. That is the wrong primitive, and it fails the same way every time: the fence is a list, lists have gaps, and an agent that is confused or captured walks through the gap.
The right primitive is a guarded state machine. The illegal move does not exist. It is not forbidden, it is unrepresentable.
This is already how formation works in clients/company/machine.go:
var transitions = []transition{
{StageStructure, StageFounders, guardStructureChosen},
{StageFounders, StagePayment, guardKYCVerified},
{StagePayment, StageDocuments, guardPaid},
{StageDocuments, StageEsign, guardDocumentsGenerated},
{StageEsign, StageGenesis, guardSigned},
{StageGenesis, StageCompany, guardGenesisRecorded},
{StageStructure, StageImport, guardSkipRequested},
{StageImport, StageCompany, guardImported},
}Its own comment says it plainly: there is no edge that is not listed here, so an illegal jump is refused by construction. An agent cannot pay before KYC clears. Not because it lacks a scope — because {StageStructure, StagePayment} is not in the table. An agent driving this machine has exactly the authority the machine grants, and no prompt, jailbreak, or misunderstanding widens it.
This is the same shape as HIP-0902's tier ladder, and the repetition is the point. Agents propose; machines accept. Separate those two powers and autonomy stops being a leap of faith and becomes ordinary engineering.
What an autonomous firm actually requires, and where it lives:
| Organ | What it must do | Hanzo | |---|---|---| | Formation | Exist in law | /v1/company | | Identity | Prove who acts | /v1/iam, /v1/idv | | Legal | Hold and sign agreements | /v1/legal | | Ownership | Record who owns what | /v1/captable | | Capital | Raise | /v1/company/fundraise | | Money | Hold, move, settle | /v1/finance, /v1/x402, /v1/wallets | | Commerce | Charge for things | /v1/commerce, /v1/billing, /v1/pricing | | Product | Build and run software | /v1/git, /v1/deploy, /v1/paas, /v1/functions | | Demand | Find and keep customers | /v1/guide, /v1/crm, /v1/campaign | | Observation | Know its own state | /v1/o11y, /v1/analytics, /v1/usage | | Compliance | Stay legal | /v1/compliance, /v1/audit, /v1/sbom | | Custody | Hold secrets | /v1/kms |
Twelve organs. All mounted. That inventory is the actual claim of this document — not that autonomous companies are coming, but that the surface a company runs on already exists and is one identity model deep.
/v1/companyTwo paths through the same machine.
Incorporate. structure → founders → payment → documents → esign → genesis → company. Choose entity and jurisdiction (c-corp, llc, dao-llc), add founders, clear KYC, pay the one-time formation fee, generate documents, sign them, record the equity genesis, and terminate as an incorporated company.
Import. structure → import → company. An existing company brings its own cap table and documents (/import/captable, /import/documents) and skips straight to terminal. Companies that already exist are not second-class.
The endpoints are the machine's edges: /genesis, /founders, /kyc, /kyc/decision, /kyc/refresh, /payment, /documents, /esign, /esign/complete, /advance, /skip.
StageGenesis deserves attention, because it is the moment a company becomes a machine-readable object rather than a filing cabinet.
The founding allocation — entity plus founders, sorted deterministically — is hashed to a keccak root and committed to the Hanzo L1 (chain 36963) by a KMS-signed transaction, either an EquityGenesis contract call or a zero-value self-transaction carrying "HZEG"+root. The chain is the source of truth; clients/graph projects the anchored root for reads.
Two properties worth naming. First, ownership becomes verifiable without trusting Hanzo — the root is on a public chain, and anyone holding the allocation can recompute it. Second, and more carefully: when the RPC or signer is not configured, the root is computed and returned with an honest pending status. No fabricated transaction hash is ever recorded, and incorporation is never blocked on an unconfigured chain. A system that will lie about anchoring is worse than one that does not anchor, and this one refuses the lie.
Formation is operated from two places, and the split follows the admin-org predicate rather than convenience.
Founder-facing — cloud.hanzo.ai. console/src/components/products/ CompanyModule.tsx drives the wizard against lib/api/company.ts, whose step list mirrors the Go machine edge for edge. A founder advances their own formation and nothing else.
Platform-facing — POST /v1/company/kyc/decision. This is a SuperAdmin operation, not a gate on the founder's path, and the distinction is the whole design.
A gate is a predicate over someone else's action. This is not that. Hanzo forms the entity, so Hanzo carries the formation KYC/AML obligation — the reviewer decision is Hanzo's own act, discharging Hanzo's own duty. IsSuperAdmin is not a check bolted onto the tenant flow; it is the authority scope the operation inherently has, because the obligation belongs to the platform and the platform is the only cross-tenant scope.
The two planes stay orthogonal:
SuperAdmin operation → produces a fact (founder.KYCStatus, founder.DecidedBy)
tenant machine guard → reads that fact (guardKYCVerified)The operation never advances the formation. The guard never calls SuperAdmin. One writes a value, the other reads it, and neither knows the other exists — which is why an agent driving the machine cannot reach the review, and a reviewer cannot accidentally advance a tenant.
Two details are worth preserving because they are easy to get wrong:
KYCReviewerConfirmed, never a provider verified. The manual route does not launder itself into looking like the automated one. Downstream, "a human confirmed this" and "a provider verified this" remain different facts forever, which is what an auditor actually needs.
DecidedBy = reviewer — satisfyingindividual accountability for a privileged act.
The authority model is therefore already right. What does not exist yet is the UI: admin/apps carries operator, admin-base, admin-commerce, admin-bot, admin-tasks, analytics, insights — and no formation review queue. A reviewer today calls the endpoint directly.
That is one missing admin app following the established admin-* pattern: a queue of founders pending KYC, the provider payload, approve/reject posting to /kyc/decision. Small, and worth naming rather than glossing, because a back-office whose only interface is curl is a back-office that will not be used consistently. And the review is not a formality Hanzo performs for a customer — it is how Hanzo discharges its own KYC/AML obligation, so performing it inconsistently is a compliance failure of the platform, not a degraded experience for the tenant.
If the obligation is Hanzo's, the record must be Hanzo's. Today it is not.
clients/company/store.go exposes Get(ctx, org), Put, Delete — keyed by org, every time. There is no list, no scan, no prefix. The consequence is blunt: Hanzo cannot enumerate its own formations. You can answer "what is this tenant's formation state" and cannot answer "how many founders are awaiting review", "which formations have been sitting at documents for three weeks", or "show me every entity we formed this quarter" — which is the question a regulator asks.
The register is the missing organ, and it is small: a cross-tenant list over the same table, SuperAdmin-scoped, with the review queue as one filtered view of it.
The deeper structural point, and the reason this is not just a missing SELECT.
The formation machine models what Hanzo controls: choose a structure, collect founders, take payment, generate documents, route signature, anchor genesis. Every one of those completes on Hanzo's own clock.
Incorporation does not. The State of Delaware responds when it responds. So does the IRS for an EIN, the registered agent, and the bank. These are third parties with human latency measured in days, and no guard can make them faster.
Conflating the two clocks fails in one of two ways: either the machine blocks on an external party — a tenant stuck at a stage nobody at Hanzo can advance — or it advances optimistically and lies, reporting a company as formed before the state has said so. The genesis anchor already refuses that second failure by returning honest pending rather than a fabricated hash; the filing track needs the same discipline.
So they stay separate. The formation machine runs Hanzo's path. A parallel filing record tracks each external obligation on its own clock:
struct Filing
namespace Text
kind Kind # jurisdiction, ein, agent, bank
authority Text # "delaware-sos", "irs"
status Status
submitted Int64
responded Int64
reference Text # the authority's file number
updatedBy Text # the reviewer who last touched it
note Text
enum Status
todo
submitted
pending # with the authority, awaiting response
action # they responded, we must do something
done
rejected/v1/legal/filings already exists as the surface. What it needs is binding to the formation and an honest manual update path — because a human at Hanzo reading an email from Delaware and typing the file number is the correct implementation. There is no API to poll. Pretending otherwise would produce a system that quietly reports stale state, which is worse than one that plainly says "waiting on Delaware since the 12th".
This is the shape of the whole back office: automate Hanzo's clock completely, track the third party's clock honestly, and make the waiting visible rather than hiding it behind a spinner. status: pending with a submitted date is a real answer. A progress bar is not.
Two steps in the founder wizard are still marked stub: true — KYC and e-sign — meaning the provider integrations are surfaced but not fully wired. Those are the same two gates section 8 identifies as human by law, which is not a coincidence: they are where the machine hands off to a person, and handoffs are the last thing to get built.
/v1/legalTemplates, documents, signature, filings: /templates, /documents, /documents/:id/sign, /documents/:id/sign/complete, /filings.
An agent drafts from a template, routes for signature, and tracks the filing. What it cannot do is be the signatory — section 8.
/v1/captableThe full instrument set, not a toy: /stakeholders, /share-classes, /shares, /shares/transfer, /options, /equity-plans, /safes, /convertibles, /rounds, /rounds/:id/close, /rounds/:id/investments, /summary.
This is the organ most often hand-waved in "AI company" pitches, and it is the one that determines whether the entity is real. A company that cannot issue a share class, grant options against a plan, and close a priced round is a storefront. This one can.
/v1/company/fundraise/fundraise/safe, /fundraise/round, /fundraise/deck.
A SAFE is a document plus a cap-table entry — both organs already present, so the endpoint is composition rather than new machinery. /fundraise/deck generates the narrative from state the company already holds: its metrics live in /v1/analytics and /v1/usage, its ownership in /v1/captable, its revenue in /v1/commerce. A deck assembled from live state instead of a founder's recollection is strictly more honest, which is an underrated argument for automating it.
Money. /v1/finance/accounts, /v1/finance/treasury, with admin sweep, policy, and anchoring under /v1/admin/treasury. Ledger discipline through clients/treasury/ledger. On-chain settlement via /v1/wallets and /v1/smart-wallets. And /v1/x402 — HTTP-native payment, where a request carrying insufficient funds gets 402 and a settlement path rather than a rejection. That matters more than it sounds: x402 is how one agent pays another without either holding a card. It is the payment rail that does not assume a human at the checkout.
The payer is one value in one place — hanzoai/account.Payer — because the alternative was four copies disagreeing and 402-ing funded customers.
Commerce. /v1/commerce, /v1/billing, /v1/pricing, /v1/plans, /v1/entitlements, /v1/marketplace, /v1/referrals, /v1/affiliates. Price, meter, invoice, collect, gate on entitlement, pay partners.
Product. /v1/git (native, no forge dependency), /v1/builds, /v1/deploy, /v1/paas, /v1/sites, /v1/functions, /v1/clusters, /v1/machines. Code enters at /v1/git and leaves as something serving traffic, with no vendor in the path.
Demand. /v1/guide — the GTM autopilot — plus /v1/crm, /v1/campaign, /v1/marketing, /v1/ads, /v1/social, /v1/content.
Observation. /v1/o11y, /v1/analytics, /v1/usage, /v1/costs, /v1/insights. A firm that cannot read its own state cannot govern itself, and autonomy without self-observation is just an unattended process.
The honest section. Three gates are human by law, not by missing product:
guardKYCVerified runs against a natural person. Jurisdictionsrequire an identifiable human behind an entity. This is the deepest gate and it is not going away.
contract.
An agent is not a legal person. It cannot be a director, cannot hold capacity to contract, and cannot be liable. Any claim otherwise is false today in every jurisdiction we would incorporate in.
So the accurate statement is narrower and, I think, more interesting than the maximal one:
A human signs a company into existence. After genesis, agents can run it.
The human is the root of trust, applied once, at the boundary where law demands a person. Everything downstream — issuing shares, closing rounds, pricing, billing, deploying, hiring vendors, paying invoices, filing — is a machine transition an agent can drive under guards.
StructureDAOLLC is in the enum because Wyoming's DAO LLC is the closest legal vehicle to on-chain governance: it permits the operating agreement to point at code. It narrows the human surface. It does not eliminate it, and this document will not pretend otherwise.
An autonomous company must be able to change its own product, which is the problem HIP-0902 exists to solve.
Agents propose ref updates. The tier ladder gates them: structure, novelty, hermetic build with passing tests, a panel of model judges that may reject but never approve, and human authority reserved for policy. A quorum accepts and the ref moves. Merged code is code that independent machines built, independent judges failed to fault, and a quorum signed.
That closes the loop. /v1/company gives the firm a legal body, /v1/commerce gives it a metabolism, and HIP-0902 lets it change its own substance without a person in the merge path. The firm can then observe itself through /v1/o11y, decide through its agents, and act through the same API surface a founder would use — because it is the same surface. There is no separate "agent API." There is one control plane, and agents are ordinary principals on it.
No two companies want the same autonomy. Policy is keyed by namespace — one value, one lookup, no {type, id} pair — and each organ declares how far it runs unattended:
struct Autonomy
namespace Text
organ Text # deploy, spend, hire, file, merge
mode Mode
ceiling Int64 # currency minor units, where money is involved
approvers List(Text)
enum Mode
off # humans only
advise # agent proposes, human accepts
bounded # agent acts under ceiling
full # agent actsA company might run merge: bounded, spend: bounded with a ceiling, file: advise, and hire: off. Autonomy becomes a dial per organ rather than a single switch, and it ratchets on evidence: run advise, read the log, and promote the organs that earned it.
Three reasons, in order of how much I believe them.
Cost. The floor cost of a company is currently a person's attention on a dozen mechanical loops — invoicing, filing, renewals, reconciliation, dependency bumps. None of it needs judgment. Pushing that floor toward zero changes which businesses are worth starting, which is a larger effect than making existing businesses cheaper.
Honesty. A machine-run company reads its numbers from its ledger. A deck generated from /v1/captable and /v1/commerce cannot round in its own favor. Automating the reporting path removes a whole category of well-intentioned misstatement.
Composability. Once firms are machine-legible, they compose. Agent-to-agent commerce via x402 needs no human at either end of the transaction, and a counterparty that is an API rather than a sales cycle is a genuinely different economic object.
The claim is not that companies should run without people. It is that the mechanical fraction should run without people, so the human fraction is judgment — which is the part people are actually good at.
party, and that party is a human. Guards bound the damage; they do not relocate the responsibility.
bounded spend stops an agent exceeding anumber, not an agent spending the number badly.
change.
pending.Correct, and it means ownership verifiability is best-effort until confirmed.
Mode must besettable only by a human quorum, or the dial governs nothing.
store.go is org-keyed with no list, so Hanzocannot enumerate the entities it formed. This blocks the review queue, the filing tracker, and any compliance report. It is the first thing to build.
respond on their own schedule through human channels. Track them honestly; do not model them as guards.
clients/company/machine.go — the formation machine, single source of truthclients/company/genesis.go — equity genesis anchor, Hanzo L1 36963clients/captable, clients/legal, clients/treasury, clients/x402hanzoai/account.Payer — one payer, one place