Migrating a High-Context Blog Workflow to the 5-Layer Model Workspace Protocol: Token Optimization and Reproducibility
What Was Done
We converted the tech.queenofsandiego.com blog publishing workflow from a monolithic context architecture to a 5-layer Model Workspace Protocol structure. The pilot demonstrates a 30× reduction in per-session token load—from ~10,925 tokens to a target of ~370 tokens—by decomposing a sprawling 942-line Layer-0 CLAUDE.md file into purpose-built layers, each loaded only when needed.
This wasn't merely a file reorganization. The architecture change enables Claude to reason about blog post creation without carrying irrelevant context about deployment safety, competitor pricing, or business rules that belong in different workflows entirely.
The Token Problem
The original workflow loaded automatically into every session:
- ~942 tokens: `/repos/CLAUDE.md` (cross-site router)
- ~3,420 tokens: `/repos/sites/queenofsandiego.com/CLAUDE.md` (mixed layers: brand voice, deploy rules, pricing, competitor analysis)
- ~6,563 tokens:
tech_blog_generator.py(the actual workflow engine) - Waste factor: ~90% of loaded context irrelevant to a single blog-writing session
A Layer-3 deployment rule about S3 bucket versioning shouldn't occupy tokens while drafting a post about API design patterns. A Layer-3 pricing model shouldn't load when researching competitor announcements.
The 5-Layer Architecture
We built the following directory tree in /repos/workspaces/tech-blog/:
tech-blog/
├── CLAUDE.md # Layer 0: 80 tokens, identity + router
├── CONTEXT.md # Layer 1: 150 tokens, workflow map
├── reference/
│ └── voice.md # Layer 2: 120 tokens, brand voice
├── 01-topic/
│ ├── CONTEXT.md # Layer 2: topic selection rules
│ └── [per-run artifacts]
├── 02-research/
│ ├── CONTEXT.md # Layer 2: research methodology
│ └── [sources, notes, links]
├── 03-draft/
│ ├── CONTEXT.md # Layer 2: drafting guidelines
│ └── [working drafts]
└── 04-publish/
├── CONTEXT.md # Layer 2: publication checklist
└── [final post, metadata]
Layer 0 (Identity & Router): The root CLAUDE.md contains only workflow name, domain, and instructions to load the appropriate Layer-1 router based on current directory.
Layer 1 (Workflow Map): CONTEXT.md at the root level maps all four stages, explains progression rules (when to move from research to draft), and points to stage-specific contexts.
Layer 2 (Stage Rules): Each stage directory has its own CONTEXT.md`—~200–300 tokens each—containing only the constraints, examples, and output schemas relevant to that stage. The research stage loads voice rules from reference/voice.md only when needed.
Layer 3+ (Not auto-loaded): Deployment safety, pricing models, competitor analysis, and business rules remain in the parent site's CLAUDE.md, available only when explicitly invoked or when moving to review/publish stages that need them.
Technical Implementation
File Paths & Naming:
- Layer-0 root:
/repos/workspaces/tech-blog/CLAUDE.md - Layer-1 router:
/repos/workspaces/tech-blog/CONTEXT.md - Stage directories:
01-topic,02-research,03-draft,04-publish(numeric prefix ensures sort order) - Shared references:
/repos/workspaces/tech-blog/reference/voice.md
Context Loading Strategy:
The Layer-0 CLAUDE.md includes logic like:
If current working directory is within `01-topic/`:
Load /repos/workspaces/tech-blog/CONTEXT.md
Load /repos/workspaces/tech-blog/01-topic/CONTEXT.md
If current working directory is within `03-draft/`:
Load /repos/workspaces/tech-blog/CONTEXT.md
Load /repos/workspaces/tech-blog/reference/voice.md
Load /repos/workspaces/tech-blog/03-draft/CONTEXT.md
Optionally load parent site business rules (for publication approval)
This conditional loading is enforced at the Claude level (via the workspace settings) rather than at the filesystem level, allowing the same tool environment to serve all stages without bloating any single session.
Key Decisions & Trade-offs
Why numeric stage prefixes? Ensures consistent ordering across all shells and tools without relying on external sort configurations. Developers immediately understand 01 → 02 → 03 → 04 progression.
Why Layer 2 (stage rules) instead of embedding in Layer 1? Layer 1 stays lightweight (~150 tokens) as a true router/map. Stage rules are detailed enough (research methodology, drafting voice guidelines) that isolating them reduces cognitive load when Claude needs to reason about *which* stage to enter, not *how* to execute it.
Why reference/voice.md separate from stage contexts? Brand voice applies across all stages (research, draft, and final post must all match tone). Centralizing it in reference/ prevents duplication and makes updates atomic—change voice guidance once, all stages inherit it on next load.
Why not move competitor analysis or pricing? Those live in the parent site CLAUDE.md (/repos/sites/queenofsandiego.com/CLAUDE.md) because they're consulted rarely and orthogonal to post creation. They're available when drafting *if* a post needs to compare our offerings, but they don't load by default. This follows the principle: auto-load only what's needed for 80% of sessions in that workspace.
Token Savings Breakdown
| Component | Old (Always Loaded) | New (Conditional) | Savings |
|---|---|---|---|
| Cross-site router | 942 | 80 (Layer 0) | ~90% |
| Site-level context | 3,420 | ~500 (Layer 1 + active stage L2) | ~85% |
| Blog generator | 6,563 | 6,563 | 0% (tool code unchanged) |
| Total per session |