Back to home

Privacy

Effective date: October 27, 2026

This statement covers Playbook: the MCP server that AI clients such as Claude connect to, and the web app that comes with it. While we move the service to a new host, it answers at two addresses, and this statement covers both: https://cedarandloam-playbook.fastmcp.app and https://mcp.playbookcatalog.com, which will replace it. A copy of the web app is also published at https://playbook-catalog.pages.dev. We also run temporary test copies for each change we are working on: of the service at https://pr-<number>-playbook-mcp.fly.dev, and of the web app at addresses ending in playbook-catalog.pages.dev. The service’s test copies use the same database and the same companies as the service, so this statement covers them too.

It does not cover catalog content (the public skills), which is openly licensed in a separate repository. It also does not cover the older Cloudflare Worker endpoint (playbook-catalog.cedarandloam.workers.dev) from the earlier TypeScript build. That is a separate surface with its own data stores and is being retired.

If you connect Playbook to an AI client like Claude, this statement describes what we, the operators, see and store. The catalog itself contains no personal data of ours. A skill you contribute to it carries your user id and whatever you wrote in it, so leave out personal details you don’t want to become part of the catalog.

If you use the Personal Graph Claude skill, your Claude data export is parsed inside your own Claude session by code bundled with the skill. Nothing from the export (conversations, memories, labels or the page it builds) is sent to us. The only thing that reaches Playbook is a skill draft you choose to save through the playbook_draft and playbook_save tools, and that draft carries derived, solution-free content only.

Who we are

Playbook is operated by Playbook Catalogue LLC, the data controller for the hosted service. You can reach us at hello@cedarandloam.com.

Our rule for runs and skill-building chats

We keep what your runs contain for a short time, and a summary of each run for longer:

  • Step content: 30 days. What each step read and wrote, what you or an approver typed when a run asked for a decision (for an email approval, the approver’s address and part of their reply), error messages, any notes saved with the run, the records of Claude’s steps, the app data a decision record captured, the details of each change a training run would have made, and the error left by a schedule’s last failed run. We delete it 30 days after the run finishes (a decision record’s app data, 30 days after the decision; a training run’s details, 30 days after they were recorded).
  • Run summaries: 400 days. Which steps ran and how they turned out, how long they took, how much AI model use they needed, the apps and actions each step was set up to use, approval decisions, the titles and links of documents a run produced, which of your clients it was for, and the values the skill ran with, which can include names or email addresses you entered. We delete the summary 400 days after the run finishes.
  • Audit trail: 400 days. A tamper-evident record of what each step attempted: which app and action, in which environment, whether it was a test run, and whether it worked. It records each app read a Player makes the same way, and each one their quest refused before anything was sent, with the reason. It also records each time someone downloads a Player’s, a client’s or the account’s history, and when. Anyone in a team can read a client’s history; only a team admin can download it. It does not keep the values a step was called with. For each one it keeps the name of the setting, how big the value was and a fingerprint of it, so we can confirm a value you still have is the one that ran without keeping the value ourselves. We delete each entry 400 days after it is recorded.
  • No automatic limit yet: the run history we use to rank skills (counts and outcomes, with the notes cleared after 30 days), the rest of each decision record (the changes proposed and which version applied), and the text of your conversations with the AI assistant. We keep these until you ask us to delete them.

Using your content for anything beyond showing you your runs and fixing problems, such as improving skills or training AI models, is opt-in: we do it only if you choose to allow it, and we remove personal details first.

What we collect

When you use the service at all. Like any web service, our hosts see your IP address and basic details of each request. We use your IP address, in memory, to limit how often the AI assistant can be used without signing in, and we keep basic operational logs, which can include your user id, to run and secure the service.

When you sign in. Sign-in goes through WorkOS, our identity provider, which tells us your user id, email address and name. We put them in the sign-in tokens our server gives your AI client or the web app, and for team features we read your email address from that token while handling each request. To keep you signed in from an AI client, or from the web app at the same address as our server, our database also holds the tokens WorkOS issued, with the profile that came with them. The copy of the web app on playbook-catalog.pages.dev gets its tokens from WorkOS through our server without our storing them. We store them encrypted. They stop working when they expire, and our next daily cleanup deletes them. Those stored tokens carry your email address in the profile beside them, and so do team invitations and skill sharing (both below). The rest of the records described here are keyed to your user id rather than your email address.

When you set up a team. Teams are managed in WorkOS. When you create a team, we send WorkOS its name, and when you invite someone, we send WorkOS their email address so it can email them an invitation. WorkOS keeps the team’s members and their roles. Once you are on a team, the records we keep are linked to the team as well as to you, and everyone on the team shares the same business details (see below). When you share one of your skills with your team or a teammate, we store your email address with the share, the skill’s name, who may open it (the whole team, or the teammate’s email address) and whether they may edit it. Sharing one of your Players works the same way: we store your email address with the share, which Player it is, who may open the Player and whether each teammate may only view the Player, use them or also change their setup, and, for teammates who may use them, which of the Player’s own app logins you picked for their quests. Teammates you share a Player with see their work, quests and proposals. Teammates who may use a Player can also ask them for work in chats of their own and add files to their own part of the Player’s stash. Their quests use only the logins you picked, never yours, every change those quests propose waits for you or an editor, and those quests’ records are open only to that teammate, you and the Player’s editors. Teammates who may change their setup can also start their quests and decide their changes, and then the Player uses only their own app logins (see below), never yours. When a run a shared Player started waits for a decision, the email we send you about it also goes to each of those teammates, from your Gmail, at the address they signed in with. When a teammate changes a Player’s setup, starts their quest or decides one of their changes, we record who did. We also keep what each change to a Player’s setup was, yours or a teammate’s, for as long as the Player exists, so you can see what changed and put it back. Shares end when you remove them, delete the Player, or when you or the teammate leave the team.

When you save a skill. Personal skills, the ones in My skills, are documents you write, or build with the AI assistant. We store the text as you saved it, plus the account that saved it. We also keep the last 50 versions of each skill, with who saved each one, so you can go back to an earlier one; deleting the skill deletes them. If you connect a GitHub repository to hold your skills, we save them there instead and store which repository it is. You can delete your skills yourself.

When you schedule a skill. We store the schedule, its time zone, the values the skill should run with, the target it runs against, the client it runs for, if any, and the last error if a scheduled run failed. That error text is cleared when a later run succeeds, and in any case 30 days after the run that left it. We also keep a line for each scheduled run, saying when it ran and what came of it, for 90 days; the reason it gives for a failure or a wait is cleared after 30 days. You can delete a schedule yourself, and its lines go with it.

When you fill in your business details. “Your business” holds your business’s name, website and description, your ideal customer, buyer personas, brand voice and compliance guidelines. We store one set for your account, or one that everyone on your team shares, along with who last saved it. Skills that use these details fill them into their instructions, so they reach Anthropic with the rest of a Claude step (see below). If you ask the web app to draft them from your website, we send Anthropic your website’s address, and Anthropic reads that site and writes a draft for you to edit before you save it. You can change or clear them in the web app’s settings or with Playbook’s tools.

When you describe your own work. Optional onboarding and Settings → Context → Your work fields hold your role, typical day, work you want to make easier, and apps you use. We save these for you within your current workspace; other team members cannot read or change them through the app. Naming an app does not connect it or grant access. You can edit or clear these fields in Settings. If you choose to include them in a Player’s draft, that snapshot goes to the model that prepares the draft and stays with the resulting Player’s brief. Changing your profile later does not change that brief. Clearing the profile removes its content; the record retains your account and workspace identifiers and last-save time.

When you keep profiles for your clients. If you run skills for several client businesses, you can keep a profile for each one: the same business details as above, plus a few IDs such as its row in your Airtable. We store the profiles under your account or team, along with who last saved each one. A run or schedule for a client fills that client’s details into its skills, so they reach Anthropic the same way. You can delete a client profile yourself.

When you write pages for your team. Under “What your team knows” you can write pages about how your business works, for your whole account or for one client. We store each page’s title and text, whether every Player reads it at the start of each quest, and who saved it, along with the last 50 versions of each page so you can put an earlier one back. Your Players read these pages: when a quest starts we send the pages marked to read at every quest, and the titles of the rest, to the company that runs the Player’s model (Anthropic, or OpenAI for a Player set to ChatGPT), and a page the Player opens during their quest goes the same way. A Player can read your business details, or their client’s, the same way. We keep pages and their versions while your account is active, and a client’s pages while you keep that client; deleting a page deletes its versions. You can delete a page yourself. A Player can also suggest a page, or new text for one, which you accept or decline on their page. We keep their suggested title and text, the page as it read and their reason for 30 days, unless you accept it, when the text becomes your page; which page it was, which apps their quest had read and your answer are kept for as long as the Player exists.

When you set up a Player. A Player is an AI teammate you set up to run your skills. We store what you tell us about them: their name, role and goals, the apps and account IDs they may work in and the limits you set on them, the skills they can run, the client they work for, if any, how much they may do without asking, their weekly budget, the times they work, the days for each and, if you give one, the job for each time, whether they are working, and the Player’s personality (how the Player talks in chat, and a one-line description if you write one). Their brief is stored too: what they know about the job, with where each fact came from and when, and any brief or plan you pasted, word for word. We store it under your account. You can delete a Player yourself. We keep a deleted Player, with their brief, anything you pasted and everything else we store with them, out of sight for 30 days, so we can put them back if you ask, and then delete it all. If you ask the web app to set a Player up for you, we send Anthropic what you typed, any brief or plan you pasted, your business details, the profile of the client they work for, if any, a small read-only sample from the connected apps they will use (for example product names and stock counts, or campaign names, statuses and budgets, read through Composio the way a skill reads them), the names and descriptions of your skills and the Library’s skills, and the list of apps Playbook works with, marked with the ones you have connected, and Anthropic writes a draft for you to check. The same goes when you answer its questions or ask it to change one part of a Player, except that the app sample is only read for the first draft. Nothing is kept until you save. When you save a new one-line description of a Player’s personality, we send that line alone to Anthropic to check it is fit for work before we keep it.

When your Player goes on a quest. While a Player is on a quest you can start a quest, in which the model you picked for them (Anthropic’s Claude, or OpenAI’s ChatGPT) works as your Player for one session. We send that provider the Player’s record (as above, without the personality, which only chat uses), the recent runs and training results of their skills, the notes they left after earlier quests, and anything they read from the apps in their field (only actions that read, through Composio the way a skill reads them). If you leave a note for their next quest, we keep it with the Player and send it to that provider when that quest starts; it is deleted when a quest that used it finishes its work, or when you clear it, except the copy in their notebook (see Your Player’s notebook below). If you let the Player browse, the pages their browser opens go to that provider too, whichever one you picked. They can start their own skills, which run like any other run. For each quest we keep when it ran, why it started, how it ended, what it cost, the runs it started, the app action names it asked for that don’t exist, with how often (a name only when it is close to a real one; any other is just counted), and the note it leaves you; the note is deleted 30 days after the quest, and the rest is kept. A Player can also ask you to connect an app they need, or ask you a question about a job with a few options: we keep their words, your answer (the option you picked and anything you typed) and when you gave it, and delete their words and what you typed 30 days after the ask closes, except the copy of your answer in their notebook. When you have more than one account for an app and haven’t picked the one a Player uses, we ask you which: the ask lists those accounts by the names you gave them, and those names are deleted from it 30 days after it closes too. Each ask also records who started the quest that raised it, the job that quest was for and the chat it came from. When a teammate started it, we keep their sign-in email with the ask, so its owner sees who asked, and delete the email 30 days after the ask closes too; a question on their quest is theirs to answer, and their answer is kept the same way as yours, without the copy in their notebook. When a quest was asked for and didn’t start yet, or didn’t start at all (a skill it started finished, a restart cut it off, its budget was spent, it was more than an hour late), we keep a short record: which Player, why, the reason it didn’t start, and the run or quest it points at, never anything you or the Player wrote; it is deleted 30 days after it last changed. When a quest starts, we also send that provider a short list our code builds from the Player’s last ten quests and the changes decided in the last 14 days: action names they asked for that don’t exist, with real ones close to them; the setup problems they hit; how many of their changes with each action you turned down, never what you wrote about them; and approved changes that failed, with the action and the kind of failure. So you can watch them work, we also keep a list of their steps: the pages they opened (never what they showed), what they clicked, the app actions they called and short notes of what they said as they went, never what they typed into a page. This includes brief progress updates from the working model, linked to the request they describe. These updates are for people to read and are not fed back to another agent as instructions. The list is deleted 30 days after the quest. Each skill they start also gets a decision record: the skill and its version, the run, the goal it served, how sure the Player was and why they started the skill. Their reason is deleted after 30 days, and a short summary of it after 400 days. A job none of their skills fits gets a decision record too: the job in a sentence, the app actions they read, what they would do and why no skill fits, deleted after 30 days, and a short name for the job, which we keep. When the same job comes up often enough, the Player offers to make it a skill; we keep the offer, your answer and the name of the skill. If you say yes, we send Anthropic that Player’s records of the job, and the notes they left after those quests, to draft the skill, which is saved as one of your private skills. When a skill fits the job but the Player would do it another way, they can say why and give their own version as exact app actions. The skill still runs as written. The Player’s version runs alongside it: actions that only read go to the apps in their field, and every other action is recorded, never sent. We keep their reason, their version and what that version would have done, so you can compare the two; those details are deleted 30 days later, and we keep which actions they named, what each would have done and your decision. A Player may also suggest new wording for one section of their own brief. We keep the wording they suggest, the wording they would replace and their reason for 30 days, and which section it was and your answer for as long as the Player exists. Nothing in the brief changes unless you accept it.

How we find problems that keep coming up. Once a week our code counts, across every customer’s Player quests, the problems that came up in more than one quest: app action names that don’t exist, setup problems, quests that failed or ran out of their budget, approved changes that failed and the actions of changes owners turned down. Each one becomes an issue in our own private GitHub repository, with its counts and the ids of up to five of those quests, so we can fix it. It holds no names of people, nothing you wrote and no account ids; of what a Player wrote, only the action names they guessed that are close to real ones.

Your Player’s notebook. A Player keeps a notebook: short notes they write down to do their job better, such as what they learned about your business, where they got to and what is still open. We store every version of every note, with the quest it was written in, the apps they had read in that quest before writing and, if they use a web browser, the sites they may visit. We send its index and its working rules (the start of the notebook) to Anthropic when each quest starts, and any note the Player reads or searches during a quest. Once a week we send the whole notebook to Anthropic to tidy it: logs move to the log, repeated rules are merged and old status lines are dropped. Every earlier version is kept and you can put it back. When the same problem shows up in several of a Player's quests, the Party Lead writes them a one-line lesson from the counts and codes our systems recorded, never from what the Player read or wrote; the line goes into the notebook, you can take it back, and it is taken back on its own when the problem keeps happening. The notebook also holds a copy of what you tell the Player: a note for their next quest, your note on a job or a training run, your answer to a question they asked, work you sent them, and what you say about it to the Party Lead, each as a dated line in your own words. We keep those lines with the notebook, for as long as the Player exists, and send them to Anthropic with the rest of the notebook. We keep the notebook, every version, for as long as the Player exists. You can read it and delete it. When you delete one note, its earlier versions stay so you can put it back. When you delete the whole notebook, or the Player, we keep it out of sight for 30 days, so we can put it back if you ask, and then delete it.

When your Player attaches a screenshot. A Player's web browser reaches the sites you list, or any public site when you allow it and your team permits it. It stays signed out except on sites where you saved a sign-in, and it never reaches our own systems. If you let a Player browse and give them GitHub and one repository, they can attach the screenshots they take to the issues they file there. We read the screenshot from their browser and save it, through Composio, on a branch named qa-screenshots in that repository, where it stays until you delete it. A screenshot shows whatever the page showed, so only let them visit sites whose pages you are happy to keep in that repository. A Player in training mode attaches nothing.

Your Player’s stash. A Player has a stash: files their quests deliver, such as a weekly report, and files you and your teammates add to it. Each file is in one of two parts: the part everyone who works with the Player can see, or one person’s own part, which only that person can open. A quest’s result goes in the own part of the person who asked for it. The Player’s owner sees the name and size of the files in other people’s parts, and can delete them, but can’t open them. A file in someone’s own part can be shared with everyone who works with the Player. The owner and editors share their own files at once. A teammate who may use the Player but not change it asks instead: the file stays in their own part, and the owner and editors see its name, its size, who asked and where it came from (for a quest’s result, the apps and sites that quest read), until one of them shares it or keeps it private. The owner also sees who asked, without the file’s name, in what is waiting on them. We record who shared each file and when. When an ask is turned down we record when, and the teammate can ask again a week later. We store each file in a private store at Supabase, with its name, type and size, who added it and, for a quest’s result, the quest it came from, the apps that quest had read and, if the Player uses a web browser, the sites they may visit. Nobody gets a lasting link to a file: a link is made when you open it and stops working after an hour. A file can be a picture (PNG, JPEG, GIF or WebP), PDF, DOCX, XLSX, PPTX, text, Markdown, CSV or JSON, up to 20 MB. Finished files also appear in Relics under the same access rules. We keep a file until someone deletes it, and remove it within a day of that. We delete a Player’s stash 30 days after the Player is deleted, and a person’s own part of it 30 days after their access to the Player ends. A file they shared with everyone stays after that. A quest can open the files in the part everyone sees and in the own part of the person who asked for it, never anyone else’s. Its opening lists those files by name, never what is in them, and a file it opens goes to the company that runs the Player’s model, Anthropic, or OpenAI for a Player set to ChatGPT: the text of a text, Markdown, CSV or JSON file, extracted Office document contents, the text in the first 50 pages of a PDF, or a picture made smaller, to at most 1568 pixels on its long side. Models that support image inspection receive the image; other models receive its name and cannot inspect it. We note which files a quest opened, as we note the apps it read, so a note or result it writes afterwards says it came after reading its stash.

Your own files in Relics. You can upload a file in Relics without choosing a Player. It is yours alone: only you can see, open or delete it, and only in the team you were signed in to when you uploaded it (or your personal account). We store it the same way as a stash file, in the same private store at Supabase, with the same file types and limits, and no Player or quest reads it. When you attach it to a Player, it moves into your own part of that Player’s stash and the rules above apply from then on. We keep it until you delete it, and remove it within a day of that. A file you uploaded in a team is deleted 30 days after you stop being a member of that team.

Your Player’s reports. A Player can make you a report page, such as a monthly Google Ads report, shown under Relics. The page and the figures it reads are stored in our database at Supabase, and those figures may come from the ad accounts you connected, read the way a quest reads them. The page runs only inside Playbook, walled off from the rest of the app and unable to call out to other sites, and only pages built from Playbook’s own report templates are shown. Nothing a page suggests happens until you approve it. Who made a change in your ad account is described by role (Google, the API, a person in the account), never by name or email. We keep a report until you delete it; deleting removes the page and its figures at once and keeps only its name, which Player made it and when its figures were pulled, so the list can still say what was there. A Player can also read the figures of the reports it made itself, never their page, when a quest needs them; what it reads goes to the company that runs its model, as a file it opens in its stash does, and we note which reports it read, so a note or result it writes afterwards says so. A quest someone with use access asked for reads only the reports made for that person. A Player can also file a report itself during a quest: the headline, text and tables it wrote, with which quest made it, who asked for it and which apps it had read. We store it in the same database, show it on Playbook’s own report page, never on a page the Player wrote, and leave the person who asked a note in their chat that links to it. A report a quest files for someone with use access is shown only to them, the Player’s owner and its editors.

The machine your chat works on. A Player chat keeps the machine its requests run on between messages, so a follow-up starts in seconds. Files and browser data the Player’s earlier requests in that chat left there stay on it, and only requests in that same chat use it. Archiving the chat keeps the machine; deleting the chat deletes it, and a check every six hours deletes any machine whose chat is gone.

Your conversation’s working files. A Player conversation can keep unfinished files, imported inputs and prior versions on a separate machine at Fly.io. These files belong to that person’s conversation, independently of its executing quest. Inputs are copied only from files that person can access, with their source recorded, and remain read-only until copied for editing. Coding conversations also hold an isolated repository checkout. Idle, Stop, restart and archive do not delete working files; no automatic expiry is applied to them. Erasure requests include these machines and their files. Files the Player reads go to their selected model provider as described above. Delivery copies a finished file into Supabase and the requester’s chat and Relics. Later edits to working files do not change that delivered copy. People with permission to edit a delivered text file can update it in Relics; those changes are saved in the same private Supabase storage. Replaced file contents are removed by the existing orphan cleanup.

When your Player runs code outside a conversation. If you let a Player edit and run code, they get a second machine of their own at Fly.io. That machine holds a copy of the one repository they work on, at the branch you chose, with the tools and packages their setup installs. It downloads those while it is set up and then reaches nothing on the internet, and it holds no passwords or keys of ours. Each quest starts from a fresh copy. We delete that machine within seven hours of you turning off code or deleting the Player. You, and anyone you share the Player with, can see the files they are changing there: we read them from the machine when you look, compare them with your repository’s own copy, and keep nothing. When they hand in a change, we keep the changed files, the difference and its summary for 30 days, then only its title, the repository, the issue it fixes, the file names and how many lines changed. Once you approve, a draft pull request opens in your repository through the Player’s GitHub login.

When your Player proposes a change. Outside their skills, a Player can’t change anything in your apps unless you let them make changes on their own. When they want to, they propose the exact changes with their reason, and we store the proposal until you approve or reject it in the Mailbox or it expires. When you approve, we make exactly those changes through your connected apps, once, and read the result back. If you let the Player make changes on their own, a proposal our code finds inside their apps, accounts and limits goes to the Party Lead, which sends Anthropic the changes, the Player’s goals and limits, and their recent decisions, never what the Player read in your apps. If the Party Lead has doubts, the proposal waits for you with its one-line reason. Otherwise it is made at once without waiting: we read what it will change first, make exactly those changes, and read the result back, and the Mailbox shows what it was before so you can set it back. The reason, the Party Lead’s reason, the changes and their details, what we read before the change and what your apps answered are deleted 30 days after the proposal was made. We keep which Player proposed it, which actions and what kind of change each was, how much it counted toward the Player’s limits, whether the Party Lead approved it, and who decided (you or our limits check), when and from where. Each decision and each change we make are also written to the audit trail, which keeps fingerprints of the values rather than the values. For each Google Ads budget a Player changes, we keep the budget’s id and one amount that its later changes are measured against: the amount you last approved, or the amount we read the first time a Player tried to change it on their own. We delete it 400 days after it was last set or used. A change raised on a quest asked for by a teammate who can use the Player but not change it always waits for you or an editor, whatever the Player’s settings, and their chat says so. The change’s card, which you and the Player’s editors see, names that teammate by the sign-in email on their request, and so do the Mailbox, a suggestion such a quest raises and the notice before the change expires. We read that email when they are shown and don’t store it again.

When your Player’s changes are checked. You can give a Player checks: named rules their changes must pass. The Party Lead suggests them from the Player’s name, role, goals, apps, limits and brief, which we send to Anthropic for that, and none runs until you approve it. When you reject a change and ask for a check like it, we send Anthropic that change and the reason you typed, never the Player’s own reason. Every change the Player proposes is scored against the checks you approved. A rule check runs on our server. For a check the Party Lead scores, we send Anthropic the check’s name and description and the changes the Player proposed, never what they read in your apps or their reason. The checks stay with your Player until you change or remove them. With each proposal we keep each check’s name, whether it passed and its numbers; the Party Lead’s line on each check is deleted 30 days after the proposal was made. The first time you mark a Player’s training change right or wrong, it is scored the same way, and we keep only each check’s result, to show how often each check agrees with you.

When your Player finishes a job. For each job a Player works on, we keep how it ended (done, not done, blocked or failed), who said so (the Player when they check in, a skill they started when that run ends, or you), when, and your verdict on whether it was done well, if you give one. We delete the job’s name and the note on its outcome 30 days after the job closes, except the copy of your note in their notebook. A job you give a Player (its title and any other names you merge into it) is kept while the job is open; we delete them 30 days after it closes or you drop it. For each job, we also keep which of the things you asked for our server found (yes or no, and references to them), for as long as the Player exists. When a change the Player made created something in your apps, such as a GitHub issue or pull request or a Webflow CMS item, we keep a reference to it: the app, what kind of thing it is, its id and the repository or collection it is in, never its title or what it says. Seven and fourteen days after the job closes, and when you open the job, at most once an hour, our server reads each of those things once more through your connection (or the Player’s own login for that app, the way the Player reads it) and keeps only its state, such as open, closed as fixed, closed as a duplicate, merged, published or deleted, and for a pull request, whether its checks pass. With what each job cost, these records show you how your Players’ work went and what a finished job costs on each model. We keep them while the Player exists.

Your Player’s level. Before a Player starts a job, the model about to do it picks a size for it (one of five, from extra small to extra large), and we keep that size, the number it maps to, and which model and sizing rule chose it. For each model call made for that job we keep a server-made call id, the token counts the model provider reported for it, and whether those counts are complete, missing or still expected. When the job’s result is delivered and every call’s counts are in, we record the XP the job earned (its size number times its token count), how it was checked, and the job’s revision at the time; a job you reopen gets a correcting entry, never an edit. These records hold only ids, sizes, numbers and times, never the job’s title, what the Player wrote or what the model said, and they are what the level and progress bar on a Player are drawn from. A message you type directly to a Player in the web app also earns 5-25 XP once accepted. For that reward we keep the message’s id, the Player’s id, a token estimate based on the message’s length, the points and the time, without copying its text into the XP record. Deleting the chat keeps those earned points. The Party Lead’s own level is built the same way from the work it does itself, today the project plans it writes and you approve, under your account and team, never from your Players’ jobs. We keep these records while the Player (or, for the Party Lead, your membership of the team) exists; deleting notes, chats or an old job’s title does not change a level. Token counts on a call older than 400 days are cleared, leaving the call’s id and state, and the job’s total is kept.

When a new issue starts a quest. If you set a Player to start a quest when a new issue with a label you chose is filed in one of the GitHub repositories in their field, our server checks that repository for new issues every few minutes through the Player’s GitHub connection (their own login for GitHub, or yours when they have none). We keep only issue numbers: the newest one we have seen, and the matching ones still waiting for a quest, which we drop once a quest starts with them. We never keep an issue’s title or what it says; the quest reads the issue itself, like any other read. We keep the numbers until you remove the Player’s last issue rule, or the Player.

When a mention on GitHub starts a quest. If you set a Player to start a quest when people you list mention a name you chose in a comment in one of the GitHub repositories in their field, our server also reads that repository’s new issue and pull request comments every few minutes, through the same connection. It reads what a comment says only to look for the mention, and keeps none of it. We keep only the newest comment id we have seen and the issue or pull request numbers still waiting for a quest, which we drop once a quest starts with them. A comment from anyone not on your list, from a bot, or from the Player starts nothing. When the Player is live and has their own GitHub login, they add an eyes reaction to each comment that started a quest, from that login, so the person can see it was picked up, unless you set GitHub to read only for them; that reaction is visible on GitHub like any other. We keep the id and numbers until you remove the Player’s last mention rule, or the Player.

When you try a change to a Player side by side. When you start a trial, we make two training copies of the Player and keep a record of the trial: which Player, the two copies and their quests, which settings you changed and the model and effort on each side, when it started, ended and closed, which side you picked, and the numbers we compared (how each job ended, how many changes of each kind it would have made, how they scored on your checks, credits, failed app calls, minutes and token counts). We delete the job you gave it, the new instructions you tried and your note on the pick 30 days after the trial starts. The copies and their quests are deleted when you close the trial or 7 days after both quests end. What the copies would have done (their training records, the changes they proposed and their skill runs) is kept and deleted like any Player’s, as this statement describes above. We keep the rest of the trial’s record while the Player exists.

When you connect an app. Connections to apps such as Gmail, Google Calendar, Google Sheets and Slack go through Composio. When you sign in to an app, Composio keeps the access that sign-in grants. When an app needs an API key instead, the key you enter passes through our server to Composio, which stores it. We keep only the reference ids that tie your account to those connections, never the tokens or keys themselves. For each connection we also keep when a call through it last got an answer and when one last failed, with a short reason code, so we can tell you when a connection stops working; nothing the call sent or got back is kept. For some apps we also read and keep the email address or name of the account you connected, so you can tell two connections to the same app apart. If you ask for an app we don’t offer yet, we store the request and any reason you give. When you let a skill use particular app actions, we store that approval: which skill, which actions and when. You can take it back with Playbook’s tools. If you connect Slack, we send you urgent notices about your Players as a direct message through your own Slack connection. Without Slack, or with these turned off in Settings, they come as an email from your own Gmail if you connected it. A notice holds only the Player’s name, what happened and a link to the Player in the web app, and, for an ask or a change raised on a quest a teammate asked for, that teammate’s sign-in email, whichever way it is sent. When a quest of a Player you own delivers a result to you, we send you one notice saying so: a Slack direct message the same way, or without Slack, or with these turned off, an email from your own Gmail if you connected it. It holds only the Player’s name and a link, and never goes to your teammates. A result a quest delivers to a teammate shows only in the web app.

When you add the Party Lead to Slack. When your workspace adds the Party Lead to Slack, we store the workspace’s id and name, the Party Lead’s Slack user id, who added it, and the access token Slack issued, encrypted in our database. When you message the Party Lead in Slack, we receive your Slack user id, the message, and the channel and thread ids. We ask Slack for the email on your Slack profile to match it to your Playbook sign-in, and we don’t keep the email. Your messages become part of your Party Lead conversation under the same 30-day rule, and reach Anthropic the same way web chat does. We also keep a copy of each message in a delivery queue until it is answered and for seven days after, so a restart of our servers never loses it. The Party Lead’s replies, and a Player’s replies when you bring one into the thread, are sent to Slack. The only thing a Slack message can change is a note for a Player’s next quest, in your exact words. Disconnect removes the token and the workspace record. Messages from other bots are ignored.

When you add the Party Lead to Microsoft Teams. When you connect the Party Lead in Microsoft Teams, we store your Teams organization’s id, the address Microsoft gives us to reply through, who connected it and when. We store no access token for Teams, because Microsoft issues one to our app on each reply. When you message the Party Lead in Teams, we receive your Teams user id, the message, and the chat and thread ids. We ask Microsoft for the email on your Teams account to match it to your Playbook sign-in, and we don’t keep the email. Your messages become part of your Party Lead conversation under the same 30-day rule, and reach Anthropic the same way web chat does. We also keep a copy of each message in a delivery queue until it is answered and for seven days after, so a restart of our servers never loses it. The Party Lead’s replies, and a Player’s replies when you bring one into the thread, are sent to Teams. Teams doesn’t let an app post under another name, so the Party Lead posts a Player’s replies with the Player’s name in front. The only thing a Teams message can change is a note for a Player’s next quest, in your exact words. Messages from other bots are ignored. Disconnect removes the record.

When you give a Player their own login. You can connect an app to a Player with an account made for them, such as claude@yourcompany.com, instead of your own. The connection goes through Composio the same way, kept under the Player rather than under you. Right after you sign in, we ask the app which account was connected (for Gmail, its address) and keep that address with the Player to show you. If it is your own sign-in address, or the address of anyone in your team or invited to it, we remove the connection at Composio and keep the address only to tell you why. To check, we read your team’s addresses from WorkOS, our sign-in provider, and don’t keep them. When the Player uses that app they act as that account, and the audit trail records that they did. Disconnecting all of a Player’s apps removes those connections at Composio as well as in our records. The addresses stay with the Player until you delete them.

When you run a skill. A run can leave four kinds of record in our database:

  • Run history. A short record of each run: the skill’s name, whether it succeeded, how long it took, any notes you add, the account that ran it and its plan tier, and, when your client provides them, a run id and the options you chose for the run’s steps. This record does not hold what the steps produced. We rank skills on how many runs succeed, never on your notes. We clear the notes 30 days after the run and keep the rest of the record until you ask us to delete it.
  • Run report. When you are signed in, we also keep a report of each finished run. It includes what every step produced, any answers you gave during the run, and the values the skill ran with (its variables). That can be content from your apps: for example email senders, subjects and snippets, message text, Slack user and channel ids, and summaries a Claude step wrote. Before we store a report, values that look like passwords, tokens or API keys are masked and very long outputs are cut short. Reports let you, and the AI client you use with Playbook, look back at past runs. After 30 days we delete what the steps produced, your answers and error messages, and keep the run summary described in our rule above, which we delete after 400 days.
  • Paused runs. A skill that pauses partway through, for example to wait for your decision or for a reply to an email, is held on our server. So that it can pick up where it left off, the paused record includes the outputs produced so far, the original run arguments (tools, selections, environment, target) and, optionally, a step-by-step trace. When the pause is there because a step wants to do something that cannot be taken back, it also holds that exact proposed action — the tool and the arguments it would be called with, which can include a recipient and a message body — so that you can read what you are approving instead of approving a step and finding out afterwards. It is kept as proposed, unmasked, because an approval that showed you something other than what would run would be worthless. It is removed when the run resumes or when you abandon it. A paused run nobody resumes is deleted 30 days after it paused, unless it is still waiting for an email reply.
  • Claude step records. For each Claude step we store a decision record: the model’s answer and the checked output of that step, keyed by run id, step id and a fingerprint of the step’s inputs. This lets a later run replay the step instead of paying for the model call again. Because it captures model output, a decision record can contain generated text, including text drawn from your apps. We delete it 30 days after the run, so replaying an older run calls the model again.
  • Decision records. When you approve a set of changes a skill proposed, and the skill is set up to record its decisions (today, the skill that quests ad budget to what’s in stock), we keep a record of that decision: the skill and its version, the run, the changes it proposed (for example each ad campaign, what changes, the old and new value, and why) and that the skill’s own version was the one applied. It also keeps what the skill read to reach those changes, which is data from your apps such as supplier stock rows, product prices and costs, and ad campaigns with their budgets and spend. That data is deleted 30 days after the decision; the rest of the record is kept so that the outcome can later be compared with what was decided. That includes the identifiers needed to measure it: the Google Ads account and campaign IDs, the supplier sheet’s ID and the SKUs involved, and which of your connections to read through. Seven and fourteen days after the decision we read that account’s ad spend and that sheet’s stock again through your connection and keep only the resulting number. Test runs record nothing.
  • Training runs. A training run reads your real data but sends nothing that could change anything. Instead, for each change it would have made (an email it would have sent, an ad budget it would have changed) and each approval it would have asked you for, we keep a record so you can review it: the run, the skill, the step, the app action, what it would have sent (which can include a recipient, a message body or campaign values; values that look like passwords, tokens or API keys are masked first), a one-line summary, and your verdict on it (agree or disagree, and a note if you add one, which also goes into the Player’s notebook). We delete what it would have sent and the summary 30 days after they were recorded, and keep the rest, including your verdict, so you can see how often you agreed before letting a skill make changes for real.

When a skill has Claude steps. Claude steps run on our server, using our own account with Anthropic. For each one we send Anthropic the step’s instructions and the text of the skill it belongs to, the values the run started with and any business details the skill uses, the results of earlier steps, and the results of any app actions Claude takes during the step. Those results can include content from your apps, such as the emails or messages a skill reads. If your AI client runs a skill’s steps itself, Claude steps run there instead, under your own account.

When you choose Use this computer. For supported short text tasks, Playbook sends instructions from your browser to Gemma 4 12B running in Ollama on that computer. Keep Ollama running and the tab open. Playbook still receives the task inputs and results and keeps the usual run record. This integration gives the model no file or app tools, sends no Playbook credentials to Ollama, and does not select cloud models or fall back to them. Ollama and its installed model aliases are software you control. Connecting the Playbook website grants it access to Ollama’s local API, including model management. Browser-relayed results are recorded as client-reported work, with Ollama attribution kept for the run report’s 30-day content window.

When we count your AI usage. Claude steps in your skills, drafts of your business details or a Player, the notes the Party Lead writes and your chats with the Party Lead are counted against your organization’s credits. Chats with the AI assistant while you build a skill, and with one of your Players, are recorded the same way but don’t use credits for now. For each call to Anthropic we record your organization, your user id, the run, skill and step it belonged to, the Player or client it was for, the model, how many tokens it used, what it cost us and how many credits it used. For each recording we turn into text, we record its length and what it cost us. The record never holds what was sent or what came back. We also record each grant of credits, and each hold we place on credits while a call is running. With each call from a Claude step, a draft or a Party Lead note, we send Anthropic an opaque code for your organization, a one-way hash rather than your name or email, so that misuse can be traced to one account.

When you pay for a plan or credits. Payments go through Stripe. You type your card details into Stripe’s own pages, so they never reach us. When your organization first pays, we send Stripe your organization’s id and the email address you signed in with. We keep your Stripe customer and subscription ids, your plan and seats, its status and billing period, your auto top-up settings, and a note if a payment was refunded or disputed, or if refunds for failed runs pass a quarter of your usage, so that a person can look into it. We record each payment event Stripe sends us by its id, so none is applied twice.

When a skill uses your apps. Each app action, such as reading an inbox, posting a message or adding a spreadsheet row, goes through Composio, which calls the app for us. Composio sees what the action sends and what the app sends back, for example email content or message text.

When you build a skill with the AI assistant. The assistant in the web app’s editor runs on our server. It sends Anthropic what you type and your answers to its questions, along with the catalog entries it looks up and the draft it writes. This happens whether or not you are signed in.

When you are signed in, we also keep two things. The first is the text of that conversation (the messages you send and the assistant’s replies), so problems with the assistant can be looked into. Kept with that conversation is a record of each step the assistant took by itself, such as looking something up in the catalog: the name of the step, a short description of it with personal details removed, and how large its result was, but never the wording it used or what came back. The second, for each session that produces a draft, is a short summary linked to your account: the kind of job, the apps involved, rough timings and what the session cost us to run, with none of your words. Because the summary holds none of your words, it is not content under our rule above; we use it to understand what people are trying to automate and to decide which skills to build next. The web app at cedarandloam-playbook.fastmcp.app runs its assistant on a separate server that keeps neither. There is no automatic limit on how long we keep them yet. We use the conversation text for anything else, such as improving the AI models that help you build skills, only if you opt in, and we remove personal details first. The text is never sent to PostHog or any other analytics provider. We keep neither if you are not signed in, or if your browser sends the Global Privacy Control (Sec-GPC) signal. You can ask us to delete your conversations at any time (see “Your rights” below).

When you use the Party Lead. When you are signed in, the web app has a chat panel, the Party Lead, on every page that can explain your skills and runs and change the skill you have open. It runs on our server, on our own account with Anthropic. Each message sends Anthropic what you type, what you are looking at (the page, and which skill, run or step), a text copy of that page (its words, its buttons and what you have typed into its fields, never a password), the text of the skill you have open, a short note of your earlier chat and your last 20 or so messages and replies. If you pick another company’s model in the chat’s model menu, such as OpenAI’s ChatGPT, the same goes to that company instead, on our own account with it. When you ask about a run, it also sends the stored report of that run, which can include content from your apps. To pick up where you left off, we keep, tied to your account and the team you are signed in to:

  • each message and reply, with what you were looking at and which skill or run it was about (never a copy of the skill, the run or the page). We delete these 30 days after they were written.
  • one short note that sums up older messages, written by Anthropic’s Claude model from those messages. We keep it until you clear your chat, your account is deleted, or you are removed from that team.

You can also open a chat with one of your Players and ask questions or request work. The Player’s selected model provider receives your request, its working context and the recent messages from that conversation. Older messages are summarized by Anthropic into a separate memory for that conversation. The summary stays until you clear or delete the conversation, delete the Player or account, or leave the team. Original messages and replies keep the existing 30-day retention rule.

Authenticated AI clients you connect can send assignments to Players and read your own Player conversations and replies, including shared page snapshots and attachment metadata already in those conversations. These messages use the same retention and model-provider handling described here. We label client-sent messages as MCP-origin; they are not human approvals and do not change the Player’s permissions.

Each message you send in a Player chat automatically includes up to 8,000 characters of visible page text, control labels, disabled controls and non-secret form values, along with the page name, relevant item references and the time it was captured. Chat transcripts, message composers, password fields, identified credential fields and the Secrets page are excluded. This is a snapshot taken when you send, not continuous screen access. We save it with that message and send it to the Player’s model provider, including when the request resumes. Earlier snapshots can appear in that conversation’s recent history or its summary. Snapshots are deleted with their messages after 30 days; summaries follow the conversation’s existing deletion rules. If you approve a Player’s report of a supported setup problem, we send the problem code, app, occurrence count, Player name and ID, your account ID and recent affected quest IDs to our private issue tracker on GitHub. The approval card shows the report before it is sent. Page snapshots and chat messages are not included in that report.

If you own the Player, can edit them or can use them, you can add files to a message with the + button. Each file goes in the Player’s stash first, in the part everyone who works with the Player can see, or, if you can use the Player but not change them, in your own part, which only you can open, as “Your Player’s stash” above describes. The Player can read authorized attachments through the same file tools, sending their contents to their selected model provider as described above. The saved message keeps each file’s name and size, never what is in it, so later messages send only its name. To keep to the limit of 20 attached files a day, we also note how many files each message carried and when, and delete that note a day later; clearing the chat leaves it until then. You can keep separate conversations with the Party Lead or a Player. Only the selected conversation’s recent messages and its own summary go with each new message. The original Party Lead chat retains its separate summary. We also keep a conversation ID, its Player if any, creation and activity times, and a title taken from the first 80 characters of your first message. These small conversation records remain until your account is deleted or your team membership is removed; deleting a Player also deletes their conversation records. Starting or switching chats does not clear earlier messages. Quest reports, proposed changes and the results a quest delivers return to the conversation that requested the work. A result’s text is kept there as a message, sent with later messages in that chat like any other, and deleted after 30 days like the others, even if its file is deleted from the stash sooner. A quest that wasn’t asked for in a web chat (one on a schedule, one you started with a button, or one asked for in Slack or Teams) reports to a chat we keep for the person who started it, one per Player, with a title we set. Its record and messages are kept and deleted the same way. A quest asked for in Slack or Teams still reports back there too.

When you talk with your team. If you are in a team, the web app has a room every member of the team can read and write in, and direct messages between two members. These are for people: a message goes to our server and is stored there, and no AI model reads it. We keep each message, tied to your team and to who wrote it, and delete it 30 days after it was written. You can delete a message you wrote at any time, and a team admin can delete any message; a line saying a message was deleted stays in its place. When you are removed from a team, your direct messages and your messages in the team room are deleted.

After each of a Player’s quests, the Party Lead writes a short report into your chat with them. To write it, we send Anthropic facts about the quest that our code counts: how it ended, what it cost against its budget, how many runs it started, how many changes it proposed and what happened to them, the names of its checks with how often they passed, which setup problems it hit and how many training entries it logged. Nothing the Player wrote goes with them. The report is kept and deleted like the other Party Lead messages.

Once a week, and once a month, the Party Lead also writes a short summary of what the Player did, from counts our code gathers (quests, changes, jobs, credits), never from anything the Player wrote. We delete each summary 400 days after it is written.

When you accept a work request in a Player chat, we store your original message separately, with its author, delivery choice, order, status, linked quest and originating conversation ID. Clearing chat history does not cancel accepted work. Active and blocked instructions remain until you cancel them or delete the Player. We delete completed, failed and canceled instructions after 30 days, except the copy of your words in the Player’s notebook. Instructions are deleted when the Player or your account is deleted, or your team membership is removed. The Player sends accepted instructions to their selected model provider when they work on them. Teammates with access to the Player can see accepted work and its status.

While a Player writes their reply to a message in their chat, we may keep the reply so far, so the chat can show it word by word. Only the latest text is kept, one copy per quest, readable by the Player’s owner and the person who asked. We delete it as soon as the whole reply is in the chat, and anything left after a quest stopped part way is deleted within about an hour and a quarter. The finished reply is kept like the other chat messages. We also keep the latest progress update separately from the reply preview, with the same access rules and short expiry. It can remain after the reply preview is cleared. If the saved activity list reaches its limit, the latest update can still change, but further updates are not added to that history.

When the Party Lead coordinates a project, we keep its versioned plan, step briefs, Player assignments, approval, progress, quest links and checked hand-over values with its originating conversation. Step handovers carry only named, checked values. Active and blocked projects stay until stopped or the originating conversation or account is deleted. Finished or stopped projects are deleted after 30 days, as are unapproved drafts after 30 days without an update. Removing your team membership deletes its projects. Deleting an assigned or invited Player, including a former party member, also removes the project and asks its running work to stop. Other work on the remaining Players continues.

For an explicit project party, you choose which Players to invite and which exact notebook versions to share. Their whole contents and your shared project brief go to the invited Players for planning and remain available during approved project work, using the same model providers and storage services described here. We keep the party membership, shared context references, assessments, challenges and resulting plan revisions with the project, under the same deletion rules above. Inviting a Player does not grant access to apps or permission to act. Removing a Player or a shared source limits future access, but cannot recall content already delivered to a model or person.

During a party review, Players may check current facts using read-only actions already allowed by their app and account settings. We share bounded results, the checking Player, source action and check time with the project party and its model provider, and keep them with the review under the project's deletion rules. The Party Lead's feedback and returned proposals are also saved there. These checks do not grant new app access or permission to make changes.

You can request deletion of your chat history as described under Your rights. This chat history is separate from the skill-building conversations above: we don’t use it to improve skills or AI models, and it is never sent to PostHog or any other analytics provider.

When you upload a recording. If you describe a task by uploading a screen recording instead of typing (signed-in users only, where this option is offered), we extract the recording’s sound and send it to OpenAI to be turned into text, then give that text to the assistant as if you had typed it. The recording and its sound are deleted from our server when that request finishes, after the assistant has drafted your skill, whether or not it succeeds, and we don’t keep the transcript. Only one of our servers offers this, the one that runs the assistant for the web app at cedarandloam-playbook.fastmcp.app, and only while transcription is switched on there. On our other hosts the card may still appear, but the upload cannot go through and nothing reaches OpenAI.

When you save a secret. Some features need a credential that our server uses on your behalf: a bearer token for an MCP server of your own, or a key that a custom API step sends. Secrets you save with the playbook_secret_set tool, or on the web app’s Secrets page, are stored in our database, encrypted with a key that is kept outside the database. You can delete them yourself.

When you give a Player a sign-in for a site. We keep the email and password encrypted like any secret, and hand them to the Player’s own computer only for a quest that opens that site, where a sign-in step, not the AI, types them in. The browser stays signed in on that computer between quests. Each time a saved secret is used, by a sign-in or a skill’s step, we record its name, which Player or run used it and when, never the value, and keep that record for 400 days. When a Player works on more than one quest at the same time, each extra quest runs on a computer set up for that quest only. The saved sign-in is handed to that computer the same way, and the computer is deleted, with its browser and sign-in, when the quest ends, at the latest within 6 hours.

When you watch a Player's browser. While a live preview is visible, we read the current browser image from the computer running that quest and show it only to the Player's owner. The preview and expanded view show the page as it appears, including any information visible on it. Our server and the web app hold these images in memory, do not record them or send them to an AI model, and clear them when you leave the view or the quest stops. The Player's computer keeps only the latest frame while its browser is running. The separate sign-in step is not shown.

When you create a target. A target is a named set of connections to MCP servers. We store each connection’s details: tool name, server address, an auth_ref (a pointer to the credential, never the credential itself), an auth type, and any nickname or description you add. The credential it points to is held by Composio for app connections, or stored as an encrypted secret (see above) for servers of your own.

When you search. Search queries are used in memory to rank results and are not stored on our servers. Ranking comes from the run history described above, not from a stored history of your searches.

Usage analytics. If you accept the analytics banner in the web app, it sends PostHog the pages you view and when you leave them, a few clicks (the sign-in buttons, the skill tiles on the home page, sign-out, opening a Player’s result or one of its files), when a Player’s result first shows on your screen, and your progress through the first-run tour. A result is sent as an id, whether it was on your screen or you opened it or one of its files, and how long after it arrived, never its title, text or file names. When you are signed in, those events carry your user id and display name, never your email address. Accepting also turns on a support chat, run by PostHog, on every page except the home page. What you type there, including any name or email address you give, goes to PostHog. PostHog also receives your IP address with every request the web app makes to it, the way any service you connect to does. The web app asks PostHog’s code to leave your IP out of the event it sends, but what PostHog keeps of the request itself is governed by its own settings and terms, not by the web app.

Separately, our server sends PostHog a record of what you do through the service, whichever client you use: your searches, how you browse the catalog (the filters you use and how many skills come back), which catalog skills you open, which skills you run or contribute, when you save a skill, whether runs succeed and how long they take, and the session summaries described above. Opens carry the catalog skill’s name; runs and contributions carry the skill’s name, including the names you give your own skills. A skill’s name is sent as you wrote it, so a name that mentions a person or a client is sent too. These events identify you by a one-way hash of your user id instead of the id itself, and never carry your email address or the name on your account. They never carry the text of your skills, conversations or run results, and a search is recorded as a one-way hash and the length of what you typed, not the words.

Our server also sends PostHog a record each time an AI app lists its tools, calls one or reads a resource: the tool or resource name, how long it took, whether it failed and the kind of error, the names of the inputs it was given, and the app’s name, version and client identifier. These records carry a session id rather than your user id, and never the values of the inputs, the results or the text of an error.

In your browser. The web app keeps some things in your browser’s storage: your sign-in tokens and the profile WorkOS returns (including your name and email address), any API key, server address or n8n credentials you enter in Settings, your analytics choice, and drafts you have not saved to your account. They stay in your browser, except that the web app sends your sign-in token or API key with each request to our server, and your n8n address and key whenever it tests your n8n connection, lists your n8n workflows or imports one. Your optional leader appearance and display name are saved separately for each account in this browser. They are not synced to other devices or sent to our server.

We do not collect precise location, payment information or advertising identifiers. We also do not see your whole conversation with your AI client, only the tool calls it makes to Playbook and what it sends in them.

Who handles your data

These companies handle personal data for us (our subprocessors). For each one we list what it gets, why, and where it processes the data.

  • Fly.io: everything you send to mcp.playbookcatalog.com, its test copies and the web app’s AI assistant, and everything they send back; your Players’ own machines: the one each quest runs on, the one each chat keeps for its requests until you delete the chat, and a short-lived extra one for each quest that runs at the same time as another, deleted when that quest ends; if you let a Player browse, their browser and their sign-ins; and for a Player that runs code, their code workspace with a copy of your repository; and persistent conversation workspaces containing drafts, imported inputs and prior file versions. Hosts the service at its new address and its test copies, the web app’s AI assistant at both addresses, and your Players’ own machines. Where: United States (Chicago); where the Players’ own machines run is not yet confirmed.
  • FastMCP Cloud, run by Prefect: everything you send to cedarandloam-playbook.fastmcp.app and everything it sends back, except the web app’s AI assistant, which runs on Fly.io. Hosts the service at that address until the move is finished. Where: United States.
  • Cloudflare: requests to playbook-catalog.pages.dev and its test copies. Serves a copy of the web app. Where: worldwide network.
  • Supabase: everything we store, listed above. Database and file storage. Where: not yet confirmed.
  • WorkOS: sign-in details; team names, members and roles, and the email addresses of people you invite to a team. Identity provider; manages teams and sends team invitations. Where: United States.
  • Anthropic: what Claude steps work on, including content from your apps; AI assistant conversations, the files you attach to a message in a chat with a Player, and in the Party Lead the skill you have open and the runs you ask about; your website’s address when you ask for a draft of your business details; what you type or paste when you ask for a Player to be set up, and your answers to its questions, with your business details, the client’s profile, a small sample from the apps they will use, the names and descriptions of your skills and which of the apps Playbook works with you have connected; when a Player works a quest, their record, their skills’ recent runs and training results, their earlier notes, your team’s pages and business details, what they read from the apps in their field, the files in their stash they open, including files you attached in a chat, the figures of the reports they made that they read, and, when you let them browse, the pages their browser opens, and afterwards the counted facts about the quest for the Party Lead’s report; an opaque code for your organization with each request. Runs Claude steps and the AI assistant, drafts business details and Players, and runs Players’ quests. Where: United States, and other countries outside Europe.
  • Composio: your user id, app sign-ins and API keys; what each app action sends and gets back; your IP address when signed-in pages load app logos. Connects to and calls your apps. Where: not stated by Composio.
  • OpenAI: the sound from recordings you upload, where that option is offered; when a Player you set to think with ChatGPT goes on a quest, their record, their skills’ recent runs and training results, their earlier notes, your team’s pages and business details, what they read from the apps in their field, the files in their stash they open, including files you attached in a chat and images when the selected model supports image inspection, the figures of the reports they made that they read, and, when you let them browse, the pages their browser opens. Turns speech into text and runs the quests of Players set to ChatGPT. Where: not yet confirmed.
  • Stripe: your organization’s id and the email address you signed in with; your plan and seats; the card details you type into Stripe’s own pages, which never reach us. Takes payments for plans and credits. Where: not yet confirmed.
  • PostHog: in the browser, only after you accept the banner: web app analytics and support chat, plus your IP address with each request, which its code is asked to leave out of the event it sends. From our server, whatever you choose there: usage events with a hashed user id, and a record of each tool call with no user id, and with the names of the inputs it was given, but never their values, the results or the text of an error. Product analytics and support. Where: United States (Virginia).
  • GitHub: any skill you contribute, with your user id; your skills and any run output you commit, if you keep them in a GitHub repository of your own; screenshots your Player attaches to the issues they file, if you let them browse and give them a repository; the draft pull requests a Player that runs code opens in your repository after you approve their change; once a week, problems that came up in more than one Player quest, as issues in our own private repository: action names, problem codes, counts and the ids of a few of those quests. Pull requests to our catalog repository; storage you choose; tracking problems we need to fix. Where: United States and other countries, which can include one near you.
  • Slack: your Slack user id and the messages you send the Party Lead in Slack; the Party Lead’s and Players’ replies. Delivers the Party Lead in your Slack workspace. Where: not yet confirmed.
  • Microsoft (Teams): your Teams user id and the messages you send the Party Lead in Teams; the Party Lead’s and Players’ replies. Delivers the Party Lead in your Microsoft Teams organization. Where: not yet confirmed.
  • Google: your IP address and browser details when a page loads its icons from Google Fonts. Serves the web app’s icon font. Where: worldwide network.

We checked these in September 2026, against our own configuration and against what each company publishes. Fly.io runs our servers in Chicago and says it stores and processes data in the United States. PostHog is on its United States cloud, which runs in Virginia. Prefect says FastMCP Cloud’s main processing happens in the United States. WorkOS names the United States as the only country it stores data in. Anthropic says data goes to its servers in the United States or to other countries outside Europe. GitHub says it uses several locations, which can include one near you. Cloudflare and Google both run worldwide networks.

Four are still open. Our Supabase project’s region is a setting on our own account rather than something Supabase publishes, and we have not written it down here yet. Composio does not say anywhere we can find where it processes data, and we have not yet asked it. OpenAI’s terms name no country either. We have not yet checked where Stripe processes data, or what its terms say about transfers. We will correct this page as each one is settled, and we would rather say “not yet confirmed” than name a country we cannot point you to.

Services you choose yourself are not our subprocessors: the apps you connect through Composio, your own MCP servers, your n8n instance, and web addresses your skills call. They get what your skills send them, such as the messages they post or the workflows you push to n8n, and their own terms apply.

We do not sell or share personal information for cross-context behavioral advertising. CCPA “Do Not Sell or Share” is satisfied by this statement.

Cookies and consent

We use cookies only when you accept the analytics consent banner. PostHog then sets a cookie, plus local storage entries, so it can recognize your browser across visits and link events from before and after you sign in. The cookie lasts up to a year. If you decline the banner, the web app sets no PostHog cookies, sends no events from your browser and loads no PostHog code. If you accept and later withdraw, it stops sending events, erases the identifiers PostHog stored in your browser and hides the support chat; the PostHog code already loaded stays in the page until you reload it. The server usage events described above do not depend on this choice.

You can withdraw or change your consent at any time, with the same ease as giving it: use the link (here, or in the footer of the home page) to reopen the consent banner.

Lawful basis for processing (GDPR)

For visitors in the European Economic Area, the United Kingdom and Switzerland, we rely on these lawful bases under Article 6 of the GDPR:

  • Consent (Art. 6(1)(a)): for analytics cookies and the events the web app sends to PostHog from your browser, and for any use of your content beyond showing you your runs and fixing problems, such as improving skills or training AI models. You can withdraw consent at any time without affecting the lawfulness of processing carried out before the withdrawal.
  • Performance of a contract (Art. 6(1)(b)): for account creation, sign-in, saved skills, running your skills (including sending step content to Anthropic and app actions through Composio), the run history and run reports that let you see your own past runs, and the Party Lead history that lets the chat pick up where you left off.
  • Legitimate interests (Art. 6(1)(f)): for basic operational logs, security monitoring required to keep the service running, the run counts and outcomes we use to rank and improve skills, the chat text we keep to look into problems with the AI assistant, the session summaries we use to decide which skills to build, and the server usage events we send to PostHog.

International transfers

Most of the companies above process data in the United States. Cloudflare and Google serve from worldwide networks, and GitHub uses several locations. Services you choose yourself, such as your n8n instance or your own servers, run wherever you host them, which may be outside the US and is under your control, not ours.

Where personal data is transferred outside the European Economic Area, the United Kingdom or Switzerland, what protects it depends on the company, so we have stopped claiming one answer for all of them.

Supabase, WorkOS, Anthropic, Cloudflare and Prefect each write the European Commission’s Standard Contractual Clauses into the terms we are already on, with no separate signature needed, and each of those adds a UK version. Anthropic and Cloudflare add a Swiss version too. OpenAI’s terms put UK data under the same clauses and make its Irish company the contracting party for European data, which says who is responsible for that data rather than where it is kept. GitHub says it relies on those clauses and on the EU-US Data Privacy Framework.

Fly.io, Composio and PostHog are different. Each offers a data processing agreement that only takes effect once we sign or accept it, and we have not done that yet, so we do not claim the Standard Contractual Clauses cover them. Fly.io is separately certified under the EU-US Data Privacy Framework, which is a transfer basis in its own right. PostHog says it relies on the Standard Contractual Clauses for transfers into its United States environment, but that is its statement, not an agreement we hold. Composio’s agreement is accepted through its dashboard on its paid plans. We are working through all three and will update this page.

For Google, the only thing that leaves your browser is the request for the icon font, and Google’s own terms govern it.

If you would prefer a service variant that keeps your analytics data in the EU, email us. We are evaluating an EU PostHog instance and would like to know there is demand.

Data processing agreement

We do not yet offer a data processing agreement. If you are a business that needs one before using Playbook with personal data you are responsible for, email us first at hello@cedarandloam.com.

How long we keep it

  • Step content: 30 days. What your steps produced, what you or an approver typed during a run, error messages, the notes saved with a run, the records of Claude’s steps, and the error left by a schedule’s last failed run are deleted 30 days after the run finishes, the app data in a decision record 30 days after the decision, what a training run would have sent 30 days after it was recorded, and the details of a change a Player proposed 30 days after they proposed it. A paused run nobody resumes is deleted 30 days after it paused, unless it is still waiting for an email reply.
  • Run summaries: 400 days. The rest of each run report, including the values the skill ran with, is deleted 400 days after the run finishes.
  • Audit trail: 400 days. The tamper-evident record of what each step attempted, which holds fingerprints of the values a step ran with rather than the values, is deleted 400 days after the entry is recorded.
  • Party Lead and Player chat messages: 30 days. Your messages and replies are deleted 30 days after they were written. The short notes that summarize older messages in the original Party Lead chat and each Player conversation stay until that chat is cleared or deleted, the Player or account is deleted, or the person leaves the team.
  • Conversation working files: until erased. Drafts, imported inputs and prior versions survive idle, Stop, restart and archive. They have no automatic expiry and are included in erasure requests.
  • Chat titles and identities: while your account and membership exist. Conversation IDs, titles, Player links and timestamps remain until your account or team membership is deleted. Deleting a Player also deletes their conversation records.
  • Credit and usage records: 400 days. We delete each record of a call’s usage, and each grant of credits, 400 days after it is recorded. A hold on credits is deleted 30 days after its call ends.
  • Payment events: 30 days. We delete the record of each payment event Stripe sends us 30 days after it arrives.
  • Scheduled run lines: 90 days. We delete the line for each scheduled run 90 days after it ran, and clear its reason after 30 days.
  • Player notebooks: while the Player exists. We keep every version of a Player’s notebook for as long as the Player exists, and delete it 30 days after the Player is deleted. That includes the copy of what you told the Player.
  • Player levels: while the Player exists. The size picked for each job, the XP it earned and the per-call token counts behind it are kept while the Player exists (for the Party Lead, while your team membership exists) and deleted with it. A call’s token counts are cleared 400 days after the call, like its usage record; the call’s id and the job’s total stay.
  • Player stashes: until deleted. We keep a file until someone deletes it, and remove it within a day of that. We delete a Player’s stash 30 days after the Player is deleted, and a person’s own part of it 30 days after their access to the Player ends. A file they shared with everyone stays after that.
  • Your own files in Relics: until deleted. We keep a file you uploaded without a Player until you delete it, and remove it within a day of that. One uploaded in a team is deleted 30 days after you stop being a member of that team.
  • No automatic limit yet for the rest. Apart from short-lived sign-in codes, nothing else we store is deleted on a schedule. Run history (with its notes cleared after 30 days), decision records (with their app data cleared after 30 days), training-run records and your verdicts on them (with what they would have sent cleared after 30 days), your Players’ other versions of a skill and your decisions on them (with the details cleared after 30 days), your Players’ job records and your verdicts on them (with the job names and notes cleared after 30 days), your trials of a change to a Player (with the job, the instructions you tried and your note cleared after 30 days), the text of your conversations with the AI assistant and their session summaries, your saved skills, schedules, saved secrets, targets, business details, client profiles, your team’s pages and their versions, Players, app approvals, stored sign-in tokens, your Slack and Microsoft Teams connections, and your plan and billing settings are kept while your account is active, until you or we delete them.
  • What you can delete yourself: your saved skills, schedules, saved secrets, targets, client profiles, your team’s pages, Players and app approvals, your business details (by clearing them), your Party Lead history (by clearing it), and most paused runs (by abandoning them), with Playbook’s tools or in the web app.
  • On request: we delete the records we hold about you, including run history, run reports and saved conversations, within 30 days of an erasure request or account deletion, unless we are required to keep them to comply with a legal obligation or resolve a dispute.
  • Backups: purged within 90 days of the live delete.
  • Analytics: events sent to PostHog follow the retention set in our PostHog project (currently the platform default; see PostHog’s documentation for the current value).
  • Catalog content (public skills): kept indefinitely as part of the public repository.

Your rights

Regardless of where you live, you have the right to:

  • Access: request a copy of your data
  • Rectification: fix inaccurate data
  • Erasure: delete your data (the “right to be forgotten”)
  • Restriction: pause processing
  • Portability: get your data in a machine-readable format
  • Objection: object to processing, including processing based on legitimate interests
  • Withdrawal of consent: withdraw consent at any time where processing relies on it
  • No automated decision with legal effect: we don’t make decisions based solely on automated processing that produce legal or similarly significant effects about you

If you are in California, you also have the right to non-discrimination for exercising these rights (Cal. Civ. Code §1798.125). Today a Sec-GPC: 1 (Global Privacy Control) signal suppresses affiliate tagging on our /signup/<service> redirect links and stops us keeping AI assistant conversations; we do not use it as a broader processing opt-out because we don’t sell or share personal information in the first place.

If you are in the EEA, the UK or Switzerland and believe our handling of your personal data breaks the GDPR, the UK GDPR or your local data protection law, you can lodge a complaint with your national supervisory authority (for example the UK Information Commissioner’s Office, or any authority listed by the European Data Protection Board). We would welcome the chance to address your concern directly first.

Children

Playbook is for businesses and is not directed at children under 16.

How to reach us

Email hello@cedarandloam.com. We will respond as soon as we can, and within one month, which is the GDPR deadline.

Changes to this statement

Material changes to what we do with data will be announced in-app or via email before they take effect. The effective date at the top of this statement is bumped when the substance changes.

This website does not use optional analytics cookies.

Privacy