Migrating a 10K-Token Blog Workflow to a 5-Layer Model Workspace Protocol: Measured Token Wins and Reproducible Architecture

```html

What Was Done

We converted the tech.queenofsandiego.com technical blog workflow from a monolithic context structure to a granular 5-layer Model Workspace Protocol, reducing per-session token overhead from ~10,925 tokens to a target of ~370 tokens—a 29× improvement. This pilot demonstrates how to decompose a complex, always-on knowledge base into discrete layers that load only when needed, without sacrificing writer productivity or output quality.

The work involved:

Measuring baseline token consumption across the existing blog generator and CLAUDE.md files
Designing a layered directory structure that isolates map, context, references, and workflow stages
Building stage-specific context files for research, drafting, and publishing
Validating the new structure against live blog post generation
Documenting the migration playbook for rollout to other workflows

Baseline Analysis: Why Token Waste Mattered

The original setup loaded three components into every session:

Repos-layer CLAUDE.md (~942 tokens): Generic map and rules for all properties
QOS CLAUDE.md (~3,420 tokens): monolithic file mixing Layer-0 navigation, Layer-3 pricing rules, deployment safety constraints, competitor analysis, and business strategy—loaded even for simple research tasks
tech_blog_generator.py (~6,563 tokens): The full Python generator, including utility functions, AWS SDK boilerplate, and state-machine logic rarely touched during ideation or drafting

Analysis showed ~90% of these tokens were overhead for any single post-authoring session. A writer researching a topic needed the voice guide and competitor context, but not deployment safety rules or the generator's internal state-machine schema. Conversely, a publisher deploying to CloudFront needed the generator and safety constraints, but not research references.

Architecture: 5-Layer Decomposition

We restructured the blog workflow under /workspaces/tech-blog/ following this hierarchy:

workspaces/tech-blog/
├── CLAUDE.md                 # Layer 0: Map & routing (~80 tokens)
├── CONTEXT.md                # Layer 1: Router & stage selector
├── reference/
│   └── voice.md              # Tone, vocabulary, target audience
├── 01-topic/
│   └── CONTEXT.md            # Layer 2: Topic ideation context
├── 02-research/
│   └── CONTEXT.md            # Layer 2: Research methodology & sources
├── 03-draft/
│   └── CONTEXT.md            # Layer 2: Draft editing & structure
└── 04-publish/
    └── CONTEXT.md            # Layer 2: Deploy, CDN, monitoring

Layer 0: Map (CLAUDE.md, ~80 tokens)

A minimal index that names each layer and stage, explains the workflow, and points to the appropriate CONTEXT.md. This file is always loaded and is the only persistent knowledge.

Layer 1: Router (CONTEXT.md, root, ~120 tokens)

Declares the four stages as separate directories and explains when to jump to each. The user explicitly navigates to a stage; this layer doesn't auto-load stage-specific context.

Layer 2: Stage-Specific Context (each stage's CONTEXT.md, ~180–200 tokens each)

01-topic/CONTEXT.md: Guidelines for brainstorming, competitor research checklist, SEO keywords for tech.sailjada.com
02-research/CONTEXT.md: Data source validation, citation format, technical depth guidelines, fact-checking rules
03-draft/CONTEXT.md: Structural templates, pacing rules, code example standards, internal linking checklist
04-publish/CONTEXT.md: CloudFront cache invalidation (distribution ID path, not the ID itself), GitHub Pages workflow, monitoring steps

Layer 3: References (reference/voice.md, ~140 tokens)

Voice, tone, and audience definition loaded explicitly when the user enters any stage. This is shared across all four stages and can be loaded once per session by the Layer 1 router.

Layer 4: Artifacts (stage directories, unbounded)

Post-specific notes, drafts, and outputs live in stage subdirectories so they don't pollute the base CLAUDE.md. A 04-publish/results/ subdirectory holds final HTML, CDN cache-key logs, and deployment confirmations.

Technical Implementation Details

File Structure and Ownership

Each stage directory is treated as a mini-workspace. Stage-specific CONTEXT.md files reference shared resources by relative path:

# In 02-research/CONTEXT.md
See ../reference/voice.md for tone guidelines.
Generator reference: ../../../bin/tech_blog_generator.py

This keeps the dependency graph explicit and avoids circular context loads. When a user explicitly navigates to a stage (e.g., cd 02-research && claude), only that stage's CONTEXT.md is loaded as prompt context; the root CONTEXT.md is not.

Stage Context Composition

The 02-research/CONTEXT.md includes:

Link to ../reference/voice.md (loaded once at session start)
Checklist of sources: tech news sites, GitHub trending, AWS re:Invent talks, academic papers
Validation rules: "No single-vendor claims without competing product comparison"
Citation template: "See [title](URL) (accessed YYYY-MM-DD)" to prevent link rot
Depth guidance: "Assume readers know Docker; explain Kubernetes patterns in 2–3 sentences"

Generator Integration

The generator itself (tech_blog_generator.py../../bin/, outside the workspace. The 04-publish/CONTEXT.md explains its invocation without embedding its full source:

To publish:
$ python ../../bin/tech_blog_generator.py \
  --post 03-draft/post_slug.md \
  --output 04-publish/results/ \
  --validate-links \
  --report 04-publish/results/deploy_log.txt

This keeps the generator code out of the context budget while remaining discoverable and auditable.

Infrastructure: CloudFront and GitHub Pages Integration

The 04-publish/CONTEXT.md includes deployment checklist items without exposing credentials:

CloudFront Distribution: The context file lists the distribution ID by name (e.g., "E2K...ABCD for blog.sailjada.com") but never in the file itself—it's retrieved from environment or AWS CLI lookup at deploy time.
Cache Invalidation Path: Posts invalidate /posts/YYYY/MM/slug/* using aws cloud