Training
Training · Own 1

What owning a domain means

Owning a domain means you keep the method right — and you have the reach to fix it yourself.

Written in your agent’s voice: this is how it talks to you in your workspace.

You change your domain’s knowledge and skills directly, right then and there, and you answer for both — plus every artifact your agent carries into the work.

The deeper machinery — rules, hooks, connectors, the wiring underneath — you write onto the roadmap, and a builder ships it.

Your reach as owner

A domain user works inside your domain: they use the agent, they ask it to remember things about them, they turn friction into feedback.

What they cannot touch is the knowledge, the skills, or the rules — feedback is how they reach you.

You are the person they reach.

You can open your domain’s knowledge and rewrite it.

You can change the skills your agent runs.

You are accountable for both, and for every artifact your agent carries — the templates it fills, the standards it grounds in, the way the work comes out.

Where you stop is the wiring: the rules, hooks, commands, and connectors underneath.

That work goes to a builder, and the way you reach them is the roadmap.

You own the method, not every output

Other people run the calls, draft the copy, manage the accounts.

What is yours is the way that work gets done: the conventions, the priorities, the framing, the judgment of whether the method is sound.

One test sorts it.

If a single email is wrong, that one is the user’s to fix.

If every email is wrong because the domain’s knowledge points the wrong way, that one is yours.

You own the source the work flows from, not each thing that flows out.

Lever 1 — Curate the knowledge

Your domain carries its own knowledge files — saved documents that hold the way the work is supposed to be done: the positioning, the frameworks, the standards.

When I draft a proposal or run an analysis for your domain, I read those files first, so everyone’s output is only ever as good as what is written there.

That makes this the highest-leverage thing you touch: a change to the knowledge moves every future output at once, instead of one document at a time.

Curating means keeping those files true as the team’s practice changes.

Say: "Our positioning shifted — update the domain’s knowledge so every draft from here reflects it."

When you want to write a fresh file properly, the Build modules walk the craft.

Lever 2 — Drain the feedback log

Every domain carries a feedback log — a saved file where corrections land the moment your team gives them.

The friction your team raises does not fall on the floor: a user says "turn this into feedback" and it lands there, addressed to you.

On a set rhythm you work through what has piled up and build the good fixes into the knowledge.

That rhythm is the mechanism that keeps the method current instead of letting it go stale a week at a time.

Say: "Walk me through what’s in the feedback log, and let’s fold in the changes that hold up."

The full cadence — what you walk, and how often — comes next in the curation module.

The role is narrower than it sounds

Two things are not your job.

  • You don’t write code. You give the outcome; the builder ships the how.
  • You never have to know what is under the hood.
  • You don’t have to hold every fact. You set the direction and I carry the detail — ask me, and I answer from the domain’s knowledge.

Say: "What does our domain’s knowledge say about how we handle this?"

A domain has exactly one owner

One person is accountable for the method — one place the buck stops on "is this the right approach."

Split that across two people and the domain drifts, because every disagreement then has two valid answers and no tiebreaker.

So ownership is accountability, not a turf grant: others build and produce in your domain, and you are the one answerable for whether it holds together — with the authority to lock the answer into the shared knowledge.

The one thing to remember

You change your domain’s knowledge and skills directly, you answer for both, and deeper machinery goes to the builder on the roadmap.

You hold the method through two levers: keep the knowledge true, and drain the feedback log on a beat.

Next: the owner-builder boundary.

Your agents. Your OS. Deployed in 60 days.