What Is an AI Playbook? The Difference Between Context You Retype and Context That's Already There

#ai #productivity #beginners #agents

A playbook is what a prompt becomes when you stop storing it in your head. It lives in a workspace, carries your context, your process, and your standards, and agents read it automatically when they enter — nothing pasted, nothing re-explained.

I used to have a very good prompt. Twelve hundred words, carefully tuned. My company name, my products, my customer segments, my communication style, the things I care about and the things I don't. I could drop it into any AI session and get usable output in seconds.

I also retyped it — or pasted it from a note that was never quite right for today's task — every single session.

The prompt was good. The location was wrong.

What a Prompt Is (and What It Can't Do)

A prompt lives wherever you stored it. Usually that means a note in your project management tool, a sticky in a doc, or the back of your memory. You paste it in when you remember, adapt it for the task at hand, and when the session ends, it's gone. The next session starts clean.

This is not a model problem. The AI isn't forgetting because the underlying model is limited. The context was never stored anywhere the agent could reach it. So every conversation begins from zero, and you provide the starting point again.

The instructions don't change when context moves to a workspace. What changes is that the agent can reach them on its own, without you pasting anything into the chat.

What a Playbook Is

A playbook is a file that lives in a Connect workspace and that agents read automatically when they enter. It's not a prompt you paste in at the start of a chat, and it's not a document someone opens and reads. It's the brief that exists independently of any session — there when you open one, there when a scheduled task runs at 3 AM, there when a colleague opens their own session tomorrow.

What goes in a playbook varies by workspace, but the structure usually covers four things: purpose (what this workspace is for and who uses it), context (what the agent should know before doing anything), process (how work gets done here), and standards (voice, format, escalation rules, what not to do). The format is markdown. The requirement is that it's specific enough to be useful without you present.

The difference from a prompt is location and durability. A prompt exists in a session. A playbook exists in the workspace and survives every session that comes and goes.

Where This Matters in Practice

Every Cowork session I open, I specify which workspace I'm entering. The agent reads the files — including the playbook — before I type a word. I don't paste anything. I don't re-explain the business, the standards, or the process. That context is already there.

Before Connect, my workflow looked different. Relevant notes lived in a project management tool. When I needed AI help with anything, I manually copied the relevant rows, customer details, or project context out of that tool and pasted them into a new chat session. The agent worked from whatever I'd pasted. If I forgot to include a detail, the output showed it. If I closed the session, I started from zero next time.

The AI didn't get smarter. The context moved somewhere the agent could find it.

This is how it works in my setup, using Cowork as my interface for Connect. Connect is also accessible via API and web UI — if you've built your own agent tooling or you're accessing Connect programmatically, the mechanism is the same. The agent reads the workspace on entry. The source of truth is the workspace, not the chat history.

The Difference That Took Me Longest to See

A prompt is written for a task. A playbook is written for a workspace.

The difference shows up most in how you maintain context over time. A prompt is optimized for the thing you're doing right now. A playbook covers what's true about this space, this workflow, these standards — regardless of what the specific task turns out to be. You write it once, update it when something changes, and every agent that enters the workspace uses the current version.

The compound effect comes from updates. When I changed how I handle customer escalations, I updated one file in one workspace. Every subsequent task in that workspace — whether I ran it or a scheduled task did — used the new approach. With a prompt, the same change requires me to remember to update my notes, find them, paste the updated version next time.

I forgot a lot.

What a Playbook Doesn't Replace

A playbook is not a substitute for task-specific instructions. It covers what's always true; you still tell the agent what's specific to right now. The playbook tells it about your business, your voice, your process. Your message in the session tells it what to do today.

The way I think about it: a playbook is onboarding. You don't re-onboard a colleague every morning. You did that once, and now they know the context. You give them today's task. A playbook does the same thing for agents — the brief already happened, before the session started.

If you're running workflows in Waxell Connect and haven't written a playbook for your primary workspaces yet, that's the first thing worth doing. The rest of what Connect can do builds from having that context layer in place. You can get access at waxell.ai/get-access.

FAQ

What is an AI playbook?

An AI playbook is a persistent, agent-readable file stored in a workspace that gives agents the context they need before a session begins. It typically covers the purpose of the workspace, relevant background information, process steps, and standards the agent should follow. Unlike a prompt, which is written into a chat session and disappears when the session ends, a playbook stays in the workspace and is read automatically each time an agent enters.

What's the difference between a prompt and a playbook?

A prompt is written into a chat session and exists only for the duration of that session. A playbook is a file that lives in a workspace permanently and is read by agents when they enter — with or without you typing anything. The practical result: a prompt requires you to provide context every session; a playbook means the context is already there.

What should I put in an AI playbook?

Start with four things: what this workspace is for, what the agent needs to know before doing anything (business context, product details, relevant constraints), how work gets done here (process steps, tools, escalation rules), and what the standards are (voice, format, what to avoid). Markdown works fine. Specificity matters more than length — a 400-word playbook that's precise will produce better output than a 1,500-word one that hedges. Update it whenever something changes, since every future task in the workspace will use whatever version exists at the time.

Do I have to paste a playbook into every chat session?

No. That's the point. If your context is stored as a file in a Connect workspace, agents read it on entry without any action from you. The old workflow — copy context from notes, paste into new session — is what the workspace-playbook pattern replaces. The playbook is there whether you're actively in the session or a scheduled task is running overnight.

How is a playbook different from a system prompt?

A system prompt is set at the model or API level and applies to a specific session configuration. A playbook is a file in a workspace that's read as context when an agent enters it. In practice: a system prompt is usually configured once by whoever set up the tool; a playbook is owned and edited by whoever owns the workspace, can be updated mid-use, and applies to any agent that enters — regardless of how the underlying model or session is configured. The playbook is also visible and editable by anyone with workspace access, which makes it easier to maintain and update.

Can different workspaces have different playbooks?

Yes, and this is one of the reasons the pattern holds up at scale. Each workspace has its own playbook, its own context, its own standards. A customer-facing workspace has a different playbook than an internal ops workspace. A blog production workspace has different standards than a bug triage workspace. The agent entering each one reads what's relevant to that specific space. Nothing bleeds across unless you explicitly reference it.