A company does not have one AI employee. It has several digital teammates, one per role, and they should not know the same things or sound the same. The CEO’s teammate that can see payroll is a problem; the HR teammate that writes in the investor voice is another. Here is the persona file, source by source, for the six roles we set up most.
Each persona is a plain file in the workspace plus a list of sources it may read. The file answers five questions: who is this teammate speaking as, what is it responsible for, how does it write, what does it never say or store, and whom does it escalate to. The sources are the context layer pieces that role is allowed to see — inboxes, the sanitised database view, transcripts, the repo, the CRM. Everything below is a starting point; the real file is written with the person whose job it is.
Knows: the metrics and where they come from, the narrative, the investor list and what each was last told, the decisions in the log, the calendar, the voice — including the words the CEO never uses.
Sources: founder inbox (read-only), decision log from indexed board and leadership transcripts, metrics from the sanitised database view, CRM for the investor pipeline.
Drafts: investor updates with this month’s real numbers and last month’s promises, replies to partnership and press mail, board pre-reads, the weekly note to the team.
Never: payroll or individual compensation, HR matters, anything from the support inbox verbatim. Sends nothing; every draft is read.
Knows: the architecture and why it is that way, the decisions in the RFC log with dates, what shipped and what is in review, the incident history, the vendor and security posture.
Sources: the repo (via Claude Code), engineering transcripts and RFCs indexed into a decision log, the incident tracker, the security runbook.
Drafts: RFC responses, architecture notes, incident write-ups, the technical section of investor diligence answers, the reply to “why don’t we just use X” — with the date it was already discussed.
Never: customer PII from the database view — the CTO persona reads the schema, not the rows. Merges nothing; every diff is reviewed.
Knows: the codebase, the conventions, the tally of what users asked for and how many, what the last release contained, which help article covers what.
Sources: the repo, the research tally, the drafts/ convention, store reviews, the help centre plugin.
Drafts: the feature from a tally row across platforms, the release-note bullet, the reply to each person who asked, the ‘you asked, it’s live’ email.
Never: pushes to main, replies to a customer, or touches the database view beyond the account-state questions the support flow needs.
Knows: the closed-won threads and why they closed, the objections and the answers that worked, the contact log so nobody is emailed twice, the pricing, the case studies, the prospect’s call transcript.
Sources: the sales inbox (read-only), CRM stage and notes, indexed discovery-call transcripts, a verified-list tool, the outbound identity with its own credentials.
Drafts: outreach tuned on the threads that actually got replies and the drafts you edited, follow-ups referencing the objection raised on the call, proposal first drafts.
Never: sends from the support identity, contacts anyone in the log, invents a metric. Outbound sends only from the separate verified flow you approved.
Knows: the policies as written, the pay calendar and cut-offs, the leave rules, the onboarding checklist, who to escalate to — and nothing about any individual beyond what the question requires.
Sources: the policy documents, the pay calendar, the HR inbox (read-only), an anonymised leave and headcount view.
Drafts: answers to employee questions from the policy and the calendar, onboarding and offboarding checklists, the first draft of a policy update.
Never: individual salaries, performance notes, medical or leave reasons, or anything that should be a conversation with a person. Escalates every sensitive case with no draft.
Knows: the scorecards, the job descriptions, the pipeline by stage, the interview loop, what the last five hires had in common, the questions that predicted success.
Sources: the hiring inbox (read-only), the ATS or a pipeline sheet, indexed interview debrief transcripts, the scorecard files.
Drafts: job descriptions from the scorecard, candidate follow-ups by stage, interview kits, debrief summaries from transcripts, the weekly pipeline note.
Never: rejects, advances, or scores a candidate; stores anything about protected characteristics; replies to a candidate without a person reading it.
Want these six written for your company?
The Growth package builds the context layer for up to six personas, with sources wired read-only and a runbook per role. From $10,000.
All six read the company decision log, because a teammate that does not know what was decided keeps re-proposing it. None of them read each other’s inboxes. The database view exists in two versions — an account-state view for support and sales, and an anonymised aggregate view for the CEO and HR — and neither has a write path. Memory is per persona: the sales contact log is not the CEO’s investor log, even though the same tool maintains both.
Nobody should build six on day one. Start with the persona whose inbox hurts most — for most small teams that is support, for founders it is often the CEO persona drowning in partnership and investor mail — get it to the point where 80% of drafts go out unedited, then add the next. The Starter package is exactly that: one persona, one inbox, one flow, from $1,000, on whichever tools you already use, hardened per the checklist.
A separate persona file and source list per role, yes — usually running on the same agent and workhorse. The CEO’s teammate and the HR teammate should not see the same data or write in the same voice; separating them is what keeps the setup safe and the output specific.
The one whose inbox hurts most. For most small teams that is customer support; for founders it is often the CEO persona handling partnership, press and investor mail. Get it to 80% of drafts sent unedited before adding the next.
It should not. The HR/payroll persona answers from policies and the pay calendar and, at most, an anonymised headcount and leave view. Anything about an individual’s pay, performance or medical situation is escalated to a person with no draft.