The Engine Split: Context Window Survival at 84K Tokens

Create-Articles v7.9.1 broke at 84,312 tokens. That figure triggered compaction, the point where a single engine stops being a set of instructions and starts being a crowd of them. No component had failed. Forty-plus stable versions had already proved the pieces worked individually. The defect was total size, and specifically what size does to attention: a model reads the start and the end of a long context most reliably, and the middle least. Rules in the middle get lost with no error to show for it. The largest block, 11,595 tokens of visual reference geometry, was material Create-Articles never modified while writing. It carried the full attention cost of content it only needed to hand onward.

Create-Articles v7.9.1 was the culmination of 32 days of iteration. The engine contained everything needed to produce a publication-ready article: voice rules, 14 SVG templates with exact geometry, AI-SEO schema definitions, three tiers of validation checks, five context files (ICP, company, messaging, offerings, brand voice), three format templates, three golden reference HTML files, and a 7-phase workflow. It was comprehensive. It was also too large.

Every component worked. Forty-plus stable versions proved that. But language models have finite attention. Anthropic’s context engineering guide describes this directly: every token attends to every other token, so as the total grows, pairwise relationships get stretched thin. The guide calls this context rot, the phenomenon where accuracy and recall degrade as token count increases.

Research from Stanford and Meta confirmed the same finding from a different angle. Their “Lost in the Middle” paper (published in TACL 2023) demonstrated that model performance degrades significantly when relevant information sits in the middle of long contexts. Performance follows a U-shaped curve: highest at the beginning and end, lowest in the middle. Dumping 84K tokens of system files into one window meant critical rules were getting lost.

The breaking point was measurable. v7.9.1 at 84,312 tokens triggered compaction. The visual rhythm system alone (SVG templates, category rotation rules, density formulas) consumed 11,595 tokens. Those templates defined exact viewBox dimensions, coordinate geometry, and font calculations that Create-Articles never modified during article generation. They were reference material for a downstream process, sitting in the middle of the context window, degrading everything around them.

The split moved 15,318 tokens out of Create-Articles and into a new engine, Create-Images v2.0.0. Everything that moved shared one property: Create-Articles loaded it but never modified it during generation. That covered 14 SVG templates worth 11,595 tokens, the SVG validation rules PAT-010, PAT-015 and PAT-016, and the image generation routing logic. A 753-token handoff contract took their place and replaced the full image specification. Nothing was deleted in the process. The material moved to the engine that actually uses it, where its full weight loads only when images are being produced. That difference between removing content and relocating it is the entire design. A monolith and a pipeline can hold identical knowledge and perform very differently.

The decision was guided by a question: what does Create-Articles need in context to generate an article? Voice rules, component definitions, schema requirements. SVG coordinate geometry, template viewBox dimensions, and Gemini prompt patterns belong to the image engine. They were consuming context window budget without contributing to article generation.

Anthropic’s context engineering guide describes the principle as finding the smallest possible set of high-signal tokens that maximize the likelihood of the desired outcome. Their recommended pattern is just-in-time context loading: maintain lightweight identifiers (file paths, stored queries) and dynamically load data at runtime rather than pre-loading everything.

That is exactly what the split achieved. Create-Articles retained a slim handoff file that described the VIP block format (what images are needed and where). Create-Images loaded the full template library and validation rules only when processing those VIP blocks. Neither engine carried the other’s weight.

The split produced a three-stage pipeline with one responsibility per stage. Create-Articles, at 69K tokens, generates HTML containing VIP placeholder blocks. Create-Images, at 42K, turns those blocks into SVG diagrams. Create-Compiler, at 10K, merges both outputs, validates integrity across the boundary, and routes defects back to the engine that caused them. Each engine also carries its own context budget and its own version history. That second property is the one that changed how the work proceeds, because an engine can now be improved without loading the rules of the two beside it. Scope came first here. The context budget followed from the scope, rather than the scope being reverse-engineered to fit a token target.

Each engine evolved independently after the split. Create-Articles went from v7.9.2 to v7.9.35, adding content profiles, an absorption gate, messaging framework integration, and source registry memory. Create-Images went from v2.0.0 to v2.0.25, adding visual perception rules, font scaling, text centering formulas, and an 8-check exit gate. Create-Compiler went from v1.0.0 to v1.3.4, adding a 14-check compile validator, a 7-question review agent, a 4-tier issue router, and reverse manifest feedback.

The version numbers tell the real story. Before the split, every improvement to image handling required loading all 84K tokens of article generation rules too. After the split, image template changes (v2.0.3 through v2.0.16 refined arrow spacing, font scaling, and source attribution placement across 14 iterations) happened without touching article generation context. Seven versions of image refinement that would have pushed the monolith well past its breaking point.

Splitting one engine into three converts an internal problem into an interface problem. Inside a monolith every rule can see every other rule, so agreement between them is free. Across a boundary, agreement has to be written down or it does not exist. This is the part of a split that teams underestimate, and it is where the gains from the split get spent when it is done casually. The pipeline here pays that cost deliberately and in one place, rather than letting assumptions accumulate in three separate codebases. The practical result is that a change to one engine's output is a change to a document. The engine downstream finds out by reading it, not by failing during assembly.

Splitting a monolith creates a coordination problem. Three separate engines need to agree on data formats, validation boundaries, and handoff protocols. This is the integration tax: the cost of making independent systems work together. I solved it with 6 documented integration contracts, each stored as a markdown file in a shared directory that all engines can read.

The contracts define three things: what crosses the boundary, in what format, and who validates what. The articles-to-images contract specifies that Create-Articles outputs VIP blocks with data-vip-id attributes, prompt text, and template hints. Create-Images matches those VIP IDs and outputs <figure> elements with the same IDs. The compiler matches VIP blocks to figures by ID during assembly.

The verification manifest contract (inspired by Stripe’s incremental verification pattern) lets each engine embed a machine-readable record of checks performed into its output. Downstream engines trust upstream manifests rather than re-running checks. Create-Articles reports which validation rules passed. Create-Images reports which exit gate checks passed. The Compiler reads both manifests and only runs cross-boundary checks that neither upstream engine could perform alone.

Assembly creates its own defects, so the Compiler became the place to catch them. It began on 5 February 2026 as version 1.0.0, a merge tool that matched VIP blocks to figures and joined the HTML. Merging turned out to produce failures neither upstream engine could see: schema word counts shift once the pieces combine, table-of-contents anchors break when sections move, FAQ schema drifts from the visible text, and CSS class references span both outputs at once. v1.1.0 answered that with a quality gate. Nine deterministic Compile Validator checks run against the final assembled HTML, and a seven-question Review Agent reads only the compiled output, with no access to the generation history. Reading it cold is the point. An engine that produced the text cannot see what it has made familiar.

The real breakthrough came with v1.2.0. The first full-pipeline production run revealed three issues: SVG images left-aligned because centering was applied to hero images only, the footer credited only Create-Articles (missing the other two engines), and a source removal required a manual fix that created drift between source and compiled output. Research into CI/CD patterns, build systems, and quality engineering confirmed that shift-left testing (beginning testing as early as practical in the lifecycle) is the production-grade pattern.

v1.2.0 introduced the Issue Router, a 4-tier classification system that routes every discovered defect back to the source engine:

Issue Router: 4-Tier Classification

Tier 0 (Preventable): Fix the issue and add a rule to the upstream engine so it never recurs. Example: SVG centering rule added to Create-Images validation.

Tier 1 (Auto-Patch): Deterministic fix applied to both source and compiled output. Example: missing target="_blank" on external links.

Tier 2 (Scoped Re-Gen): Fix request routed to Create-Articles for a single section regeneration. Maximum 2 retries.

Tier 3 (Structural): Escalate to the operator. Recommend full pipeline re-run.

v1.3.0 closed the loop with reverse manifests. The Compiler generates a structured manifest that routes Tier 0 and Tier 2 entries back to upstream engines. Create-Articles receives them through Phase 5 and can regenerate a single H2 section (Section-Patch Mode) without re-running the full pipeline. Create-Images receives Tier 0 entries through its Feedback Receiving Protocol and adds or strengthens validation rules.

The system now has guards against infinite loops: an idempotency rule prevents duplicate entries, and an overflow guard stops processing if more than 3 Tier 2 entries target the same article (recommending a full re-run instead). Fix-forward-only, where you fix the compiled output without updating the source, was formally banned as an anti-pattern. It creates the content equivalent of “works on my machine.”

Five principles came out of the split, and each was paid for by a specific failure rather than reasoned out in advance. All five apply to any system where AI agents move structured content through a multi-step pipeline. They were tested across repeated production runs and written into the changelogs, so each has a version number attached to the failure that produced it. The common thread is that reliability came from structure, not from better instructions. Where the system tells a model what to do, results vary. Where the system makes the wrong output impossible, or removes the material that caused the confusion, results hold. Each of the five is a version of that trade, applied at a different level of the pipeline.

1. Context windows are finite resources. Separate what from how.

This is Principle P11, extracted directly from v7.9.2. Create-Articles needed to know what images to place: VIP blocks with prompt descriptions. SVG coordinate geometry, viewBox calculations, and font scaling formulas belong to a different engine. Loading both into the same window meant procedural drawing instructions competed with article content for attention. The split separated declarative intent from procedural execution.

2. Advisory rules get skipped. Make requirements structural.

Principle P04, learned across dozens of versions. The most reliable improvements came from making violations structurally impossible rather than advising against them. When I added STR-022 (SVG Boundary Check) as a BLOCKING gate, articles immediately stopped containing inline SVGs. The advisory note in the workflow that said “prefer VIP blocks” had been ignored for 7 consecutive builds. The structural check that fails on grep -c "<svg" $FILE returning anything above zero has never been bypassed.

3. One example beats 89 lines of instructions.

Principle P03, from the v3.8 disaster. I added an 89-line validation checklist and output quality dropped. Claude got confused by the volume of rules. v5.0 fixed it by showing one completed HTML example (the golden reference). Claude followed the workflow correctly again. The engine split preserved this lesson: each engine has its own golden references and worked examples rather than exhaustive rule lists.

4. System files are training data. They must follow the same rules they enforce.

Principle P13, from v7.9.22. The em dash generation-time rule existed in voice.md, but voice.md itself contained em dashes in its prose. The LLM learned the pattern from the system file it was supposed to use for enforcement. The fix: purge em dashes from all system file prose. Every rule file was audited for self-contradiction. This principle now applies to every system file change: if you ban a pattern, your system files cannot use it.

5. Fix-forward creates drift. Fix at the source.

Principle from v1.2.0. When the Compiler found an issue in the compiled output, the temptation was to fix it in place and move on. But the next compilation would overwrite that fix because the source article still had the original defect. The reverse manifest system (v1.3.0) formalized the alternative: every fix flows back to the source engine. The Compiler generates the fix request, the source engine applies it, and the next compilation produces a clean output without manual intervention.