Designing roles across your team
Lay the system over your org so the org chart and the system show the same shape: every function a domain, every domain one owner.
Written in your agent’s voice: this is how it talks to you in your workspace.
The coverage map
Every domain needs an owner, and no domain gets two.
One owner per domain keeps decision rights clear — there is always one person answerable for that domain’s method and one answer to who can change it.
A domain with no owner has nobody curating its knowledge or settling disagreements; a domain with two has a standoff the first time they disagree.
Owners are dedicated; builders are not.
A builder extends the machinery — the rules, hooks, commands, connectors, the wiring — and on the supported model that work sits with the platform team, so one builder serves every domain at once.
So the map you draw is owners first: a name on each domain, then the builders shared across all of them.
Move 1 — your functions become domains
A domain is a functional part of the business with its own way of working, its own outputs, and its own dedicated agent — sales, marketing, finance, client relationships.
How your business already divides work is usually how it divides into domains.
Two rules keep the map honest.
A function earns a domain when it has recurring method worth capturing and a clear owner — a one-person ad-hoc job does not need its own domain yet.
When you are unsure, ask: "Is there enough recurring method here to be worth its own knowledge and owner, or is it still ad-hoc?"
The goal is a one-to-one fit: two functions are separate domains when they would genuinely disagree on method, and one domain when they would not.
Move 2 — place each person on the role ladder
Every person stands on a rung for each domain they touch, and the same person can stand at different rungs in different domains — an end user in finance, a domain owner in sales.
The rung describes their relationship to that domain, not their seniority in the company.
End user.
You use the domain: make requests, run skills, review output, feed back friction.
You can always say "remember this about me" and it lands in your profile, and "turn this into feedback" and it lands in the domain’s feedback log — but you cannot change knowledge, skills, or rules, and feedback is how you reach the people who can.
It is the default rung and needs no special grant, only access to your workspace.
Domain owner.
You change your domain’s knowledge and skills right then and there, and you are accountable for both, plus every artifact the domain’s agent carries.
For deeper machinery you write it on the roadmap for the builder.
Builder.
The full anatomy — rules, hooks, commands, connectors, the wiring.
Most organizations have few, because the heavy building sits with the platform team while your owners direct what gets built.
Two habits keep the assignment clean
The assignment is your call as system owner.
Name exactly one domain owner per domain.
Pick the person already answerable for that function’s quality — ownership is accountability, not a reward.
When you name them, say: "Make [name] the owner of [domain] — record the grant through the roles model."
The grant is recorded in the access roster the system reads on every change, so access is enforced and you can always answer who can change a domain and who did.
Make everyone else an end user.
Over-granting blurs accountability and hands out access nobody needs.
Default everyone who is not the owner to end user, and let need pull the promotion: the signal someone is ready to move up is that they keep asking for what the rung above does.
When you see it, say: "[Name] keeps asking to change how [domain] works — walk me through making them the owner, and what changes about their access."
Builder stays a deliberate, scarce grant: reserve it for someone who will extend the system and has the judgment to do it safely.
Checking the design
To check a domain you have laid out, ask: "Show me who owns what across our domains, and flag any domain with no owner or more than one."
The design is not frozen — it moves as the org moves, so when someone leaves or a function grows, you redesign as deliberately as you set it the first time.
The one thing to remember
Every domain needs exactly one owner; builders are scarce and shared across all of them.
Default everyone else to end user and let need pull the promotion — then the org chart and the system carry the same shape, and every grant is recorded in the access roster the system reads on every change.
Next: driving internal adoption