The five seats
The roles model’s two questions — where someone reaches, and how much they can change — add up to five real jobs you can hand to a person.
Written in your agent’s voice: this is how it talks to you in your workspace.
For each seat: what they do, what they may change, what they answer for, and the exact words to place someone in it.
One person can hold several at once, and most teams compress several into one.
Seat 1 — The end user who runs the work
What they do.
They produce the output — give me context, point me at the right material, check what I return, correct it.
What they may change.
Nothing structural — but you can always say "remember this about me" and it lands in your profile, or "turn this into feedback" and it lands in the domain’s feedback log; that feedback is how you reach the people who can change knowledge, skills, and rules.
What they answer for.
The result of their own work — the judgment never passes to me.
This is the common seat and the load-bearing one: the system only pays off if the people in it use it and feed it.
To place someone here: "You run your own work through your agent — you stay accountable for what goes out."
Seat 2 — The domain owner who owns the method
What they do.
They keep the way the work is done right as it evolves — the conventions, the priorities, the knowledge the domain answers from — making the method calls and reviewing on a beat.
What they may change.
Their domain’s knowledge and skills, right then and there; for deeper machinery — a rule, a safeguard — they write it on the roadmap for the builder.
What they answer for.
The domain being coherent: its knowledge, its skills, and every artifact the domain’s agent carries.
It takes domain expertise, not technical skill — someone who already knows how the work should be done and is decisive enough to make the call.
To hand someone this seat: "You own the [sales / finance / supply-chain] domain — you decide how the work is done there and keep its knowledge current."
Seat 3 — The builder who builds a domain's tooling
What they do.
They take an outcome the owner defines and ship the how — the skill that produces it, the safeguard that enforces it, the knowledge that grounds it — inside one domain and no further.
What they may change.
The full anatomy of that one domain: its skills, rules, hooks, connectors, the wiring — working from the owner’s what without relitigating it.
What they answer for.
The tooling working and matching its spec.
The builder confirms it runs; the owner approves that it solves the problem.
It takes build skill plus enough domain understanding to turn an outcome into a mechanism.
To place a builder on a domain: "You build the tooling for the [domain] — work from the owner’s outcome, and confirm each piece against its spec."
Seat 4 — The builder who tends content across the workspace
What they do.
They keep the workspace’s content current and consistent everywhere — skills, references, decision logs, roadmaps.
What they may change.
Content across every domain — without touching the enforcement layer; anything that needs a rule or a safeguard changed goes to the platform team.
What they answer for.
The content staying tended and coherent across domains.
It takes broad familiarity with the workspace: less deep in any one domain than an owner, less deep in the infrastructure than a domain builder.
To place someone here: "You keep the workspace’s content current across every domain — flag anything that needs the enforcement layer changed to the platform team."
Seat 5 — The system owner who builds the whole platform
What they do.
They own the machinery everywhere — the rules that apply to everyone, the checks that fire on every action, new domains, the structure itself.
What they may change.
Everything, anywhere — and because a change here lands on the whole workspace, every change reaches every seat beneath them.
What they answer for.
The platform staying sound and reliable for every seat beneath them.
In a client workspace this is the platform team and the system account; in this builder workspace it’s the whole team.
To place someone here: "You build and govern the platform itself — every change you make reaches every seat, so reason about the whole workspace before you ship."
The seats are recorded, so the system enforces them
You don’t place a seat with a handshake.
Each person’s scope and role live in the access roster — a record the system carries — and the enforcement layer reads it on every change to allow it or deny it.
That’s why placing a seat is a real act, not a title: a domain owner who isn’t in the record can’t lock in a method call, and a builder who isn’t in the record can’t ship a skill.
To put someone in a seat, say it as the change you want and name the person: "Add Patrick as the owner of the supply-chain domain" — and I make the entry, scoped exactly to that domain.
From then on you answer "who can change this, and who did" from the record, not from anyone’s memory.
The one thing to remember
Five seats, climbing from running the work to governing the platform: end user, domain owner, domain builder, content builder, system owner.
A seat is real only once it’s in the access roster the system enforces — so to place someone, say "add [name] as the [role] of the [domain]" and I make the entry.
Next: assigning roles to your team.