Exocortex Presence System

Problem

Personal AI projects usually split into disconnected demos: a chatbot here, a camera feed there, a publishing script somewhere else. Exocortex treats the interface, voice loop, local model routing, data collection, and publish controls as one observable control surface instead of separate toys.

Why it matters

The build is a practical architecture for making a personal agent legible and controllable. It prioritizes local responsiveness, explicit routing, safe action boundaries, visible diagnostics, and a dedicated manifestation plane that can behave like a persistent system presence rather than a tab in a browser.

System description

Exocortex Console owns settings, state, logs, source collectors, publishing controls, voice selection, and operator diagnostics. A subordinate Presence agent runs locally for room interaction: wake phrase handling, microphone and speaker resolution, Piper or Windows SAPI speech output, deterministic command routing, local LLM-assisted conversation, and the Monitor 2 viewport. The viewport renders a live room-derived ASCII signal field with a voice-summoned face state, speaking/listening/thinking modes, and restrained cybernetic visual direction. The source layer collects Spotify, YouTube, and PlayStation activity for review-first public state, while the publishing layer can generate Signal field notes and push scoped Exocortex-owned files to the site.

Operating context

The working repo is a local desktop system, not a standalone novelty assistant. Its architecture is split across a Tauri/React Console app, a Node collector sidecar, shared TypeScript schemas, a Python room Presence agent, and a Next.js website publish target. Current work is focused on making the control plane reliable: voice catalog management, source refresh diagnostics, scoped publishing, command routing, and a room display that feels like Exo becoming visible through signal rather than another dashboard.