From a tmux pane inside an SEO tool to an autonomous orchestrator: 8 months of building VNX

VNX did not start as a product. It started as a side-effect.

In late August 2025 I was deep inside building my SEO analysis tool, a Dutch SEO engine with 234 extractor fields, built on Crawl4AI 0.7.4 (you will see the result of that work when it launches as a SaaS product later this year). The crawler ran in one terminal. I worked in another. When I hit a wall, I would spin up a third pane to ask Claude something and copy the answer back.

Eight months later that ad-hoc setup has grown into VNX, a publicly released, governance-first orchestration runtime that runs four AI providers in parallel, rotates its own context automatically at 65% capacity, runs dispatches without my approval, and has produced 6,000+ structured receipts on disk across both the SEO-tool and VNX repos.

This post is the honest evolution log. Seven phases, real commit hashes, real dates, and the moments where I realized something needed to change.

Phase 0, August 2025: born inside an SEO tool

Aug 28, 2025, SEOcrawler_v2 commit 095864bf "Initial commit: SEOcrawler V2 - Core Crawler foundation".

The first version of what would become VNX was not orchestration. It was me coordinating things by hand. Two terminals: one running the crawler, one running Claude Code where I would debug the crawler.

After about a week I realized I was copy-pasting too much. Crawler logs from terminal 1 to Claude in terminal 2. Claude's diagnosis from terminal 2 back to my code in terminal 1. Tens of times per day.

So I wrote tmux send-keys glue. One pane could deliver instructions to another. The first version was twenty lines of bash. It worked. That was enough to keep going.

The SEO tool itself, by the way, is still in active development, and will launch as a SaaS product for MKB owners and agency owners later in May 2026. Combination of deterministic SEO checks and AI-powered actionable suggestions. It is not open source. VNX (the orchestration runtime that emerged from building it) is. Two products, two distribution models, both born in the same August 2025 commit.

Phase 1, September 2025: panes with specialized workers

By early September the SEO project had grown enough that one Claude pane was not enough. So I gave each pane a role.

Sept 2-3, 2025, SEOcrawler_v2 commits 2de2c722 "Complete orchestration system P0 implementation" and 3e83168b "P0 Orchestration Implementation & Cleanup".

The pattern was: pane A was "backend" (crawler logic, extractors, database). Pane B was "frontend" (the dashboard I was building alongside). Pane C was "architect" (the one I would ask design questions to). Each pane had its own CLAUDE.md with role-specific context.

This worked surprisingly well for about three weeks. Then it started to break.

The breaks were always the same: a backend task would need a frontend change, and the backend pane could not do it well because its context was wrong. Or the architect pane would propose something the backend already implemented, and neither knew. The role boundaries created blind spots.

Sept 15, 2025, commit 5f02739d "Fix VNX orchestration automatic popup system".

Around the same time I added popup approval. Every dispatch from one pane to another would trigger a popup; I had to type "yes" before the worker pane would execute. This was paranoid. It was also right. I do not regret a single one of those popup confirmations, they caught more than one bad action before it landed.

Phase 2, Late 2025 to early 2026: workers go agnostic

The blind-spot problem from Phase 1 was the trigger for the next big change. By December 2025 I had stopped giving panes specific roles. Instead, every pane became a generic worker that could handle any dispatch.

The receipts ledger and the dispatcher carried the role information per task, not per pane. A "frontend refactor" dispatch carried frontend context in its prompt. The next dispatch on the same pane could be a backend audit with backend context. Same pane, different role each time.

Jan 27, 2026, SEOcrawler_v2 commit 21b97bcc "Production readiness - SSE refactor, VNX orchestration".

By late January the pane count had grown from 2 to 4. T0 (orchestrator) plus three workers T1/T2/T3. The 2x2 tmux grid that you see in current VNX is from this period.

Critically: by the end of Phase 2, the orchestration code was no longer about SEO. It was a generic system that happened to be running inside an SEO project. It was about to want its own home.

Phase 3, February 19, 2026: split into a standalone repo

Feb 19, 2026, vnx-roadmap-autopilot-wt commit de64917 "feat: vnx public baseline (runtime, cli, governance core)".

This was the day I extracted VNX from the SEO tool. The first commit on the new repo is a squashed import of months of work, not a clean greenfield start. The system had already been running in production (inside the SEO tool's repo) since September 2025. Splitting it off was a productization move, not a reset.

Why split it? Two reasons.

First, every time I improved orchestration to fix an SEO-specific problem, the orchestration improvement was generic. The receipts ledger was useful for any AI workflow. The popup-approval pattern was useful for any multi-agent setup. Keeping it embedded in the SEO tool was holding back its reuse, and was muddying the licensing story (the SEO tool is heading to SaaS; the orchestration layer wanted to be open).

Second, and this is the moment I remember most clearly, Anthropic announced Claude Agent Teams around the same time. I read the docs and thought: "this is what I have been building for six months, but with less governance and no receipts." That was a useful jolt. If Anthropic was about to ship a generic version, my version had to be either better or open. I picked both.

I wrote about the comparison shortly after.

Phase 4, February 23-25, 2026: context rotation at 65% (the USP that nobody else has)

This is the phase that put VNX on the map.

Feb 23, 2026, commits 2cdf066 "hooks: add context monitor stop hook and payload probe" and cb96540 "feat: add context rotation handover detector and tmux rotator". Feb 24, 2026, commit 53badbb "docs: add public CONTEXT_ROTATION.md (v2.5)". Feb 25, 2026, commits db74810 "fix(context-rotation): stop agent loop after handover write" and cfbc178 "fix(rotation): latch Stage 1 filename to prevent repeated regeneration".

The problem this fixed: every Claude Code session has a context window. Around 80% capacity, Claude Code's built-in auto-compact engages and rewrites older context, losing fidelity. Even before that, around 65% capacity, output quality starts to drift. Below 65% in my measurements, agent quality scores averaged 0.86 (σ=0.04). Above 65%, the average dropped to 0.78 (σ=0.11).

Manual /clear is unsatisfying because it loses the active task state. Auto-compact is unsatisfying because by the time it fires, drift has already happened.

The fix VNX shipped: automatic context rotation at 65%, with structured handover, before auto-compact engages.

How it works (three-hook pipeline, all open source in hooks/):

1. PreToolUse hook (vnx_context_monitor.sh), fires before every tool call, checks context usage. If >= 65%, returns {"decision":"block","reason":"VNX CONTEXT ROTATION REQUIRED"} and instructs Claude to write a ROTATION-HANDOVER.md document covering completed work, remaining tasks, files modified, and next steps.
2. PostToolUse hook (vnx_handover_detector.sh), detects the handover write and launches the rotator script in the background.
3. Background rotator (vnx_rotate.sh), sends /clear via tmux send-keys, extracts the dispatch ID and skill from the handover, and re-injects a continuation prompt with the handover content into the cleared session.

The threshold of 65% was deliberate. From the inline code comment in hooks/vnx_context_monitor.sh:51:

"Rotating 15 points earlier [than 80%] gives rotation time to write the handover and execute /clear before auto-compact engages."

The result is rotation that happens before drift, with full structured state preserved across the boundary. Zero human intervention. Skill restored on the new side. Dispatch continues.

I wrote about this in detail on Feb 25, the same day the final fix landed, and that post ranked #1 on Google for the relevant queries within weeks. Not because I knew SEO. Because nobody else had solved the problem.

A scale validation post showed the mechanism holding across 10,000+ dispatches with measurable quality improvement on long tasks.

The competitive landscape on this specific feature, as of May 2026:

Only VNX implements all five capabilities. The other four frameworks (CrewAI, LangGraph, Mastra, Claude Squad) implement none of them.

• Automatic detection at 65% context usage, VNX only
• Structured markdown handover, VNX only
• tmux /clear integration, VNX only
• Skill recovery on new session, VNX only
• Zero human intervention, VNX only

This is the only line item in the VNX vs Claude Code comparison doc where the answer is unambiguous. Manual on one side, fully automatic on the other.

📖 Read also: Async Quality Gates: Why AI Agents Don't Get to Decide When They're Done: the governance layer that made the autonomous mode survivable after popup approval was retired.

Phase 5, March 17-18, 2026: full autonomous, popup retired

Mar 17, 2026, SEOcrawler_v2 commit d9ca054d "docs(fp20): harden governance, evidence bar, and start gate for autonomous T0". Mar 18, 2026, commit 66a3b465 "feat(vnx): add autonomous mode section to t0-orchestrator skill".

The popup approval system that I had relied on since September 2025 was retired. Replaced by deterministic governance gates: evidence bar, start gate, automated receipt verification, and a unified supervisor for crash recovery.

This was the scariest week of the eight months. Six months of "I approve every dispatch" became "the system approves dispatches based on a contract I wrote."

The contract that made it safe enough to do:

• Evidence bar, no autonomous action without prior receipts proving the precondition
• Start gate, explicit policy check before each dispatch (file size, scope, blast radius)
• Triple-gate-pass at merge, Codex review + Gemini review + CI green before any merge (see the multi-AI code review data)
• Two-path human approval still available, staging→promote for planned work, popup confirmation for ad-hoc dispatches that fall outside policy

The popup did not disappear. It moved from "every dispatch" to "every dispatch that falls outside the autonomous policy." Most dispatches now pass through autonomously. The exceptions still pop up. That balance is what made it survivable.

Phase 6, March 30, 2026: public release v0.5.0

Mar 30, 2026, commit fc3332b "chore(release): prepare v0.5.0", PR #46 merged.

VNX went public on GitHub as github.com/Vinix24/vnx-orchestration at v0.5.0. Manifesto published, architecture documented, license attached.

The honest framing: I released VNX publicly 13 days after it became autonomous. The public version was already running without my popup approval. That sequence matters, it is not "we built a public toy and then made it autonomous." It is "we ran it autonomously for two weeks ourselves and then released the working version."

By April 11 (commit 8e44ed5), I had bumped to v0.9.0 and added a competitive analysis comparing VNX explicitly with Claude Agent Teams. The positioning that emerged: VNX is not really a competitor, it is a different layer. Agent Teams solves coordination. VNX solves governance and context rotation.

Phase 7, Now: where it is today (and where it is going)

At the time of writing (May 1, 2026):

• Version: v0.10.0, still pre-1.0 by design
• Receipts on disk: 4,666 in the parent SEO-tool repo (SEOcrawler_v2, Aug 2025 onward) + 1,526 in the standalone VNX repo (vnx-roadmap-autopilot-wt, Feb 2026 onward), over 6,000 dispatch receipts total across eight months, plus 28,000+ events and 327,000+ state records
• Providers integrated: Claude (reference), Codex (peer reviewer), Gemini (architecture reviewer), Ollama (experimental)
• Active workflows: 11 AI agents running daily, most without my approval
• Public artifacts: open-source repo (MIT license), audit PDF for the Anthropic OAuth-ban survival, weekly billing-safety burn-in CI

The eight-month evolution that this post traces, from a tmux pane inside my SEO tool to a public, autonomous, context-rotating, governance-first orchestrator, is not finished. The roadmap for May-June 2026 includes:

• Headless context rotation (today's headless workers are single-shot; auto-rotation is interactive only)
• MCP server exposing VNX state to external Claude sessions
• Multi-repository orchestration (currently single-worktree)
• 10+ terminal scale testing (currently tested at 4)
• Subscription-preserving worker lanes, an ephemeral tmux-spawn window per dispatch, ahead of the announced June 15 Anthropic billing change that moves headless claude -p onto paid API credits while interactive Claude Code stays on subscription

Each of those is its own project. The receipts will document them all.

What I would tell my August 2025 self

Three things.

One: Keep the receipts from day one. The first three weeks of VNX existence had no structured receipts; I was reconstructing what happened from chat scrollback. Those three weeks of debugging cost me more than the rest of Phase 0 combined.

Two: Specialized workers were a mistake worth making. If I had skipped to agnostic workers immediately, I would not have learned the blind-spot pattern that drove the next architecture. Some mistakes are fast teachers.

Three: Solve context rotation early, not late. I shipped 65%-rotation in Phase 4, after six months of pain. If I had built it in Phase 1, the cumulative quality of my output would have been measurably higher across the entire first half of the project. Context drift is the silent killer in long sessions, and the fix is not hard once you have hooks.

Anti-claims (because honesty wins)

VNX is pre-1.0. Multi-repository orchestration is untested. 10+ terminals at scale is untested. T0 with non-Claude models is not battle-tested. Headless context rotation is deferred, only interactive sessions get the 65%-handover. Heavy users blow through Pro/Max subscription caps and the cost story changes.

The autonomous mode is autonomous within a contract. T0 cannot write files. Two-path human approval still triggers for off-policy dispatches. "No supervision needed" is a lie. "Less supervision needed for in-policy work" is true. Read the LIMITATIONS doc before you bet your team on it.

Update: June 2026

Since I published this, VNX reached 1.0 code-freeze: still a governance-first control-plane rather than a packaged product, and not yet on PyPI, so the honest framing holds, the claude -p subprocess lane is the proven reference while the interactive lane matures into the default. That default is the real change: Anthropic's June 15 billing move pushes headless claude -p onto paid API credits while interactive Claude Code stays on subscription, so the default Claude worker is now an ephemeral tmux-spawn lane, a fresh interactive window per dispatch instead of the fixed 2x2 grid this post describes. The dispatch lifecycle is also uniform across every lane now, PREPARE assembles one instruction, GOVERN produces a contract report or synthesizes one from git facts, and RECEIPT guarantees a hash-chained, provider-aware NDJSON entry with a lane-side fallback so a subscription session is never silently lost. Feature design moved to a four-architect panel, codex, kimi, deepseek, and opus writing independent plans that I synthesize, and I found my worst lane bug only by dogfooding it: the first task sat idle because the instruction was pasted into the prompt but never submitted, and my readiness check still watched for a "Welcome to Claude" banner that Claude Code v2.1.159 no longer prints.

What is next on this blog

Through May 2026 I am writing seven deep-dive posts on individual VNX components, the receipt ledger, three NDJSON streams, multi-AI review at the merge gate, the unified supervisor, instruction provenance, the dispatch parameter tracker, and a may build log.

I am also launching the SEO tool, that VNX was born inside, as a SaaS product on May 19. Built for MKB owners and agency owners. Combines deterministic SEO checks and AI-powered actionable suggestions. That is its own story.

Eight months. From a tmux pane that copy-pasted to itself, to an autonomous system I trust enough to release publicly and let run while I am asleep, and that knows when to rotate its own brain.

The next eight months will not look like the last. That is the only thing I am sure of.

Read also: Three NDJSON Streams, Zero Corruption, the log-shaped state architecture that emerged from this evolution.

For teams who want a peer-level conversation about their own orchestration setup: I work with engineering teams on production-grade AI architecture.

---

Want to follow along with the build? The VNX repo is open source. Issues, PRs and honest critique welcome. Or connect on LinkedIn for the weekly updates.

---

Sources & references

1. VNX Orchestration repo
2. VNX Architecture manifesto
3. VNX Limitations / Anti-claims
4. VNX Context Rotation system documentation
5. VNX vs Claude Code comparison
6. Claude Code Agent Teams documentation
7. Internal data: SEOcrawler_v2 git history (Aug 28, 2025, present, 4,666 receipts in t0_receipts.ndjson), vnx-roadmap-autopilot-wt git history (Feb 19, 2026, present, 1,526 receipts in t0_receipts.ndjson), HEAD f3194b3 (Apr 30, 2026). Plus 28,000+ events and 327,000+ state-stream records across both repos.