tropo

How Playbooks Work

A playbook captures a process so anyone — a person or an agent — can run it the same way every time: its intent, its hard rules, the steps, what "done" means, and how you prove it.

A playbook is a process with teeth. Not a vague checklist — a governed file that declares what a job is for, the constraints it must respect, the steps to run it, the outcomes that count as done, and how to verify it was done right. Because the process is written down as structure, the same playbook an expert wrote can be run by a teammate, by an agent, or by you — and it runs the same way each time. Capture the method once; run it anywhere, forever.

Why playbooks

Expertise usually lives in someone's head, and it doesn't scale — every run depends on the person remembering. A playbook moves the method out of the head and into a file:

  • The expert writes it once. Intent, rules, definition of done — captured as structure, not folklore.
  • Anyone (or any agent) runs it. The same file drives a person or an AI, on any model, at any time.
  • Every run is checkable. A playbook declares its own verification, so "did we follow the process?" has a real answer, not a vibe.

A playbook separates what you know from who's doing the work. Your method becomes a thing the whole crew can run — repeatable, portable, and verifiable.

What a playbook declares — five required sections

Every playbook is a governed file (playbook.capsule, e7b3c509) with a five-section floor. Once you can read one, you can read all of them:

  • Intent — the goal and why. The North Star when a judgment call comes up.
  • Rules — hard constraints, phrased as MUST / MUST NOT. Testable: an observer can check whether each was followed.
  • Steps (or Groups) — the executable content: a linear sequence, or a DAG of groups for multi-owner, long-running work.
  • Outcomes — the end states that count as done, each marked [REQUIRED] or [OPTIONAL].
  • Verification — how you prove it ran correctly — not "was the output perfect" but "did it stay in the rules and produce the outcomes."

Two more sections are common but optional: Suggestions (soft guidance) and Resources (the templates and references a run needs). And like every governed entry, a playbook has a lifecycle: draft → active → superseded → archived.

STRUCTURE · A PROCESS WITH TEETH send-the-save-the-date.playbook.md ## Intentthe goal + why ## RulesMUST / MUST NOT — testable ## Stepsthe executable content (or ## Groups) ## Outcomes[REQUIRED] end states ## Verificationproof it ran correctly LIFECYCLE draft active superseded archived + optional: ## Suggestions ## Resources governed by playbook.capsule (e7b3c509) · 21 validation checks · subtypes: pipeline · concierge-paths · test-harness

Diagram 1 — five required sections, one lifecycle. Intent and Rules frame the work; Steps (or Groups, for multi-owner runs) are the executable core; Outcomes and Verification define and prove "done." Suggestions and Resources are optional.

How a playbook runs

Running a playbook isn't reading a doc top-to-bottom — it's a governed execution. When an agent (or a person) invokes one, the run opens a run folder: a place that records what happened — a thread.md log, milestones as each group completes, and verification receipts proving the outcomes were met. The same playbook drives a human or an agent; the trail it leaves is the same either way.

And the rules don't float free — they cascade. A playbook's rules sit underneath the Operating Principles, the studio's agreement, any director policy, the agent's own charter, and any parent playbook. A playbook can add constraints; it can never remove the ones above it. That's how a process stays inside the lines no matter who runs it.

MECHANISM · EVERY RUN LEAVES A TRAIL the playbook status: active invoked by a person OR agent the run folder thread.md — the running log milestones — one per group completed verification receipts — proof of outcomes RULES CASCADE — a playbook can add constraints, never remove the ones above Operating Principles + studio agreement → director policy → agent charter → parent playbook → this playbook most general at the top; most specific at the bottom; no layer loosens the layer above it.

Diagram 2 — a run is governed, not just read. Invoking a playbook opens a run folder that records the log, the milestones, and the verification receipts — the same trail whether a person or an agent ran it. Rules cascade from the Operating Principles down; a playbook tightens, never loosens.

One process, end to end

Say you want to send the Customer Summit save-the-date, reliably, every quarter. You capture it as a playbook:

## Intent
Send the save-the-date to our top 50 accounts, on brand, with no duplicates.

## Rules
- MUST send only to accounts tagged `tier-1`.
- MUST NOT send before the date and venue are confirmed.

## Steps
1. Pull the tier-1 account list.
2. Draft from the approved template.
3. Get sign-off.
4. Send, and log each recipient.

## Outcomes
- [REQUIRED] All tier-1 accounts received exactly one save-the-date.

## Verification
- Method: peer-review of the send log against the tier-1 list.

The first time, your strategist agent runs it and you watch. Next quarter, you hand it to a different agent — or run it yourself — and it goes the same way, because the intent, the rules, and the definition of done are all written into the file. The expertise didn't leave with anyone.

Playbooks compose — and Tropo runs on them

Playbooks call playbooks. A long process declares Groups — a DAG where each group has an owner and can fan out to sub-playbooks — so a big orchestration is just smaller playbooks composed. And this isn't a side feature: it's how the system runs itself. Every Tropo agent boots by executing one — the Agent Activation playbook (99341618), the most-run playbook in the whole studio. The concierge that onboards a newcomer runs playbooks too (start-a-project, create-an-agent). The method is the product, and the method is playbooks.

COMPOSITION · PLAYBOOKS CALL PLAYBOOKS orchestrator ## Groups (a DAG) sub-playbookgroup A · owner ada sub-playbookgroup B · runs in parallel sub-playbookgroup C · depends on A fan out Every Tropo agent boots by running one: the Agent Activation playbook (99341618) — the most-run playbook in the studio.

Diagram 3 — playbooks call playbooks. A long process is a DAG of groups, each fanning out to a sub-playbook; an orchestration is just smaller playbooks composed. Booting an agent is itself a playbook run — the method is the product.

How playbooks compose with the other five primitives

  • Vault — a playbook is a governed Vault entry; running it writes more entries (the run folder, the receipts).
  • Capsules — playbook.capsule (e7b3c509) is the contract every playbook obeys.
  • Agents — an agent runs playbooks to do multi-step work; booting an agent is running the Agent Activation playbook.
  • Channels — a long run coordinates owners across groups by posting to the shared event log.
  • Tropo Work — a pipeline is a playbook subtype; it drives a project's work from request to ship.

Where to go next

  • The Vault — where playbooks and their run records live.
  • Capsules — including playbook.capsule, the contract.
  • Agents — who run playbooks (and boot by running one).
  • Channels — how a multi-owner run coordinates.
  • Tropo Work — pipelines, the playbook subtype that drives projects.

And the playbooks that shipped with your studio are the best reference: open any file under .tropo/playbooks/ to see the five sections in practice.

How Playbooks Work · Build with Tropo · Playbooks. Capture the method once; run it anywhere, forever. The method is the product.

Getting Started with Tropo

  1. 1Vaultyour files + governance, in one place
  2. 2Agentsyour crew; named, scoped, persistent across sessions
  3. 3Capsulesthe rules; what each kind of thing in your Studio is
  4. 4Playbooksa repeatable process, with its checks built in, that any agent can run
  5. 5Channelshow agents coordinate without you routing every message
  6. 6Worktasks, projects, and boards that live in the same files as the work itself