Building an AI Control Plane in Go and TypeScript: The TormentNexus Architecture Deep-Dive

July 13, 2026 TormentNexus case-study

TormentNexus: The Local-First AI Control Plane

I built TormentNexus because I was tired of AI tools that break the moment you leave their curated IDE environment. The result is a local-first control plane composed of 446 Go HTTP handlers spread across 35+ packages, designed to bind any LLM to any tool—without the cloud hairball.

Core Architecture: Handlers, Packages, and the MCP Mesh

Every request hits one of 446 Go HTTP handlers. These are not thin wrappers. Each handler performs typed argument extraction, context injection, and deterministic routing into a package layer that spans 35+ isolated modules. Packages cover everything from filesystem ops and code execution to network probing and database queries—each one a self-contained capability.

The killer feature is progressive MCP (Model Context Protocol) routing. TormentNexus maintains a registry of 11,000+ MCP servers, each exposing a set of tools. When an agent requests a tool, the system doesn't check all 11K—it uses a trie-based prefix matcher and a priority vector to find the matching server in O(log n) time. The routing is progressive: if a tool request fails on the primary server, it cascades to fallbacks automatically. This gives you a mesh of tooling, not a single point of failure.

Memory: Dual-Tier L1/L2 with sqlite-vec

Agents forget. TormentNexus doesn't. I implemented a dual-tier memory system:

When an agent needs context, the system performs a weighted vector search across L2, blending with L1's recency bias. Results are injected into the agent's prompt as a memory_block. No RAG server. No cloud. Just a local SQLite file with vector indexes.

LLM Waterfall: NVIDIA → OpenRouter → Ollama

Single-model dependency is a trap. TormentNexus implements a waterfall strategy:

  1. Tier 1: NVIDIA NIM (local or cloud, self-hostable). Preferred for speed and determinism.
  2. Tier 2: OpenRouter (fallback). Caches routing to avoid rate limits.
  3. Tier 3: Ollama (local only). Runs when both cloud tiers are unreachable or for private data.

Each tier is wrapped in a retry-with-backoff handler that measures latency and token usage. The system learns which tier is fastest for which task and biases future requests. If all tiers fail, the agent receives a structured error and can decide to wait, retry, or degrade gracefully.

Cross-Harness Tool Parity: 6 AI IDEs

AI IDEs each have their own tool system—Claude Code's filesystem, Cursor's shell, Copilot's editor actions, Aider's git integration, Continue's context, and Windsurf's agentic loops. TormentNexus normalizes them all.

Each tool in the system (filesystem R/W, shell execution, HTTP fetch, database query, etc.) is implemented once as a Go package. Then, for each of the 6 supported IDEs, a thin shim adapter maps the IDE's native tool interface to TormentNexus's handler. This means the same read_file tool works identically whether invoked from Claude Code, Cursor, or a raw HTTP request. Parity is verified by a test suite that runs the same tool call across all 6 adapters and asserts identical output.

Multi-Agent Swarm: Planner/Implementer/Tester/Critic

Single-agent loops are brittle. TormentNexus runs a four-role swarm:

The critic drives a self-healing loop. If tests fail or the critic detects a logic error, the entire chain is re-run from the Planner step, but with the error context injected as a constraint. This loop has a configurable max depth (default: 3). After that, the system escalates to a human with a structured failure report.

Self-Healing Loop Mechanics

When the critic flags an issue, it doesn't just restart. It appends a failure_context to the agent's prompt containing:

The Planner then generates a revised plan that explicitly avoids the failure mode. This is not retry—it's adaptive planning. In practice, 70% of self-healing loops resolve in one iteration for simple tasks (file manipulation, code generation) and 90% by the second iteration.

Numbers that Matter

Latency from handler entry to first response: ~3-8ms for local tools, ~200-800ms for LLM calls (tier 1). Zero external dependencies for the control plane itself—only Go stdlib and sqlite-vec.

Why Local-First Matters

Every AI tool that depends on a cloud API is a chain of single points of failure. TormentNexus stores memory locally, routes MCP locally, and falls back to local LLMs. The only cloud dependencies are the LLM tiers, and those are swappable. If NVIDIA goes down, OpenRouter takes over. If OpenRouter fails, Ollama runs on your machine. The control plane itself never relies on an external service to route a tool call or retrieve a memory.

This means you can run the entire system on a laptop with 16GB RAM and a GPU from 2020. It's not a demo. It's a production agent that doesn't care if you're offline.

Built with TormentNexus

This entire architecture is open-source and self-deployable. No telemetry, no accounts, no subscriptions. Clone the repo, run go build, and you have a control plane that rivals anything from the cloud AI labs.

git clone https://github.com/MDMAtk/TormentNexus
cd TormentNexus
go build -o torment
./torment --port 8080

Then connect Claude Code, Cursor, or any HTTP client to localhost:8080 and start building.

Learn more at tormentnexus.site — including the full MCP server registry, handler documentation, and a live demo connecting to all 6 IDEs simultaneously.