02 · Five builds
Five shapes. Pick one; ignore the other four.
Everything built on this substrate is one of five things, ordered by how much of the stack you run yourself. The first needs nothing but an app and somebody else’s Home. The last needs a chain. The fastest way to waste a week here is to start the wrong one.
An application
you run: your appThe people using it already have an agent somewhere.
A web app, a CLI, an assistant client that acts for a person who already has a Home. You are a relying app: she connects with her Home, you hold a bearer bound to her agent, and an act you cannot authorize comes back naming the page where she signs. You never hold a key.
Getting started →A behaviour
you run: nothing — you author documentsYou are describing what an agent should do, not writing a service.
A skill is Markdown with an execution contract in its frontmatter: the capability id, the risk, which argument carries the resource a mandate scopes, what evidence follows the act. Define the capability once and the agent’s tool set, its published vocabulary, its card and the Home’s affordance are all projections of it. If a feature needs an invoker and a vocabulary entry and a UI handler, the model is not doing its job.
Authoring skills →A service agent
you run: one Worker — or nothing at allOther people’s agents will call this thing as a peer.
An account on chain with a typed name, a card, skills and records of its own. Two shapes: hosted, where your work is an MCP server and the estate’s runtime runs the harness for it; or self-hosted, where you run the A2A door with the Service Host embedded. Either way its runs land in its own vault — a service that answers from its own loop leaves its steward’s Home showing “No runs yet” after a hundred asks.
Build a service agent →An estate
you run: five Workers and a HomeYou need your own people, whose keys and records are yours.
A Home where they sign, an agent runtime, a vault, an edge and a Home MCP, on a chain that already has a town. The people in it are different Smart Agents from anyone else’s, because the custody root differs — that one fact is what an estate is, and most of the work is keeping it true.
What an estate is made of →A town
you run: a chain and its servicesYou need your own chain.
The services every estate on one chain shares: naming, the public graph, the registry, chain access, key custody. Single-chain by definition, because every service in it is a contract on that chain or a read of its state; a town may root its names at another town and keep a local table, the way hopenet roots at faithchain. If you want your own people and names but not your own chain, you want build 4 — a day’s work instead of a quarter’s.
New-town runbook →Builds 1–3 are what a coding agent can do almost entirely on its own — that is what the rest of this guide is about. Builds 4 and 5 are operations as much as code: each is a runbook in the repository that owns it, and each has been run end to end at least twice, which is why the runbooks mark the steps that bit the second time.
True in all five
- — The person signs at her own Home. No build collects a signature on her behalf.
- — Being connected, listed, admitted or a member is never permission. The effect must be inside the acting principal’s live, scoped delegation at the moment it runs.
- — Behaviour is generated; authority never is. A generated surface is consulted by no verifier.
- — The record belongs to its owner. Your database, your Durable Object and your cache are serving planes; the record is the owner’s vault, and she can carry it elsewhere.
Running one of these for real
Builds 4 and 5 sit on a ladder with a rule: a rung never asks the one below it for anything it should not hold. An estate takes packages, never a deployment. A town takes an estate’s public facts — its Home, its edge, its name roots — never a key, a vault, a delegation or a session. The operator’s ladder places them; the four scales says what each one is.