In Chapter 10, I mentioned that I run my entire consulting practice through an interconnected system of AI assistants. Not one chatbot doing everything badly, but a network of specialised documents and prompts that talk to each other – an “operating system” for the business.
This is that system. I call it SparkOS.
What follows is the full architecture: the seven components, how they connect, what to put in each one, and the mistakes I made building it so you don’t have to. I’ve also included starter templates you can fill in for your own practice.
A quick note on what this guide is and isn’t. I’m sharing the structure and the thinking behind each component. What I’m not sharing is the specific content of my own documents – the exact prompts, the pricing logic, the scripts. That’s the IP I’ve built over hundreds of hours of client work, and it’s what makes my system mine. Your job is to build yours.
Why Interconnected Beats Standalone
Most consultants who use AI have a collection of one-off prompts. A prompt for writing proposals. Another for client emails. Maybe one for social media posts.
The problem is that none of these prompts know anything about the others. Your proposal prompt doesn’t know your pricing philosophy. Your email prompt doesn’t know where the client is in your sales process. Your content prompt doesn’t know what you actually sell.
So you end up re-explaining your business to the AI every single time. You paste in context. You correct it when it gets your positioning wrong. You waste twenty minutes getting it to sound like you instead of a LinkedIn carousel.
SparkOS solves this by giving AI a persistent, structured understanding of your entire practice. Each document covers one domain of your business, and the system instructions tell the AI how to use them together.
The difference is night and day. When my AI knows my positioning, my client archetypes, my pricing principles, and my sales process, it doesn’t just respond faster – it responds correctly. It catches things I’d miss. It holds me to my own standards. It becomes what I call a “brain outside your brain.”
The Seven Components
Here’s the full architecture. Each component is a document (I use Claude Projects, but you could adapt this to Custom GPTs or any system that supports project-level context).
1. The Kernel (D00)
This is the strategic control panel. Everything else flows from it.
Your Kernel contains your positioning statement, your mission, your client archetypes (who you serve and who you don’t), your service boundaries, and your governing principles. Think of it as the constitution of your practice – the document that settles arguments when two other documents disagree.
What to include:
- Your one-liner (what you do, for whom, in 30 seconds)
- Your positioning boundaries (what’s in scope, what you refer out)
- Your client archetypes (2-3 ideal client profiles with their core problems)
- Your governing principles (the rules you don’t break)
- A reference table pointing to every other document in the system
Why it matters: Without the Kernel, your AI has no centre of gravity. It’ll drift toward generic advice because it doesn’t know what makes your practice yours. The Kernel is the anchor.
2. The Sales Offerings Document (D01)
This defines everything you sell, what it costs, and who it’s for.
Your offerings document maps each product or service to the client archetype it serves, the problem it solves, the entry point, and the pricing logic. It also captures your pricing principles – the rules that govern how you quote.
What to include:
- Every service you offer, with a clear description
- Which archetype each service is designed for
- Entry-level pricing and pricing principles (not necessarily exact figures – the principles matter more)
- Your engagement model (how clients move from first contact to paid work)
- What you explicitly don’t do
Why it matters: When you ask your AI to help draft a proposal, it needs to know what you actually sell and how you price it. Without this document, you’ll get generic proposal language instead of language that matches your specific offerings.
3. The Customer Journey Document (D02)
This is your sales playbook. It contains the scripts, emails, and questions for every stage of the client relationship.
From first contact through to project completion and ongoing work, this document maps what you say, when you say it, and why. It includes your discovery questions, your follow-up email templates, and – critically – your disengagement scripts for when a prospect isn’t the right fit.
What to include:
- Your sales stages (however you define them)
- Scripts or talking points for each stage
- Email templates for common scenarios (follow-ups, proposals, thank-yous, disengagements)
- Your discovery questions (what you ask prospects to understand their situation)
- Any conversion pathways (how someone goes from, say, a workshop attendee to a consulting client)
Why it matters: Consistency. Your AI can draft follow-up emails that sound like you and match where the client actually is in your process. It can suggest the right questions to ask at the right time. And it holds you accountable to your own sales discipline.
4. The Diagnostic SOP (D03)
This is your internal standard operating procedure for running the diagnostic phase of your engagements.
Every good consulting engagement starts with a diagnosis. This document tells you (and your AI) exactly how to run that diagnostic session: what to prepare, what questions to ask, how to structure the time, and what to capture.
What to include:
- Pre-session preparation checklist
- The session structure (time blocks, topics, transitions)
- Your diagnostic questions (the ones that reliably uncover the real problem)
- Note-taking framework (what you need to capture for the deliverable)
- Post-session reflection questions (what I call the “Hot Wash” – three mandatory questions after every client session that keep the system alive)
Why it matters: This is what turns your diagnostic from an improvised conversation into a repeatable, high-value process. Your AI can help you prepare for sessions, remind you of your own framework, and draft deliverables from your notes.
5. The Deliverable Templates (D04)
These are the templates for whatever you hand to the client after the diagnostic phase.
In my case, this is a structured report with scored priorities and a clear recommendation for next steps. Yours might be different – a roadmap, a strategy document, a set of wireframes. The point is that it’s templated, so your AI can help you produce it consistently.
What to include:
- The structure of your deliverable (sections, headings, what goes where)
- Any scoring or prioritisation frameworks you use
- Example language for recommendations
- Formatting standards
Why it matters: This is where the time savings really compound. When your AI knows the template, it can draft 60-80% of the deliverable from your session notes. You review, refine, and add the judgment calls. The mechanical work is handled.
6. The Labs Playbook (D05)
This is your R&D engine – the system for turning consulting insights into reusable intellectual property.
Every consultant has what I call the “Doer’s Dilemma”: you’re so busy doing client work that you never build the assets (tools, frameworks, content, products) that would make the practice more valuable long-term. The Labs Playbook is the structural solution.
What to include:
- Your R&D idea capture process (where ideas go when they come up)
- The rules for what gets built (reusable assets, not one-off solutions)
- Your build rhythm (when you do R&D work)
- How R&D outputs feed back into marketing and new products
- The boundary between R&D and sales (critical – you don’t build free proofs-of-concept for prospects)
Why it matters: Without this document, your “tinkering time” stays informal and unfocused. With it, your AI can help you track ideas, prioritise builds, and connect your R&D to your commercial strategy. The Labs Playbook is what turns a consulting practice into an IP business.
7. The System Instructions
This is the glue. The system instructions tell your AI how to use all six documents together.
In Claude Projects, these go in the project instructions. In a Custom GPT, this is the system prompt. The system instructions define the AI’s role, its personality, its rules of engagement, and – most importantly – which document to reference for which type of question.
What to include:
- The AI’s role and voice (match it to your own communication style)
- A routing table: “When I ask about X, reference document Y”
- Rules of engagement (what the AI should and shouldn’t do)
- Any personas or modes (e.g., I have a “Council of Strategic Advisors” mode for strategic decisions)
- Conflict resolution rules (which document wins when two disagree)
Why it matters: This is what makes the system a system rather than a folder of documents. Without clear instructions, the AI will use the documents inconsistently or not at all. With them, it becomes a genuine operating partner.
How the Components Connect
The power of SparkOS isn’t in any single document. It’s in the connections between them.
Here’s how it works in practice. A prospect books a call with me. My AI references the Kernel (D00) to understand my positioning, the Sales Offerings document (D01) to know what I might recommend, and the Customer Journey document (D02) for the right questions and follow-up sequence. After the call, the Diagnostic SOP (D03) guides the session structure, and the Deliverable Template (D04) helps me produce the client’s report. If the engagement sparks an idea for a reusable tool, it goes into the Labs Playbook (D05).
Every document feeds the others. The Kernel sets the principles. The Sales Bible applies them commercially. The Customer Journey operationalises them in conversations. The SOP and Templates deliver on them. And the Labs Playbook evolves them.
That’s the loop. And it means the system gets smarter and more aligned over time, because every update to one document ripples through the others.
Implementation Guide
Setting This Up in Claude Projects (Recommended)
- Create a new Claude Project.
- Write your system instructions first. Start with the AI’s role and the routing table.
- Create each of the six documents as project knowledge files. Start with the Kernel – everything else depends on it.
- Test by asking questions that require cross-document reasoning. Ask it to draft a proposal (needs D00, D01, D02). Ask it to prepare for a diagnostic session (needs D00, D03, D04). If the answers feel disconnected, your system instructions probably need clearer routing.
- Iterate. Your first version will be rough. That’s expected. The system improves every time you use it and notice where it falls short.
Adapting for Custom GPTs
The same architecture works in OpenAI’s Custom GPTs, with a few differences. Your system instructions go in the “Instructions” field. Your documents upload as knowledge files. The main limitation is that Custom GPTs have a smaller context window, so you may need to be more concise in your documents or split across multiple GPTs.
Adapting for Other Platforms
Any AI platform that supports persistent context (project files, knowledge bases, system prompts) can run some version of this. The architecture is platform-agnostic. What matters is: (a) the AI can access all documents simultaneously, and (b) you have system-level instructions that tell it how to use them.
Common Mistakes (and What I’d Do Differently)
Starting with prompts instead of positioning. I see consultants jump straight to “write me a prompt for proposals” without ever defining their positioning, archetypes, or pricing principles. The prompt is the last thing you write, not the first. Start with the Kernel.
Making it too long. Your first instinct will be to write 10,000 words per document. Resist. The AI needs clear, structured information, not essays. My Kernel is about two pages. Concise beats comprehensive.
Treating it as static. SparkOS only works if you keep it alive. After every client session, I run a quick reflection (the “Hot Wash”) and update the relevant documents. If your system doesn’t evolve, it goes stale within weeks.
No conflict resolution rules. When your pricing document says one thing and your customer journey document implies another, which wins? If you haven’t defined this, the AI will guess. And it’ll guess wrong. Set explicit hierarchy rules.
Building six documents at once. Start with the Kernel and one other document (I’d suggest the Sales Offerings document). Get those working. Then add the next one. Trying to build the whole system in a weekend will produce six mediocre documents instead of two good ones.
Forgetting the human in the loop. SparkOS is a “brain outside your brain,” not a replacement for your brain. It drafts. It reminds. It connects dots. But the judgment calls – what to charge, whether to take the client, when to walk away – those are always yours. The system supports your thinking. It doesn’t replace it.
Starter Templates
Below are skeleton templates for each component. These contain the section headings and guiding questions – you fill in the answers for your own practice.
I’ve kept these deliberately minimal. A template that’s too detailed will push you toward my answers instead of yours. The structure is what matters. The content has to come from your own experience, positioning, and client work.
Template 1: The Kernel
# [Your Practice Name] Kernel ## What We Do (30-Second Version) [Write your one-liner here. Who do you help? What do you help them do? What's the outcome?] ## Who We Serve [Define 2-3 client archetypes. For each: who are they, what's their core problem, what's the entry point into working with you?] | Archetype | Profile | Core Problem | Entry Point | |-----------|---------|-------------|-------------| | [Name] | | | | | [Name] | | | | ## What We Don't Do [Define your boundaries. What work do you refer out? What's out of scope?] ## Governing Principles [List 4-6 non-negotiable rules for how you operate. These settle arguments when other documents disagree.] 1. [Principle] 2. [Principle] ## Document Reference Table | Document | Purpose | Reference When... | |----------|---------|-------------------| | Kernel | Strategic orientation | Making positioning decisions | | [D01] | | | | [D02] | | |
Template 2: Sales Offerings
# [Your Practice Name] Sales Offerings ## Service Menu [For each service you offer:] ### [Service Name] - **For:** [Which archetype] - **Solves:** [What problem] - **Format:** [How it's delivered] - **Pricing approach:** [Fixed fee / value-based / per-session. Note: you don't have to put exact numbers here. Principles matter more than figures.] - **Entry point:** [How someone gets to this service] ## Pricing Principles [The rules that govern how you price. Examples: "Price the client, not the service." "The price floor rises with each engagement." "Three-option proposals, always."] 1. [Principle] 2. [Principle] ## What We Explicitly Don't Sell [Services people ask for that you don't offer. Where do you send them instead?]
Template 3: Customer Journey
# [Your Practice Name] Customer Journey ## Stage 1: [First Contact / Discovery Call / etc.] - **Goal:** [What you're trying to learn or establish] - **Key questions to ask:** 1. [Question] 2. [Question] - **Follow-up:** [What happens after this stage] - **Email template:** [Draft your standard follow-up for this stage] ## Stage 2: [Proposal / Diagnostic / etc.] [Repeat the structure above for each stage] ## Disengagement Script [What you say when a prospect isn't the right fit. This is as important as your sales script.]
Template 4: Diagnostic SOP
# [Your Practice Name] Diagnostic SOP
## Pre-Session
- [ ] [Preparation step]
- [ ] [Preparation step]
## Session Structure
| Time Block | Focus | Key Questions |
|-----------|-------|---------------|
| First 15 min | [Topic] | [Questions] |
| Next 20 min | [Topic] | [Questions] |
| Final 15 min | [Topic] | [Questions] |
## Post-Session Reflection ("Hot Wash")
Answer these within 24 hours:
1. What pattern did I identify?
2. What went well?
3. What would I do differently?
Template 5: Deliverable Template
# [Client Name] - [Deliverable Title] ## Executive Summary [2-3 sentences: what we found, what we recommend] ## What We Examined [Scope of the diagnostic] ## Findings ### Priority 1: [Name] - **The problem:** [Description] - **The impact:** [What it costs in time, money, or opportunity] - **The recommendation:** [What to do about it] ### Priority 2: [Name] [Repeat] ## Recommended Next Step [One clear recommendation. Not a menu. Your expert opinion.]
Template 6: Labs Playbook
# [Your Practice Name] Labs Playbook ## The Rules 1. The Lab is R&D, not sales. No free proofs-of-concept for prospects. 2. The Lab builds reusable assets, not one-off solutions. 3. Every Lab project generates at least one piece of content. ## R&D Idea List | Idea | Source | Reuse Potential | Status | |------|--------|----------------|--------| | | | | | ## Build Rhythm [When do you do Labs work? How much time per week?] ## The "No Free PoC" Script [What you say when a prospect asks you to build something for free during a sales conversation]
Template 7: System Instructions
# System Instructions for [Your Practice Name] AI ## Your Role You are [role description]. You help me [what the AI does for you]. ## Your Voice [Match this to your own communication style. Formal? Conversational? Technical? Warm?] ## Document Routing When I ask about... - Positioning or boundaries -> reference the Kernel - Pricing or services -> reference Sales Offerings - Client communication -> reference Customer Journey - Running a diagnostic -> reference Diagnostic SOP - Producing deliverables -> reference Deliverable Template - R&D or ideas -> reference Labs Playbook ## Rules 1. [What the AI should always do] 2. [What the AI should never do] 3. [How to handle conflicts between documents]
What Comes Next
If you’ve read this far, you’re probably in one of two places.
You might be thinking “I can build this myself” – and you can. The templates above are enough to get started. Build the Kernel first, add one more document, test it, then expand. Give yourself a few weeks. It won’t be perfect on the first pass, and that’s fine.
Or you might be thinking “I can see the architecture, but I’d want help building mine properly.” If that’s where you are, we run a 90-minute session where we build the first two components of your system together, live. You walk out with a working Kernel and Sales Offerings document, configured in Claude Projects, ready to use.
Either way, the important thing is to start with the Kernel. Everything else flows from it.
If you’d like to talk through which approach makes sense for you, you can book a free Focus Call.
— Alastair
