The hardware

Two GMKTec EVO-X2 machines connected by a Thunderbolt 4-class link, running AMD Strix Halo. Furnace carries a 64 GB GPU frame buffer (reduced from 96 GB on September 5, 2026); Crucible devotes 48 GB of its 64 GB unified memory to the GPU. 112 GB of GPU memory across one platform, split across two brains.

Three machines, four fabrics, one brain

Furnace, Crucible, and Anvil are stitched together with four distinct network paths — a dedicated Thunderbolt 4-class cable for the hot loop, a Thunderbolt bridge for the Mac, Tailscale overlaying everything for secure remote access, and 1 GbE for background LAN traffic. Each link carries different flows and has wildly different latency characteristics.

The software stack

Nexus is an npm workspaces monorepo with four packages. The API server handles external requests, the Worker runs agent cycles and processes jobs, the MCP server exposes tools via the Model Context Protocol, and Core provides shared services used by all three.

Worker modes: The workers run in two postures. Furnace baseline handles agent cycles, event listeners, and urgent jobs on the primary node. Crucible burst handles the long-running LLM work — embeddings, sentiment analysis, photo descriptions — from a persistent bulk worker on Crucible, and the autoscaler adds ephemeral burst runners alongside it when the queue grows, removing them when it drains. Furnace does not autoscale; the burst capacity lives on Crucible.

LLM models

Four resident models, one per job, spread across the three machines. Chat and classification live on Furnace, embeddings are mirrored to Crucible, and vision runs on Anvil next to the photo library. Each model is purpose-matched to its workload.

The service layer

Ten specialized services running alongside the core LLM models. Each handles a specific modality — vision, audio, identity, search — all accessible through Forge's unified API.

👁

Vision Language Model

Photo description, visual QA, OCR

🔬

Embeddings

Semantic search, 4096 dimensions

🎤

Whisper

Speech-to-text transcription

👤

InsightFace

Face detection and recognition

📋

Reranker

Search result reranking

📄

Unlimited OCR 3B

Document text extraction

🔊

Higgs TTS

Text-to-speech · Higgs 3.4B, Kokoro 82M on Crucible

🎧

Voice Diarization

Speaker identification

📊

Sentiment Analysis

LLM-powered sentiment scoring

LLM

🎨

Image Generation

FLUX.1 + Z-Image via sd.cpp (Furnace) · ComfyUI (Crucible) · Wan 2.2 video

Nineteen sources, one graph

Everything a digital life touches flows through the same ingestion pipeline: normalize → deduplicate → store → enrich (sentiment, embeddings, knowledge graph) → proactive rules. Sources run on different cadences — some real-time, some scheduled, some manually imported archives — but they all land in the same PostgreSQL database and are queryable as one dataset.

Each source lands raw in bronze (aurora_raw_* tables) and is normalized into silver unified views, then fans out through the enrichment pipeline: sentiment analysis, 4096-dim embeddings, knowledge graph extraction, and GPS reverse-geocoding where applicable. The proactive engine watches all sources and surfaces significant events to agents via the inbox. Nothing is truly siloed — a photo cluster can cross-reference a trip, which cross-references messages with a person, which cross-references a song played during that week.

One message, end to end

Watch a single iMessage flow through every stage of the system — from arrival to action — in about thirty seconds. This is the same path every piece of incoming data takes.

Meet the agents

The agent cast of the Nexus runtime, each with a distinct role and personality. They coordinate through Muster, the fleet coordination layer, run on configurable schedules, and operate under graduated autonomy levels.

Insight

Analyzes patterns across 40K knowledge facts and personal data

PlatformOps

The operations brain — trend review and incident diagnosis for the whole stack

ProjectManager

Owns the Operator Backlog end to end — triage, lanes, proposals, follow-through

SecurityAnalyst

Read-only reasoner over the security evidence plane — findings explained, work proposed

What the agents are actually doing

Every agent cycle is a complete loop: load state → reason via LLM → pick tool calls → execute → log the outcome. Every cycle ends in a logged decision: what the agent saw, what it reasoned, what it did. Published snapshots of this page can carry one real decision, redacted and walked through step by step, with a sampled feed of recent agent activity underneath. This snapshot ships without one.

Lately

Sampled · sanitized · from the platform snapshot

The MCP connection web

A web of MCP servers connects external services — Gmail, GitHub, Notion, iMessage — into a unified tool catalog that agents discover on demand. The Nexus MCP server alone exposes 282 tools.

Agent architecture

Each agent runs as a short-lived cycle: load soul package, gather state, call Forge, parse actions, execute tools, log decision, under graduated autonomy and approval gates.

## Routine Checks

- Review `project_tracking_candidates` for new
  repo/project candidates, stale pending reviews,
  and candidates with enough evidence to track.
- Review recent `proactive_insights`,
  `agent_evidence_findings`, `agent_tasks`, and
  timeline summaries for stale commitments.
- Produce at most one concise planning summary
  per routine cycle.
- Send ARIA an inbox message only when a plan
  candidate is timely, actionable, and grounded
  in fresh evidence.

<working_memory>
Photo backlog was 3200 last cycle.
Triggered 6 describe batches.
Check reduction next cycle.
Gmail auth token expires in 48h -- monitoring.
</working_memory>

// ARIA checking Forge health via PlatformOps
delegate_task({
  agent_id: "platform-ops",
  prompt: "Is Forge healthy right now?
           Any latency concerns?"
})

The autoscaler

When enrichment backlogs grow, Crucible adds ephemeral burst runners next to its standing bulk worker. Furnace holds the baseline and does not scale. When the queue drains, the burst runners disappear. No orchestrator, no containers — just systemd transient units.

A backlog of 3,200 unembedded photos floods the job queue. Crucible's autoscaler detects the pending jobs and spawns ephemeral burst runners alongside its persistent bulk worker. Workers pull jobs with FOR UPDATE SKIP LOCKED, process them in parallel, and exit when the queue is empty. Furnace keeps the baseline load throughout — the burst capacity lives on Crucible.

Every commit, every repo

Nexus didn't appear out of thin air — it was built on top of months of related work across a constellation of personal repos. Each bar shows unique commits per repo per month across the whole portfolio, deduplicated across the worktrees and scratch clones that share each repo's history. The whole thing is a recent push: 21,497 unique commits across 131 repos between the initial idea and what's running today.

How it happened

What else is running

The sections above are the core. Around it, the platform grew a coordination layer, an operations discipline, and a set of instruments that mostly stay out of sight.