Playbook
the way I onboard people
AI Ops
Playbook
- 03Every chat is day one
- 04Onboard it like a new hire
- 05How I think
- 06The write back loop
- 07Same method, any function
- 08Three tiers of truth
- 09Who wins a conflict
- 10Notes that know they are old
- 11Two layers: me and the company
- 12Rituals and rollout
- 13Six mistakes I made
- 14Signs it works, and credits
Table of contents
I work in talent operations. My main job is high volume studio hiring at BEAT81, a fitness company in Berlin. Alongside it I run operations for Tort Claim Strategies, a US legal lead generation company. Onboarding people is the centre of what I do, so when I started working with AI agents I gave them what I give a new hire: a role, a definition of done, house rules with reasons, and feedback that sticks.
This playbook is that system. A folder of notes the agent reads before it answers and updates after it learns something. One layer describes how I work and travels with me. A second layer describes each company. I built it first at TCS and rebuilt it at BEAT81.
The onboarding lens: every people practice has an equivalent for an agent.
Rules of thumb: the do and don't list that makes the output mine.
The write back loop: how each session leaves the notes better than it found them.
Works with any agent that can read and write files. Mine is Claude Code on an Obsidian vault.
No database and no special tool. Plain text files, a little frontmatter and a short list of rules.
Calls
Decisions are made out loud. The AI summary gets some of them wrong and nobody checks the transcript.
Chats
An hour of context goes into one AI conversation and is gone when the tab closes.
Docs
Six versions of the same runbook, and none says which one is current.
Heads
The person who knows how invoicing works is on holiday this week.
Every chat is day one
A language model knows nothing about your business. It knows your team, clients and rules only if you put them in front of it, every time. Most people paste the same background into each new chat, which is like re-running induction every morning.
The alternative is a place the agent always reads first and always writes back to. After that, each conversation adds to what the next one starts with. The rest of this playbook is how I keep that place useful.
| Without notes | With notes |
|---|---|
| Paste the background | Agent reads the operating manual on start |
| Answer from a guess | Answer names the note it came from |
| Correct it again next week | Correction becomes a written rule |
| Onboard by shadowing | New teammate reads the notes the agent reads |
At TCS the measure was simple: the owner is no longer the only one catching issues.
A role
What it owns, what it does not own, and what done looks like.
A pack
The business in one screen, the vocabulary, who is who.
House rules
Each with the reason, so it can judge the edge cases.
Feedback
Given in the moment, written down once, never repeated.
Onboard it like a new hire
If I would not hand a new colleague a task without a role, an onboarding pack and someone to ask, I should not hand it to an agent that way either. Every practice I use for people has an equivalent.
| For a person | For the agent |
|---|---|
| Role profile | Scope, what it does not own, definition of done, named back in one line before work starts |
| Onboarding pack | Business brief, glossary, one note per person |
| House rules | Rules of thumb, one per file, each with a Why line |
| Buddy and shadowing | Read the area note and the last daily note before asking me |
| "Here is what went wrong last time" | Warnings tied to real past mistakes, inside every guide |
| Feedback | A correction becomes a rule in the manual |
| Probation check in | Weekly pass: what is stale, what is still open |
| Handover | Nothing lives only in one chat or one head |
Same checklist, different kind of colleague.
- 1
Context before instructions.
Every priority says why, what happens next, and who does it, decides and is informed.
- 2
Stable or volatile.
Rules are learned once. Numbers and owners are read live, or marked [VERIFY] with the date they were true.
- 3
True apart from should.
How it runs today and what would fix it are separate sections. The target is never written as if it exists.
- 4
Gaps are answers.
"Nobody", "To be mapped" and [OPEN] beat a plausible guess.
- 5
Real mistakes make the best warnings.
A generic caution teaches nothing. What actually went wrong teaches what it looks like from the inside.
- 6
Do less, finish it, then improve.
I tend to over build. This rule is for me as much as for the agent.
- 7
Judgement stays with me.
The agent spots patterns and challenges my assumptions, with reasons. I decide.
How I think
| Do | Don't |
|---|---|
| Lead with the answer | Open with background |
| Name the deliverable back in one line | Offer options unless the choice changes the work |
| Mark volatile facts with a date | State a number nobody checked |
| Link every source inline | Name a source without linking it |
| Number action items 1. and 1.1. | Use bullets for things people need to point at |
| Turn a correction into a rule | Fix it once and forget it |
| Report status, leave my tasks open | Mark my tasks done |
| Ask before anything goes out | Send, post or email on my behalf |
--- name: done-only-when-i-say type: feedback --- My tasks are done only when I say so. Why: in progress means touched, not finished. How to apply: report status, leave the item open.
One rule per file, each with its reason. The reason is what lets the agent handle a case the rule did not foresee.
The write back loop
Step five is the one most setups skip. Facts pile up; rules compound. When I correct how something is done, the correction goes into the manual, so I never give the same feedback twice.
Same method, any function
I built this first for lead operations, then used the same loop for hiring, onboarding, finance checks and ad operations. Nothing in the loop belongs to one team. What changes is where the knowledge comes from and which small rules matter.
| Part of the loop | In this function |
|---|
Rules shown are examples of the kind I write down. Each team's real list grows from its own corrections.
If a process can be taught to a new hire, it can be written down for an agent.
| Tier | Holds | Read when |
|---|---|---|
| A · current truth | Rules, people, clients, decisions, SOPs, this week's priorities | First, for every question |
| B · recent context | Processed calls, daily notes, trackers, drafts | When tier A has nothing, or is older than the question |
| C · provenance | Raw transcripts, exports, spreadsheets, old versions | Only to check a quote or a number |
Folders say where a note lives. Frontmatter says what kind of note it is. Saved views show the cross sections, so nothing has to move to be seen differently.
Tiers also save tokens. An agent that starts with tier A answers from a few short files instead of hundreds of transcripts.
Three tiers of truth
One home per fact. Everything else links to it.
- Source system data, read today. The CRM, the ATS, bank and invoice records.
- The owner's dated statement. Tagged with who said it and when.
- My own dated decision or my correction of a note.
- A client or partner in writing. Email, contract, Slack.
- Team members on calls or in chat.
- AI call summaries. Checked against the transcript underneath.
- Older notes and wikis, and figures inherited from someone who has left.
Who wins a conflict
The higher row wins. In the same row, the newer dated statement wins.
The agent reports both sources when they disagree.
| Marker | Means |
|---|---|
| [VERIFY] | Written down, but check the live system before acting on it |
| [OPEN] | Unresolved. Ask, do not guess |
Notes that know they are old
--- title: Lead delivery runbook v5 type: sop status: superseded superseded_by: "[[Lead delivery runbook v6]]" area: ops last_verified: 2026-10-14 sources: - "[[Meetings/2026-10-13 ops sync]]" ---
I started with seventeen free text statuses and no note marked as old. Four values with fixed behaviour, two markers, and a date on everything that can change.
# How I operate ← travels with me How I think, rules of thumb, working contract, knowledge loop # Company manual ← one per company The business in one screen, people, systems, vocabulary, house style, where files live # Live sources ← linked, never copied Dashboards, ATS, CRM, finance
Two layers: me and the company
| Layer | Holds | Changes when |
|---|---|---|
| Me | How I think, how work is handed to me, writing rules, the knowledge loop, guardrails | I change my mind |
| Company | Business brief, people, systems, vocabulary, house style and colours | The company changes |
| Live | Numbers, statuses, owners this week | Daily |
I keep my two jobs in two separate vaults, each with its own manual and its own colours, and never one deliverable across both. The personal layer is the same file in each. Pasted into a new tool or a new model, it gets the agent working my way in one step.
Same me, any company, any model.
| When | What happens |
|---|---|
| Start of session | Read the rules, the last daily note and the area note; state the situation in two lines |
| After each call | One processed note: corrections to the AI summary, decisions, facts, actions |
| End of session | Write back, then close with what was made, where it is, what is open |
| Each morning | Start of day note: today's three, what is dragging, what is untouched |
| Weekly | Empty the inbox, merge duplicates, re-verify old facts, archive what is replaced |
Rituals and rollout
Add
Manual, index, decision log, processed calls. Nothing moves.
Protect
Confidential notes into an ignored folder before anyone else gets access.
Automate
Scheduled clean up and a processing pass after every call sync.
Share
Teammates and their agents read the same notes.
Start with the data sources. The structure can follow.
- 1
I reorganised the folders three times in eight days.
Folders by document type answer no question. Saved views over frontmatter do the job without moving files.
- 2
Seventeen statuses, and nothing was ever old.
Now four statuses, and every retired note points to its replacement.
- 3
An AI summary invented a name nobody said.
Facts reach tier A from the transcript, not the summary. The processed note lists each correction.
Six mistakes I made
- 4
Daily numbers in notes went stale within days.
Link the live dashboard. Keep only the threshold or rule behind the number.
- 5
Sharing the repository made "private" untrue overnight.
A frontmatter flag does not stop a push. A separate ignored folder does.
- 6
Calls from one job synced into the other job's notes.
Filter at the source. A rule in the index is only a backstop.
A well designed document built on a fact nobody checked is worse than one that says "to be mapped".
Playbook
working
You stop re-explaining. A new chat starts with the right context because the agent read the manual first.
Answers cite notes. Each claim points to a file, and the file points to its source.
Feedback is given once. A correction becomes a rule and does not come back.
People onboard from it. A new teammate reads the same notes the agent reads.
Signs it works
- My manuals at TCS and BEAT81Where every rule on these pages was tested first.
- Colleagues at TCSThe tiers, the tagging and the ranking of sources came out of an ops sync in October 2026.
- Frameworks that helped me break it downTiago Forte's idea of writing down your rules of thumb, and Rachel Woods' view of AI operations as process work, from their conversation.
- Claude Code and ObsidianThe agent and the notes app. Everything else is plain Markdown.
I work in talent operations and business integration in Berlin. If you are building something similar in any function, I am happy to compare notes.