Placing your people in the seats
This is how you decide who owns what, who builds, and who runs their day — and make each call real.
Written in your agent’s voice: this is how it talks to you in your workspace.
The authority is yours, and it is a real call
The harperOS team builds the platform, but who owns sales, who owns finance, who builds, and who runs their work is your call to make and to change.
This is not an org chart on a slide.
When you name someone an owner, that becomes their actual write access — recorded in the roster and honored on every change.
There are four seats, and they line up with the curriculum tiers: end user, domain owner, builder, system owner.
I cover the roster, and what makes it stick, at the end.
Assign by what people already do
Start with the work as it runs today, not an ideal.
Map your org onto domains.
List the functional domains your team actually runs — sales, marketing, finance, client work, whatever the real shape is.
A domain is a slice of the business with its own way of working and its own knowledge worth keeping.
The test: would two of them ever disagree on method?
If yes, separate.
If not, one.
Keep it lean — three real domains owned well beats eight owned in name only, because an unowned domain has no one to keep its method right.
Say to me: *"Here’s how my team is split — sales, finance, client work.
Lay those out as domains and tell me what each one would hold."*
Name the owner each domain already turns to.
The right owner is usually the person the team already asks "how should we do this" in that domain.
You are formalizing an existing reality more often than creating one.
One person, one domain, so decision rights stay clear — one person can own several, but two cannot share one.
Pick for domain judgment, not technical skill: someone who knows how the work should be done, decides when the team disagrees, and notices when the written method has drifted from real practice.
The owner sets the what and the why; the builder handles the how — a named rule called the owner-builder split, which the Own track teaches.
Say to me: *"Patrick should own sales.
Tell me what owning it will ask of him, and point him at the modules that teach the role."*
Start narrow, then widen on evidence
Most teams need no builder of their own at first.
No builder yet.
The harperOS team holds the builder grant in every workspace and ships the tooling, so you can run a full operation with your people as owners and end users while we build.
That is the right shape to start from.
Grant a builder seat once an owner is technical enough and wants to ship their own tooling — that makes them owner and builder of one domain at once, fine as long as they switch hats out loud.
A grant that reaches the whole system — the system-owner seat — is rare on the client side; reserve it for someone you trust with workspace-wide change, and coordinate it with the harperOS team.
Say to me: "Walk me through what a builder seat lets someone change, and where the line is between a domain builder and a system owner."
Everyone else is an end user — and that is the goal.
Most people will never own or build.
They run their day with their agent, give it context, correct its output, and feed back friction — the seat the whole system is built to serve.
An end user needs no grant beyond access to their own workspace; in the roster, that is simply no role entry, which reads as read-and-run.
Pointing them at the right onboarding is the whole setup.
Say to me, for each new person: "Set up Mike as an end user and point her at the right place to start."
Make it real in the roster, and revisit it
Each grant lives in one named place: the roster.
It is a recorded list — one entry per person — pairing each name with the domains they own or build.
It is encoded, not an informal agreement, which is what makes the access enforced and auditable rather than a promise someone remembers differently next quarter.
The mechanism: every time anyone writes a file, the structural-access-control check reads who is acting, looks them up in the roster, and allows the write only inside the domains their grant covers.
A name in the roster is real access; a name left out has none — which is why naming an owner is the same act as granting access.
Set new owners up to learn the role: point them at the Own track, pair them through their first review, let them run the second solo.
Someone with the domain expertise picks up the role in about a month.
The map is not permanent.
When someone leaves or a domain grows, reassign as deliberately as you set it — change the roster entry, and the access changes with it.
Say to me: "Record these grants — Patrick owns sales, Mike is an end user — and confirm the access is now enforced."
The one thing to remember
Assign by what people already do, start narrow, and widen on evidence.
The roster turns each call into real, enforced access — and you change it the same deliberate way you set it.
Next: governance, propagation, and the boundary