You know that feeling when you read a great book, highlight the good parts, and then... never look at those highlights again? I had a full digital copy of "The Presentation Secrets of Steve Jobs" sitting in my files. Three hundred and fifty pages of genuine expertise. But when I actually needed to prepare a board presentation? I'd start from scratch, vaguely remembering "something about the rule of three."
Here's what I realized: the knowledge existed. My problem wasn't finding expertise. It was making that expertise available at the moment I needed it. Not as a book to re-read, but as tools I could actually invoke.
The Context Gap
The book contained everything: headline creation, slide design principles, the "holy shit moment" formula, number dressing techniques, rehearsal protocols. But all of that knowledge lived in one massive file that AI couldn't even read (too large) and I wouldn't re-read (too long).
This is the classic context problem: expertise exists somewhere, but it's not structured for use. It's like having a brilliant mentor who's only available when you have four hours to sit down and listen to them talk.
The insight: Raw knowledge isn't useful context. For AI to help you apply expertise, that expertise needs to be architected: structured, discoverable, invocable at the right moment.
What I Built
Rather than creating a summary (which would just be another document to not read), I transformed the book into a three-layer system:
Layer 1: Knowledge Entry. A synthesized reference document with frontmatter triggers. When I mention "presentation" or "board meeting," this loads automatically. It contains the 10 Commandments as a scannable TL;DR, the core frameworks, CMO-specific application guides, and quick-reference checklists.
Layer 2: Specialized Agents. Instead of one "presentation expert" that tries to do everything, I built two focused agents:
- A Presentation Coach for strategic review: finding headlines, structuring the story, identifying the "holy shit moment"
- A Data Storyteller for one specific skill: transforming raw numbers into compelling statements
Layer 3: Procedural Skill. A step-by-step workflow I can invoke when I want to follow the full Jobs methodology from start to finish.
What's in my context layer now:
- Reference document that auto-loads when relevant (with 10 Commandments, 5 frameworks, 4 CMO contexts)
- Presentation Coach agent for strategic dialogue
- Data Storyteller agent for number transformation
- Presentation Prep skill for structured workflow
- Integration with my agent index for discoverability
The key decision: splitting capabilities rather than building one monolithic agent. Number transformation is genuinely different from structural coaching. Users can invoke just what they need.
How It Actually Works
Last week I needed to present marketing results to the board. Instead of opening the book or starting from scratch, I invoked the Data Storyteller:
"We had 4 million downloads" became "20,000 downloads every single day since launch, one every four seconds."
"5% market share" became "Greater than BMW or Mercedes in the automotive industry, and nobody thinks they're going away."
For the structure, the Presentation Coach asked me: "If the board remembers ONE thing from this presentation, what is it?" That question (which came directly from the Jobs methodology) shaped everything that followed.
The unexpected benefit: the agents reference each other. The Presentation Coach knows to suggest the Data Storyteller when it sees numbers in a deck. The system is smarter than any single tool.
The Context Layer Lesson
This wasn't just about presentations. It revealed a pattern for turning any dense expertise into usable AI tools.
Dense expertise needs three layers, not one. Reference material (for looking things up), agents (for interactive dialogue), and skills (for structured workflows) serve different needs. A single "expert document" tries to do all three and does none well. (This mirrors what I learned about how knowledge flows through memory systems. Different types of context need different treatment.)
Specialized agents beat super-agents. One agent doing one thing deeply is more useful than one agent doing ten things adequately. Users can combine them as needed, and each agent can go deeper on its specialty.
Integration work is essential. Building the agents wasn't enough. I had to update indexes, create keyword triggers, add composition patterns. Undiscoverable tools don't get used. The architecture of discoverability matters as much as the tools themselves.
Try This Yourself
You probably have expertise sitting in files right now: books, courses, methodologies, notes from mentors. The question isn't whether to read them again. It's how to architect them for use.
Start with one source of expertise. Ask: What are the 3-5 distinct capabilities buried in here? Could each be a focused agent or a simple checklist? What would trigger me to need this?
Start here: Take one book or methodology you've read. Write down the single most useful framework from it in 3-5 bullet points. That's your first knowledge entry. Now ask: "When would I need this?" That's your
when-to-usetrigger.
Questions You Might Have
Isn't this overkill for one book?
For one book, maybe. But the pattern scales. I've now done this with three methodologies. Each took about 45 minutes. And each now compounds. Every presentation, every data-heavy report, every board meeting benefits from expertise that's actually accessible.
How do I know what to include vs. cut?
Start with your use cases. I'm a CMO, so I focused on board presentations, product launches, and internal comms. A salesperson would extract different frameworks from the same book. The expertise stays the same; the architecture serves your actual work.
What if I don't have a system like yours?
You don't need my exact setup. The principle works anywhere: synthesize → structure → make discoverable. That could be a Notion database, a folder of markdown files, or even a single document with clear sections. The architecture matters more than the tools.
Can AI do this extraction automatically?
Partly. AI is great at synthesizing and structuring. But you have to decide what's important for your work, how to split capabilities, and what triggers matter. The architecture decisions are human decisions. (I used a similar approach when building a visual asset creator. AI generated the images, but I defined the semantic color system and metaphor library.)
How does this connect to the broader context layer idea?
This is context architecture in action. Raw knowledge (a book) becomes structured context (a knowledge entry) becomes active capability (agents and skills). Each layer builds on the previous. And once it's built, it compounds. The expertise is now part of your system, not a file you hope to re-read someday.
Building context that compounds.
