Your AI Doesn't Remember Last Quarter. Here's How to Fix That.
Part 2 of the AI-Powered GTM Stack series.
A practical guide to building a compounding knowledge system for vertical SaaS GTM teams. This is the infrastructure that turns Claude from a smart assistant into an intelligence engine that gets sharper every week. Includes the 4-layer architecture, step-by-step setup, governance model, and real examples from a system managing 281 knowledge nodes and $100M+ in pipeline.
This is Part 2 of a 6-part series on building an AI-powered GTM operating system with Claude Code.
The Amnesia Problem
Your VP of Sales just asked: “What do we know about our biggest competitor’s customer retention issues? Didn’t we win 8 deals from them last year?”
Someone searches Slack. Someone opens a Google Doc from six months ago. Someone asks the AE who closed that big deal we won last year, except she left in November. The information exists, but it’s scattered across CRM notes, call transcripts, Slack threads, and people’s heads.
So you do what everyone does now. You open Claude, paste in some context, and ask. It gives you a reasonable answer based on what you pasted in. But it doesn’t know about the 12 verified competitor displacement wins, the specific accuracy differential (90% vs. 60%), the $4.4M in ARR won, or the three customer quotes that close deals when deployed at the right moment.
Next week, a different rep asks the same question. They paste in different context. They get a different answer.
This is the amnesia problem. AI is brilliant in the moment and completely empty between moments. Every conversation starts from zero. Every user gets a different version of the truth. The intelligence your team generates (from hundreds of calls, dozens of wins, years of competitive encounters) evaporates between sessions.
We fixed this. Not with a vector database. Not with RAG. Not with a chatbot sitting on top of Google Drive.
We built a structured knowledge system where every piece of GTM intelligence has an address, a lifecycle, a governance model, and connections to related intelligence. Claude doesn’t guess. It navigates. And the system gets denser, more connected, and more valuable every week.
This article is the blueprint.
I built this system at Handle.com, where I run GTM intelligence for a construction fintech platform. Before Handle, I spent a decade at CourseKey (now Portico) watching tribal knowledge walk out the door every time someone left. We lost co-founders, we lost top AEs, and every time we lost months of accumulated intelligence that existed nowhere but their heads. Context OS is what I wish I’d built five years earlier.
Why “Just Use RAG” Doesn’t Work for GTM
If you’ve looked into giving AI “memory,” you’ve probably encountered RAG (Retrieval Augmented Generation). Upload your docs, chunk them, embed them, search them. It’s the default answer to “how do I make AI remember stuff?”
Here’s why RAG fails for GTM intelligence:
1. RAG treats all documents equally. Your battle-tested competitive displacement playbook and a random Slack message about a competitor get the same treatment. There’s no concept of validated versus speculative intelligence, no lifecycle for concepts that mature from hypothesis to proven pattern.
2. RAG has no structure. When you ask “what do we know about [competitor X]?”, RAG retrieves chunks that mention them. It doesn’t know that [competitor X] connects to 6 verified displacement wins, a specific pricing objection pattern, 2 active pipeline deals, and a talk track that’s closed $526K+ in ARR. Structure is what turns information into intelligence.
3. RAG can’t govern quality. Anyone can add anything. Nothing gets validated. Nothing gets deprecated. There’s no blessed vocabulary, no tag hygiene, no quality gates. Six months in, you have 2,000 chunks of varying quality with no way to tell which ones are trustworthy.
I know because I tried it. My first attempt at giving our AI “memory” was exactly this: dump everything into a knowledge base and hope retrieval would sort it out. Garbage in, garbage out. I learned that in my accounting class in college, and it turns out it applies to AI knowledge systems too.
4. RAG doesn’t compound. Each document exists in isolation. There’s no mechanism for connecting a new win to an existing competitive pattern, or for promoting a hypothesis to a proven framework after it’s been validated three times. The knowledge base stays flat. It grows in volume but not in intelligence.
What you actually need is a knowledge graph: structured, governed, interconnected, and designed to get smarter over time.
The 4-Layer Architecture
I call it Context OS, a term I borrowed from Jacob Dietle at taste.systems, who first articulated the idea that AI context should be treated as an operating system, not a document store.
I took that idea and built it into a production system managing 281 knowledge nodes, 6 connected data sources, and $100M+ in active pipeline. Here’s what the architecture looks like when it’s not theoretical.
Here’s the architecture. Four layers, each with a specific job, each building on the one below it.
Layer 1: Claude Configuration
What it does: Teaches Claude WHO it's working for
Contains: Identity, preferences, quality gates, correction log, slash commands
Changes: Rarely (when team norms evolve)
Layer 2: Constitutional Rules
What it does: Defines the VOCABULARY and RELATIONSHIPS of your knowledge
Contains: Blessed tags (taxonomy), relationship types (ontology)
Changes: Infrequently (when new categories emerge)
Layer 3: Operational Foundation
What it does: Compresses hundreds of nodes into FAST-PATH executive summaries
Contains: Positioning framework, persona messaging, competitive intel, methodology cheat sheet
Changes: Monthly (as win/loss data and competitive intel update)
Layer 4: Knowledge Graph
What it does: Stores ATOMIC intelligence, one concept per node, richly connected
Contains: Competitor profiles, frameworks, case studies, account intelligence, personas
Changes: Weekly (as new intelligence arrives)
The Key Insight: Each layer has a different rate of change and a different audience.
Layer 1 is for Claude’s configuration. You set it once and update occasionally.
Layer 2 is the constitution that governs what goes in and how it connects.
Layer 3 is for humans who need answers fast. Read four documents and know 95% of what matters.
Layer 4 is where the raw intelligence lives…dense, interconnected, and growing.
Most teams try to build Layer 4 first and skip everything else. That’s like filling a library with books but having no catalog, no shelving system, and no librarian.
Layer 1: Claude Configuration. Teaching AI Who You Are
This is the foundation everything else builds on. If you’re using Claude Code (Anthropic’s CLI tool), this lives in your CLAUDE.md files and settings.
What Goes Here
Global Identity: not “you are a helpful AI assistant.” Real context:
Who I Am: Head of GTM Intelligence at [Company]
What We Sell: Construction compliance + payments platform
My Role: GTM strategy, AI solutions, sales enablement
How I Work: Explain reasoning, present trade-offs, let me decide
Quality Gates: the things Claude should never do without explicit permission. In GTM work, this typically includes: never push code to production, never generate client-facing deliverables without review, never delete existing work, never commit to shared repositories.
Correction Log: and this is the part most people skip. Every time Claude makes a mistake (assumes the complex solution, deletes something that was still in use, skips error handling) you log it. Claude reads this log at the start of every session and learns from it.
The correction log matters because without it, you fix the same mistake in every session. With it, you fix it once and it stays fixed. Over six months, our correction log has 26 entries…these are mistakes that will never be repeated.
Entity Memory: key people, companies, and projects that come up repeatedly. Your sales team’s names, your top accounts, your active engagements. This prevents Claude from asking “who is Eric?” for the third time this week.
Slash Commands: Methodology as Executable Actions
This is where Layer 1 connects to the Skills article. Your methodology (the frameworks, scoring systems, and playbooks) gets packaged as slash commands.
We run 28 slash commands across two levels:
Global Commands (available in every project):
/battlecard,/business-case,/call-coaching,/outbound-sequence: the sales methodology suite/ingest,/graph-health,/context-os-setup: the knowledge management suite/debug,/tdd,/verify: the development suite
Project Commands (available only in my Handle.com platform project):
/pulse: score a deal using 16 signals and write results to the database/build-bcr: generate a 16-page branded business case recommendation/sync-pipeline-stages: check Salesforce deal stages via Endgame AI
The difference between global and project commands is portability. Global commands work anywhere because they embody your methodology. Project commands are wired into specific infrastructure: databases, APIs, dashboards.
The Setup (30 minutes)
Create
~/.claude/CLAUDE.mdwith your identity, preferences, and quality gatesStart a correction log section (empty is fine; it fills over time)
Add entity memory for your team, top accounts, and active projects
Reference your knowledge base location so Claude knows where to look
That’s it for Layer 1. The investment is 30 minutes. The payoff is every future session starting with full context instead of zero.
Layer 2: Constitutional Rules. The Grammar of Your Knowledge
This layer is small (two YAML files) and it’s the most important thing you’ll build. It defines the vocabulary, relationships, and quality standards for everything that enters your knowledge system.
Taxonomy: Your Blessed Vocabulary
The taxonomy defines every tag, category, and label your knowledge base can use. Nothing else is allowed.
# Example Handle.com taxonomy.yaml (simplified)
version: 1.0.0
domains:
blessed:
- technical # Platform architecture, APIs
- business # ICP, pricing, positioning
- gtm # Sales, marketing, enablement
- methodology # Frameworks and processes
node_types:
blessed:
- concept # Core ideas and definitions
- framework # Structured methodologies
- competitor-intel # Competitive intelligence
- win-loss # Deal outcome analysis
- account-profile # Account-level summary
status_values:
blessed:
- emergent # Identified but not proven
- validated # Proven in practice (1+ times)
- canonical # Proven and referenced (2+ times)
topic_library:
gtm:
- icp
- value-proposition
- competitive-positioning
- battlecard
- deal-progression
- pipeline-health
- displacement
- champion-development
competitors:
- billtrust
- levelset
- ncs-credit
# ...every named competitor
personas:
- cfo
- vp-credit
- controller
- ar-manager
# ...every target buyer
quality_thresholds:
tag_sprawl_warning: 20 # Alert if >20% of tags are single-use
minimum_topic_count: 3 # Every node needs 3+ topics
maximum_topic_count: 7 # No node should have 7+ topics
Why This Matters: Without a blessed vocabulary, your knowledge base drifts. One person tags a node “competitive,” another uses “competition,” a third uses “comp-intel.” Six months later you have 40% tag sprawl and search becomes unreliable.
The taxonomy is the agreement your team makes. These are the words we use, these are the categories that exist, and nothing else gets in without a deliberate decision.
Ontology: How Things Connect
The ontology defines the types of relationships between knowledge nodes.
# Example ontology.yaml (simplified)
relationship_types:
enables: "A makes B possible"
supports: "A provides evidence for B"
implements: "A is practical execution of B"
competes_with: "A is competitive alternative to B"
displaced_by: "A was replaced by B at a specific account"
counters: "A is a response to objection B"
targets: "A is designed for persona B"
validates: "A proves B is true in practice"
linking_requirements:
all_nodes:
minimum_links: 3 # Every node links to 3+ other nodes
emergent_nodes:
minimum_links: 1 # New concepts start with 1 link
account_scoping:
rules:
- "Account nodes cannot link directly to other account nodes"
- "When a pattern repeats across 2+ accounts, extract it to a GTM-layer node"
- "Stakeholder details stay in account-scoped nodes only"
The account scoping rule is critical. It prevents cross-contamination between account intelligence. Your most recent displacement story should not link directly to a previous displacement story, even though they have similar patterns. Instead, both feed into a competitor1-displacement-playbook pattern node in the GTM layer. The playbook references both accounts as evidence, but contains no account-specific operational data.
This is what transforms account-level anecdotes into organizational intelligence.
The Setup (1 hour)
Create
_system/knowledge_graph/taxonomy.yaml. Start with 3-4 domains, 5-6 node types, and your current vocabularyCreate
_system/knowledge_graph/ontology.yaml. Start with 5-6 relationship types and the linking minimumList your competitors, personas, and industries. This becomes the blessed vocabulary for these categories
Set quality thresholds: tag sprawl warning at 20%, minimum 3 topics per node
Start small. Your taxonomy will grow as you ingest content. The point of the starting taxonomy isn’t to be comprehensive. It’s to establish the habit of governed vocabulary from Day 1.
Layer 3: Operational Foundation. The 5% That Answers 95% of Questions
This is the layer most knowledge management systems skip, and it’s the one your team will actually use daily.
The foundation layer compresses your entire knowledge graph into 3-5 executive summary documents. A new AE should be able to read these documents and understand 95% of what matters about your positioning, personas, methodology, and competitive landscape.
The Four Foundation Documents
1. Competitive Intelligence Summary: Your complete competitive map. Threat rankings with evidence. Capability comparison matrix. Win/lose quick reference. Active pipeline against named competitors. Market data.
Example content:
## Threat Ranking (as of Mar 2026)
| Rank | Competitor | Threat | Verified Wins Against |
|------|------------ |--------|----------------------|
| 1 | Competitor 1 | HIGH | 6+ wins, $526K+ ARR |
| 2 | Competitor 2 | HIGH | 12+ wins, $4.4M+ ARR |
| 3 | Competitor 3 | HIGH | 2+ wins, $1.7M+ ARR |
Not opinions. Evidence-backed rankings sourced from actual pipeline data.
2. Sales Methodology Cheat Sheet: Every framework your team uses, compressed into a single reference document. The full sales flow at a glance. SPIN discovery. Challenger demo. MEDDPICC qualification. 16-signal deal scoring. Qualification gates. The complete playbook in one place.
3. Positioning Framework: Your platform story, value propositions, uncontested capabilities, verified win record, and market context. Where you win, where you compete, where you don’t play.
4. Persona Messaging Framework: Every buyer persona with opening hooks, pain language, value props, proof points, top objections with responses, and discovery questions. Multi-threading map showing how to navigate the buying committee.
The Critical Rule
Foundation documents are built from knowledge nodes. They don’t duplicate them. Every claim references a wiki-linked source node:
Handle's verified win record now totals 22+ competitive wins in 2025, $5.2M+ ARR (see [[win-loss-intelligence]]). Key patterns: 35% of losses are to incumbent inertia, not competitive feature gaps.
When the underlying node updates (a new win, a new competitor data point, a revised loss pattern) the foundation document gets refreshed. The synthesis changes, but the source of truth stays in the knowledge graph.
The Setup (2-3 hours per document)
You don’t write these from scratch. You write them after your knowledge graph has 30-50 nodes. They emerge naturally from the patterns your graph reveals.
Start with whichever document your team needs most (usually competitive intelligence or methodology)
Pull from existing knowledge nodes. Don’t create new content
Use
[[wiki-links]]to connect every major claim to its source nodeSet a refresh cadence. Monthly is usually right for GTM foundation docs
Date-stamp the document. Stale foundation docs are worse than none
Layer 4: The Knowledge Graph. Where Intelligence Lives
This is the layer most people think of when they hear “knowledge base.” Individual nodes (one concept per file) with rich metadata and connections to other nodes.
What a Knowledge Node Looks Like
Every node follows the same structure:
---
name: COMPETITOR_DISPLACEMENT_PLAYBOOK
description: "Talk tracks and positioning for displacing COMPETITOR"
domain: gtm
node_type: displacement
status: canonical
last_updated: 2026-02-17
tags:
- gtm
- competitive-positioning
topics:
- competitive-positioning
- displacement
- deal-progression
related_concepts:
- "[[competitive-landscape]]"
- "[[win-loss-intelligence]]"
- "[[enterprise-champion-model]]"
source:
type: endgame
documents:
- "Salesforce Opportunity records"
- "Competitive Intelligence Guide 2.0"
date: "2026-02-17"
---
# COMPETITOR Displacement Playbook
Competitor was acquired in November 2021 for ~$500M. Since then, we have won 12+ verified displacement deals totaling $4.4M+ ARR...
[VERIFIED: Sourced from Endgame (Salesforce records, call transcripts)]
Notice what’s happening here:
YAML frontmatter makes the node machine-readable. Claude can filter by domain, status, topic, or node type.
Topics use blessed vocabulary from the taxonomy. No freestyle tagging.
Related concepts create the graph connections. This node links to competitive-landscape, win-loss-intelligence, and enterprise-champion-model.
Status tracks the lifecycle. This node is
canonical, meaning it’s been referenced 2+ times and proven in practice.Source attribution proves where the information came from. VERIFIED means it’s backed by primary sources.
The Knowledge Lifecycle
Concepts don’t arrive as facts. They arrive as hypotheses that mature through validation.
emergent → validated → canonical
| | |
| | └─ Referenced 2+ times, proven pattern
| └─ Proven once in practice
└─ New idea, not yet tested
When a rep reports that a new objection-handling technique worked on a call, that’s emergent. When it works on three calls, it’s validated. When it’s referenced by two other nodes and deployed in an outbound sequence, it’s canonical.
This lifecycle is what separates a knowledge system from a document dump. Documents are static. Knowledge nodes mature.
Our Graph by the Numbers
After 6 months of building:
Every node connects to 3+ other nodes via wiki-links. The graph has zero orphans, zero tag sprawl, and clear lineage from source material to operational intelligence.
The Node Creation Workflow
You don’t manually create 281 nodes. You ingest content and let the system decompose it:
Source arrives: a call transcript, a competitive document, a win/loss report, a product brief
Run
/ingest: Claude analyzes the content type, identifies atomic concepts, and generates structured nodesEach node gets: YAML frontmatter (name, domain, type, status, topics, links, source), a 2-3 paragraph explanation, key points, evidence with direct quotes, and related concept links
Node is saved to the correct knowledge_base/ subdirectory based on domain
Hookify guards validate: frontmatter present? Topics from blessed taxonomy? 3+ wiki-links? Source documented?
The guard rails are critical. Without them, quality degrades as the graph grows. With them, every node that enters the system meets the same standard.
The Governance Model: Quality Gates That Scale
This is the part that makes the difference between a knowledge base that stays useful and one that becomes a junk drawer.
6 Automated Guards
We use hookify, a Claude Code plugin that runs validation rules on every file write. When Claude tries to save a knowledge node, these guards fire:
These guards run automatically. Claude doesn’t have to remember the rules. The rules enforce themselves. A new team member ingesting their first piece of content gets the same quality standard as someone who’s been using the system for six months.
The Health Check
Beyond automated guards, we run periodic health checks on the full graph:
# Knowledge Base Health Report
Generated: 2026-03-05
## Summary
Overall Health: Healthy
## Inventory
Total Nodes: 281
By Domain: technical 5, business 9, gtm 36, methodology 11, accounts 220
## Tag Health
Tag Sprawl: 0% - Healthy
Single-use tags: 17 (all legitimate industry verticals)
## Link Health
Orphan Nodes (< 3 links): 0
Broken Links: 0
## Lifecycle Health
Aging Emergent Nodes (> 30 days): 0
This runs as a slash command (/graph-health) and takes about 2 minutes. It catches drift before it becomes a problem: tags that aren’t in the taxonomy, nodes that have gone stale in emergent status, wiki-links pointing to nodes that don’t exist.
The maintenance cadence: run /graph-health monthly. Fix what it finds. It’s 30 minutes of maintenance that protects months of accumulated intelligence.
The Feedback Loop: Where the System Gets Smart
Skills are the methodology execution engine. The knowledge graph is the intelligence substrate. The feedback loop is what connects them.
Skills generate intelligence → Stored in knowledge graph
↓
Knowledge graph feeds ← Foundation docs updated
back into skills
Here’s what this looks like in practice:
Step 1: A rep runs /pulse on an active deal. The skill scores 16 signals across four pillars (Why Anything, Why Us, Why Now, Execution). The output is stored in two places: Supabase (for the pipeline dashboard) and knowledge_base/accounts/{slug}/pulse-report.md (for the knowledge graph).
Step 2: After 10 pulse reports, patterns emerge. Deals against competitor X tend to be Yellow on the “Why Now” pillar because incumbents create inertia without a compelling event. This pattern gets extracted into the service-bureau-displacement-playbook node.
Step 3: The displacement playbook feeds back into skills. The next time a rep runs /competitive-strategy against competitor X, the skill pulls the displacement playbook, including the “Why Now” weakness pattern, and builds it into the win plan.
Step 4: Foundation docs update monthly. The competitive intelligence summary absorbs the new win data, the updated threat rankings, and the refined displacement patterns. A VP reading the summary gets the latest intelligence without touching the knowledge graph directly.
This is why the system compounds. Every deal scored, every call coached, every competitive encounter adds intelligence to the graph. The graph feeds the foundation docs. The foundation docs feed the skills.
The skills arm the next rep for the next deal. The flywheel accelerates.
A System That Remembers: Month 0 vs. Month 6
Month 0 (Day You Set This Up)
Layer 1: Claude knows your identity, your team, your preferences. It stops asking “what does your company do?” every session.
Layer 2: Taxonomy has 30 blessed terms. Ontology defines 6 relationship types. Guards are in place.
Layer 3: Empty. You don’t have enough nodes yet.
Layer 4: 10-20 seed nodes from your first content ingestion. Competitive profiles, core methodology, ICP definitions.
Claude is better than vanilla, but still feels thin. Most questions require the user to provide context.
Month 1
Knowledge graph: 40-60 nodes. Competitive landscape taking shape. Key frameworks documented.
Foundation docs: First synthesis doc written (usually competitive intelligence).
First feedback loop: A pulse report references a competitive node. A slash command pulls from the knowledge graph for the first time.
Noticeable change: Competitive questions get answered without copy-pasting context. Discovery prep pulls from real framework nodes instead of generating generic questions.
Month 3
Knowledge graph: 100-150 nodes. Account intelligence accumulating from pulse reports and Endgame queries.
Foundation docs: All four written. Team starts using the methodology cheat sheet as a daily reference.
Guards catching issues: Tag sprawl flagged and fixed. Two emergent nodes promoted to validated. One stale node archived.
Noticeable change: New hires onboard faster because the methodology is executable, not just documented. Pipeline reviews reference signal intelligence from the graph. Competitive encounters pull displacement playbooks automatically.
Month 6
Knowledge graph: 250+ nodes. 100+ account profiles. Patterns emerging across accounts.
Foundation docs: Refreshed twice. Win/loss data current. Threat rankings evidence-based.
System intelligence: The graph answers questions the team didn’t think to ask. “Which deals against Levelset tend to stall, and why?” Answerable from the graph in seconds.
Noticeable change: The system knows more about your competitive landscape, buyer personas, and deal patterns than any individual on the team. It’s not a knowledge base. It’s institutional memory that doesn’t quit.
The Setup Playbook: Weekend Build, Monday Launch
Here’s the complete build sequence, from zero to operational. Time estimate: one focused weekend.
Saturday Morning: Layer 1 + Layer 2 (2-3 hours)
Hour 1: Claude Configuration
Create
~/.claude/CLAUDE.md: identity, preferences, quality gates, correction logAdd entity memory: team members, key accounts, active projects
Reference your project directory and knowledge base location
Hour 2: Constitutional Rules
Create
_system/knowledge_graph/taxonomy.yaml: domains, node types, status values, topic library, competitors, personas, industriesCreate
_system/knowledge_graph/ontology.yaml: relationship types, linking requirements, account scoping rules, attribution standardsStart with your current vocabulary. It doesn’t need to be perfect. It needs to exist.
Hour 3: Folder Structure + Guards
Create directory structure:
your-project/
├── knowledge_base/
│ ├── technical/
│ ├── business/
│ ├── gtm/
│ │ ├── competitive/
│ │ ├── enablement/
│ │ └── outbound/
│ ├── methodology/
│ ├── accounts/
│ └── emergent/
├── 00_foundation/
│ ├── positioning/
│ ├── messaging/
│ └── _synthesis/
└── _system/
└── knowledge_graph/
├── taxonomy.yaml
└── ontology.yaml
Set up quality guards (hookify or manual checklists)
Test: write a dummy node, verify guards catch missing frontmatter
Saturday Afternoon: Layer 4 Seed Content (3-4 hours)
Your first ingestion targets (pick 3-5):
Your competitive battle card or competitive intelligence document
Your sales methodology training deck or playbook
Your ICP definition document
Your buyer persona profiles
Your best win story or case study
For each piece of content:
Run
/ingestor manually decompose into atomic nodesEach node gets YAML frontmatter, 2-3 paragraphs of content, wiki-links to related nodes
Save to the correct subdirectory
Verify: frontmatter complete, topics from taxonomy, 3+ wiki-links, source documented
Target: 15-25 seed nodes by end of Saturday. This is enough to start seeing connections.
Sunday: Layer 3 Foundation Docs (2-3 hours)
Write your first foundation document. Choose the one your team needs most:
If competitive deals are your pain → Competitive Intelligence Summary
If methodology consistency is your pain → Sales Methodology Cheat Sheet
If positioning clarity is your pain → Positioning Framework
If persona messaging is your pain → Persona Messaging Framework
The writing process:
Open 5-10 of your seed nodes
Synthesize, don’t duplicate. Compress patterns, reference sources with
[[wiki-links]]Include tables, quick references, and actionable formats
Date-stamp it. Set a refresh reminder for 30 days.
Monday: Ship It
Walk the team through the foundation doc. This is their “read this first” reference
Show one slash command in action:
/meeting-prepor/battlecardpulling from real knowledge nodesAssign ongoing ingestion: every new win story, competitive encounter, or methodology refinement gets ingested
Schedule the first
/graph-healthcheck for 30 days out
Common Mistakes (and How to Avoid Them)
Mistake 1: Building the Graph Before the Constitution
What happens: You create 50 nodes with no taxonomy. Tags are freestyle. Some say “competitive” and others say “competition” and others say “comp-intel.” Connections are random. Six months later, you can’t search reliably.
Fix: Spend one hour on taxonomy.yaml before creating a single node. You can always add blessed terms later, but you can’t retroactively standardize freestyle tags without touching every file.
Mistake 2: Creating Nodes Without Connections
What happens: Each node is an island. 200 nodes with zero wiki-links. Claude can find individual nodes by keyword, but can’t traverse from one concept to a related concept. You have a document store, not a knowledge graph.
Fix: The 3-link minimum in the ontology. Every node connects to 3+ other nodes. Every connection is a traversal path. No orphans.
Mistake 3: Skipping the Foundation Layer
What happens: You have a rich knowledge graph but no synthesis. Every question requires Claude to search across dozens of nodes, assemble context, and hope it finds the right combination. Answers are slower and less reliable.
Fix: Foundation docs are the cache layer. They compress the most-accessed intelligence into fast-path documents. Claude reads one 200-line synthesis instead of traversing 50 nodes. Answers are faster and more consistent.
Mistake 4: Never Graduating Emergent Nodes
What happens: Every node stays emergent forever. There’s no concept of validated intelligence versus speculative ideas. A proven methodology framework and a random hypothesis from a single call have the same status.
Fix: Monthly lifecycle review. Emergent nodes older than 30 days get promoted to validated (if proven) or archived (if not). The status field is the trust signal. canonical nodes are the ones you bet the deal on.
Mistake 5: Treating Account Nodes Like GTM Nodes
What happens: Your Company A displacement story references your Company B displacement story. When the Company A story updates, Company B details might leak in. Account intelligence cross-contaminates.
Fix: Account scoping rules in the ontology. Account nodes link UP to pattern nodes in the GTM layer, never SIDEWAYS to other accounts. When a pattern repeats across 2+ accounts, extract it into a reusable GTM node. The GTM node references accounts as evidence but contains no account-specific operational data.
Why This Matters for Vertical SaaS GTM Leaders
If you read our companion article on Claude Skills, you know the Skills are the methodology execution engine. They turn frameworks into operational output for every rep, every deal, every day.
But Skills without a knowledge substrate are still drawing from generic context every time. They’re powerful, but they’re not compounding.
Context OS is what makes Skills compound. It’s the infrastructure layer that:
Makes institutional knowledge permanent. When your best AE leaves, their tribal knowledge (the competitive insights, the persona intuition, the discovery patterns built over two years) survives in the graph. It’s not in their head. It’s in nodes, with metadata, connections, and evidence.
Makes AI answers consistent. When three different reps ask “what do we know about competitor X?”, they get the same answer, because there’s one canonical node with one verified set of intelligence. Not three different search results from three different document chunks.
Makes intelligence compound weekly. Every pulse report, every ingested call, every competitive encounter adds a node, updates a connection, or promotes a hypothesis. The system on Friday is smarter than the system on Monday. Every week. Automatically.
Makes onboarding a graph traversal, not a training program. A new hire reads four foundation docs, runs their first slash command, and gets methodology-graded output on Day 1. They don’t need to internalize 200 nodes. The system navigates the graph for them. They learn by doing, with the graph as their guide.
This pattern isn’t construction-specific. At CourseKey, we spent a decade in vocational edtech selling to compliance-driven trade schools. Every time a top AE or co-founder left, months of accumulated intelligence about accreditation workflows, placement rate optimization, and institutional buying cycles walked out with them. A Context OS would have captured all of that in structured, connected nodes instead of letting it evaporate. The architecture works in any vertical where domain knowledge is the competitive advantage.
The math for vertical SaaS…you already have the domain expertise: the ICP knowledge, the competitive intelligence, the buyer persona insights, the proven methodology. That expertise is your moat. Context OS is the vault that protects it and the engine that multiplies it.
The Complete Stack: Skills + Context OS
The two articles together describe the full system:
Skills without Context OS = powerful but amnesiac. Context OS without Skills = intelligent but passive. Both together = a GTM intelligence engine that gets smarter every week.
The Full Series: AI-Powered GTM Stack (Built with Claude Code)
This is Part 2 of a 6-part series on building an AI-powered GTM operating system with Claude Code.
Get the System
Start with the Skills. If you haven’t read the companion article, start there. The 14-skill methodology suite gives you immediate operational value.
Your Reps Are Using AI Like a Search Bar. Here's What the Top 1% Are Doing Instead.
A practical guide to Claude Code Skills, the system turning vertical SaaS sales teams into methodology-driven machines. Built on Claude Code, Anthropic’s AI-powered development CLI. Includes the 14-skill sales methodology suite, 3 before/after scenarios, and a portable framework you can deploy for any vertical.
Then build the Context OS. Follow the Weekend Build playbook in this article. Layer 1 + Layer 2 on Saturday morning. Seed content on Saturday afternoon. First foundation doc on Sunday. Ship it Monday.
Get the setup templates. Starter taxonomy.yaml, ontology.yaml, and folder structure, pre-configured for vertical SaaS GTM.
Join the Guild. The Vertical GTM Guild is where vertical SaaS GTM leaders share deployment patterns, ask questions, and show real results from AI-powered revenue operations.
Follow for deep dives. Weekly breakdowns of specific patterns (competitive displacement, account intelligence, pipeline forecasting) all built on top of this architecture.
Follow & Connect: https://www.linkedin.com/in/ryanvanshur/