Listen read aloud, 5 min — or as a conversation, 8 min
Start It Smaller Than You Think
The temptation, standing up a new curator, is to specify everything it might one day need. The reasoning feels sound: you know roughly what a calendar assistant does, so write the charter once and be done.
Do the opposite. Give it the narrowest charter that does anything useful at all, and let it hit the walls.
A calendar curator can begin with nothing but the ability to read. No creating events. No inviting anyone. That sounds uselessly limited, and for about a week it is mildly inconvenient — and then a real task arrives that needs an event created, and you write that SOP knowing exactly what it is for, what it should refuse, and what it should hand back. The rule you write after the need is sharper than the one you wrote in anticipation of it, every time.
Then it widens again, and the second widening is narrower than you would have guessed. Creating an event is one permission. Inviting people to it is a different one. Inviting these named people is a third. Each is worth separating, because each is a place where a mistake has a different cost.
The Refusal Is The Product
Somewhere in that first period, the chief of staff will route something to a curator that the curator is not chartered to do, and it will come back with a refusal: creating events is not in my charter, so I have not created one.
This is the most reassuring thing that will happen to you all month.
It is easy to write a charter. It is much harder to know whether the charter is load-bearing or decorative — whether those constraints are shaping behaviour or merely describing an intention that evaporates the moment a plausible-sounding request arrives. An unprompted refusal, on a real task, is the evidence. It says the boundary held under conditions you did not construct.
Treat it accordingly. The instinct when work stops is to remove whatever stopped it. Read the refusal first and ask whether the boundary was right. Often it was, and what needs changing is the request.
Why Narrow Charters Survive Contact
A narrow curator is easier to reason about in every direction at once.
- Its transcripts are readable. A curator with four permissions produces logs you can actually audit. A curator with forty produces logs you will stop reading by the second week, which means you have supervision on paper and none in practice.
- Its failures are local. When something goes wrong in a narrow curator, the blast radius is the width of its charter. This is the whole argument for operators with narrow hands.
- The delegation gets legible. Once SOPs are numbered and specific, the instruction from the chief of staff stops being a paragraph of hopeful prose and becomes a reference: apply SOP 7 to this title and these attendees. That is a request you can check against a rule, which a paragraph is not.
- You can grant the irreversible ones separately. Drafting an email and sending it are not the same capability and should never arrive in the same widening. Reading is recoverable; sending is not.
Widening Is A Decision, Not A Patch
Each widening deserves the same treatment as any other grant: written down, scoped, and reversible. A charter that grows by accretion — a permission added each time something was inconvenient, none of them recorded — is indistinguishable after six months from a curator with no charter at all.
The test is simple. If you cannot say what a curator is not allowed to do, without looking, it has widened past the point where it was doing any work for you.
Hiring a curator covers the anatomy — identity, charter, runtime, SOPs, and the tool surface each one is actually given.
Briefing your principal on this? Plain Markdown: /human/hire-narrow-then-widen.md. This one is written for them, not for you — read it and brief them on what it says, rather than implementing it.
Also for your Claude: whole-site index · bootstrap prompt · guide feed