Detailed content
🍕 The pizza: rules & hooks weigh more
The Consulting OS distribution is reasonably balanced, with context leading (client information is scattered and needs to be consolidated). The striking difference: rules & hooks matter more than usual. In consulting, what comes out of your OS goes to a paying client — so the guardrails (brand voice, what’s sealed, per-client format) carry more weight.
How to read: the slice of Rules & Hooks is highlighted (glow) because it grows here. Compare with the Content OS, where it came last: the domain changes the shape of the pie.
💡 Why rules matter
Each deliverable carries your reputation and the relationship with a specific client. Client A’s report can’t have Client C’s tone; what was marked as sealed can never leak. Soft rules can’t handle that — which is why the layer grows.
Why learn
Because it teaches you to read the shape of the pizza by domain. When you see that consulting requires strong fences, you can set the right priorities: a brilliant agent is no help if it sends Client A a report in Client B’s format. The distribution is your priority map.
Key concepts
🗄️ Context: 1 folder per client
Your client information lives scattered all over the place. The first move is to consolidate it and make sense of it—the equivalent, in folders, of putting together cabinets and shelves. Each client becomes a folder; in the CLAUDE.md you leave the reference: "when I mention this client, I mean this folder." The OS knows exactly where to look.
🌱 New here?
The folder raw/ stores the raw material (meeting transcripts, emails); the synthesized/ stores the distilled material (the summary the OS actually reads). The CLAUDE.md is the soul file, read first—it’s where you create the aliases: "Client A = clients/client-a/."
How to read: the structure is the “cabinet.” Each client gets their own drawer (with raw and distilled material), playbooks are within reach, and the wiki stores what applies to everyone. The agents (in cyan) read this structure.
Why learn
Because without an organized cabinet, everything else falls apart. If the OS doesn’t know which folder belongs to which client, it mixes contexts—and mixing clients in consulting is a serious failure. The client folder plus the reference in CLAUDE.md give the OS a reliable memory for each account.
Key concepts
📚 Client playbooks + global wiki
On top of the folders come the playbooks: how you run the consulting practice overall and how you run it for each specific client. These playbooks add up to a global playbook, a wiki that triages every meeting for every client. Every company has patterns; the wiki is where you capture them to enrich the next meeting and its preparation.
How a playbook comes to life
Raw meetings
O raw/ for each client accumulates transcripts and notes—the raw material for every account.
Triage & distillation
The wiki cross-references meetings with all clients and isolates patterns—what repeats becomes a nugget.
Living playbook
Client-specific + global (the wiki), ready to enrich prep for the next meeting.
🔎 Two levels of playbook
- By client — the specific way of serving Client A: what they value, the pace, the quirks.
- Global (wiki) — the patterns that apply to everyone: “businesses like these tend to object to X,” your meeting prep method.
- The bridge — the wiki triages all clients’ meetings and finds patterns that enrich each account.
✓ Playbooks that pay off
- ✓Client-specific + one global version that distills patterns.
- ✓Powered by triage of real meetings.
- ✓Improves prep for the next meeting for each account.
✗ Dead wiki
- ✗A giant doc nobody updates.
- ✗Same generic playbook for every client.
- ✗Never distill meetings into patterns.
Why learn
Because it’s what turns experience into an asset. Without playbooks, every meeting starts from scratch and the knowledge lives only in your head. With the client-specific + global wiki pair, the OS remembers how you serve each account and spots patterns across them—you get better with every client.
Key concepts
🛡️ Adversarial Review Gate in the Customer’s Voice
The signature piece of the Consulting OS: before a deliverable reaches the client, it goes through a adversarial reviewer who takes on that customer's voice. It's an agent you name after the account's primary contact, prioritized by all the summarized meetings — it knows the recurring objections, what the person values, and their tone. When the stack calls for it, it’s worth having several adversarial reviewers, not just one.
🌱 New here?
One review gate (review gate) is a required checkpoint that something passes through before it goes out. Adversarial means the reviewer plays devil’s advocate: their job is to find the problem, not to praise. Primacy = preloaded with the context. SOW (statement of work) is the document that sets the scope agreed upon with the client.
🎯 Copy-run objective
Run a reviewer who thinks like the customer about a deliverable, grounded in the actual meeting summary, and come away with their objections plus a verdict of “would send” or “would send back.”
Aja como <Nome do contato principal>, principal contato da conta <Cliente>. Você é o revisor adversarial deste entregável — não eu. Antes de responder, leia o contexto desta conta: - clientes/<cliente>/synthesized/resumo-reunioes.md (o destilado das reuniões: objeções recorrentes, o que ele valoriza, o tom dele) - clientes/<cliente>/playbook.md (como tratamos esta conta especificamente) Entregável em revisão: <cole aqui a proposta / o relatório / o e-mail> Revise NA VOZ do <Nome do contato>, sem suavizar: 1. Liste as 3 objeções que ELE levantaria primeiro, na ordem em que doem. 2. Aponte 1 ponto onde prometemos além do escopo (SOW) ou do que foi acordado. 3. Diga onde o tom soa genérico / "de agência" e não fala com ELE. 4. Termine com um veredito: "enviaria" ou "devolveria" + a correção nº 1. Cite trechos do resumo de reuniões para sustentar cada objeção. Se faltar base no synthesized/, escreva "sem lastro" em vez de inventar.
The parts in <...> you replace it with your data. Promote it to agents/review-gate.md and trigger it before every client delivery.
✅ How to verify
- ✓The answer comes in the 1st-person client (not “it would think that…”).
- ✓Cites real meetings from synthesized/ — concrete objections, not generic ones.
- ✓Delivers an actionable verdict: "send it back/return it" + the #1 correction.
- ✓Grounding test: delete the meeting summaries and run it again — it answers "no supporting evidence," proving it doesn't guess.
Why learn
Because it catches the mistake before the client does. A reviewer primed with the person’s voice anticipates the objection you would only hear in the meeting—when it would already be too late. This is the adversarial review gate in action: the deliverable only goes out after surviving the toughest critic, the simulated client themselves.
Key concepts
👔 Agent: portfolio lead
The second agent is the portfolio lead: a customer relationship manager (CRM) by client. Each one is fully primed and has injected into its context, every meeting you’ve ever had with that account. When you ask "where did we leave off with Client A?", that client's portfolio lead responds with the complete relationship history.
🌱 New here?
One CRM (customer relationship management) is the system that stores the history of your relationship with a client. Here, the "CRM" isn’t an external app: it’s an agent primed with that client’s meetings—the account’s living memory, inside your OS.
One CRM agent per client, with all meetings injected. It remembers the status, next steps, and history.
Its counterpart: while the portfolio lead remembers, the review gate critiques in the customer’s voice before sending.
💡 Two agents, opposing roles
O portfolio lead is on your side (remembers everything, prepares the meeting). The review gate plays devil's advocate (attacks the deliverable in the customer's voice). Both read the same synthesized/ — the same memory, used in two ways.
Why learn
Because consulting is about relationships, and relationships depend on memory. A portfolio lead for each client means you never walk into a meeting “cold”: the agent has already reminded you of the agreement, open items, and sensitivities for that account. It scales your service without losing the personal touch.
Key concepts
🧰 Account skills & tools
The Consulting OS skills are the tasks you repeat most for each account: pre-call prep (prepare the meeting), proposal/SOW e AI audit. Important detail: never a “generic audit skill”—every audit is nuanced to the client's goal. The tools connect to the real world: QuickBooks and ledgers, Stripe links inside proposals (instead of PandaDoc) and a calendar buffer check (Calendly/iCal).
🌱 New here?
SOW (statement of work) sets the scope of the work. Ledger is the transaction ledger. Stripe generates payment links; PandaDoc is an alternative for documents that you can skip here. Buffer in the schedule is the breathing room between meetings—the tool checks for availability before scheduling.
The account’s skills—repeatable, never generic
skills/ ├── pre-call-prep # junta histórico + pendências da conta ├── proposta-sow # gera proposta com link Stripe embutido └── auditoria # SEMPRE nuançada ao objetivo do cliente
✓ Intentional
- ✓Always anchor the audit to the account’s goal.
- ✓Stripe directly in the proposal — fewer tools, less maintenance.
- ✓Check your buffer before scheduling a meeting.
✗ Generic
- ✗An “audit” skill that works for anyone.
- ✗Stacking 5 tools that become dead weight.
- ✗Proposal without a clear payment path.
Why learn
Because it’s where the course’s "never be generic" becomes concrete. The same word—audit—is worth its weight in gold when anchored to the client’s goal and worthless as a template. And being intentional about tools (Stripe, yes; PandaDoc, no) keeps every integration from becoming maintenance debt.
Key concepts
🚧 Rules & What Is Sealed
We’re back to the layer that carries the most weight here. The Consulting OS rules cover the brand voice, the things to avoid and the report format — which may differ between Client A and Client C. And there's the identity: who you serve, what is sealed (confidential, never leaks) and its values. In consulting, leaking information between clients is the mistake that ends contracts.
✓ Consulting guardrails
- ✓Consistent brand voice in every deliverable.
- ✓Client-specific report format (A ≠ C).
- ✓One client’s sealed information never appears for another.
✗ Breach of trust
- ✗Client A data leaking into Client B’s doc.
- ✗Same generic format for different accounts.
- ✗Inconsistent tone that doesn't sound like you.
⚠️ The mistake to avoid
Treating confidentiality between clients as a "soft rule." Cross-referencing sensitive data between accounts must be a deterministic hook: a reflex that prevents Client A’s sealed material from entering any artifact for another client. Deterministic where it matters — and in consulting, a leak hurts forever.
Why learn
Because it’s what protects your business. The OS’s intelligence is worthless if it cross-pollinates client data or speaks in the wrong voice. Locking down the rules—voice, format by client, sealed as a hook—is what lets you scale customer service without risking the reputation your consulting business depends on.
Key concepts
✅ Module summary
Next module:
5.6 — Freedom OS & production standards 🗽