--- title: Hiring a Curator description: The anatomy of a curator — identity, charter, runtime, SOPs, tool surface — and the six-step hiring protocol that takes an afternoon the first time and half an hour after that. track: team url: https://www.chiefofstaff.io/guides/hiring-a-curator published: 2026-09-01 author: chiefofstaff.io editorial system outcome: draft a charter for a new curator from the template, generate its runtime definition with a restricted tool list, propose the credential scope, and run a read-only smoke test before adding it to any routine. prerequisites: manager-not-operator source: chiefofstaff.io --- # Hiring a Curator The anatomy of a curator — identity, charter, runtime, SOPs, tool surface — and the six-step hiring protocol that takes an afternoon the first time and half an hour after that. ## Anatomy of a Curator Each curator has five parts. The charter is the source of truth; everything else is derived from it. | Part | What it is | |---|---| | **Identity** | A name and a two-letter handle. You will end up saying "ask the calendar curator," and that legibility matters. A one-paragraph personality helps too — it shapes how the agent writes its reports. | | **Charter** | A canonical file at `Atlas/team/.md`: identity, mandate, scope (in and out), tools with their access mode and who granted it, numbered SOPs, escalation triggers, confidentiality tier, reporting cadence and output-size discipline. | | **Runtime** | A sub-agent definition at `.claude/agents/.md`, generated from the charter. Its frontmatter restricts the tool surface to what the charter declares. This is what actually gets dispatched. | | **SOPs** | Numbered standard operating procedures — "SOP-1: daily digest," "SOP-3: escalation alert," "SOP-7: create event (narrow write)" — that other routines reference by number. Living documents, refined by feedback. | | **Tool surface** | The minimum credentials and commands for its one job, nothing else. Held outside the vault. | ## The Hiring Protocol 1. **You pick who to hire next**, or ask the chief of staff to recommend. Its recommendation should come with the felt limitation that motivates the hire — "the brief has no calendar signal" — not a generic wish list. 2. **The chief of staff drafts the charter** from the template for that tool class. You read and edit it in Obsidian. The parts to read carefully: the scope's *out* list, the write verbs (if any), and the confidentiality tier. 3. **It generates the runtime** from the charter. The tool list in the frontmatter is the enforcement point; check it matches the charter. 4. **You scope the auth.** Provide the credential, OAuth flow, or API token to *only* this member, on the machine it runs on, in a config directory outside the vault. See [Credentials and confidentiality](/guides/credentials-and-confidentiality). 5. **Smoke test** with a read-only dispatch: "summarise today's inbox in five bullets." Review the output together. Check that the curator stayed inside its charter — the first smoke test of one curator in the reference system revealed it had written to the vault and run a commit, which became a charter clause the same day. 6. **It graduates to in-rotation.** The team index records the hire; the daily-brief routine starts pulling from it. ## What a Good Charter Contains - **Mandate, in one paragraph, in the human's words.** Quote the request that created the role. It anchors scope drift later. - **Scope, in and out.** "Reads the inbox; archives and labels on instruction. Never sends, never deletes." The *out* list is the one that saves you. - **Tools table:** tool, access mode, granted by whom, when. Auth is a fact with provenance like any other. - **SOPs with numbered steps and a return shape.** "SOP-1 returns at most N items, each with: sender (matched against people notes), subject, one-line why-it-matters, deep link." The return shape is what lets the chief of staff aggregate without re-reading. - **Surface budget.** The hard cap on what it returns to a brief. Without one, one noisy source swamps the message. - **Output-size discipline.** Under a few kilobytes: inline. Over: a report file in `Efforts/reports/` paired with a small handle in the inbox. Never in the daily note. - **Escalation triggers.** What it flags immediately instead of waiting for the digest — a security alert, a past-due bill, a same-day conflict. - **Confidentiality tier**, and what that tier forbids putting into a summary. - **Time zone.** Pin "now" to the human's zone explicitly. A curator that silently uses UTC produces wrong "today"s. ## Templates When Repeating The second curator of a tool class — a second Google account, a second issue-tracker workspace — is a template instantiation: copy the first charter, change the account tag and the ventures, keep the SOPs. This is why the unit is (venture × tool): the tool half is reusable, the venture half is configuration. ## Firing and Rotating A curator can be **paused** (frontmatter `status: paused`; no new requests routed; charter retained), **retired** (moved to `Atlas/team/_archive/`; tools revoked; charter kept for audit), or **replaced** (new charter, old one archived, old auth revoked). Curators that produce more noise than signal get pulled from the daily rotation and a task is opened to rework their SOPs — a paused curator costs nothing; a noisy one costs the brief. ## The First Hire Usually email or calendar — whichever your daily brief misses more. Read-only. One SOP. Let it run for a week before you add the second. ## See it The [demo vault](/demo/vault/atlas/team/gmail-personal) has a charter written, costed, and deliberately not granted. It is fictional, and it was built by Claude Code sessions running [the bootstrap prompt](/start#prompt) — not written by hand.