01 / Selected work

Synapse

AIInfrastructureAutomation

An AI interaction system I designed, built and operate — connecting conversation to tools, media and real execution.

I conceived Synapse to make local AI useful across conversation, knowledge and execution. V2 composes specialized services and independently served models, with durable state for work that outlives a single exchange.

My role
Concept, architecture, integration & operation
Context
Active personal system
System
Local AI · services · durable tasks

What works today

Synapse is an active personal system, not a public hosted product. Capability coverage and availability depend on the interface and provider.

  • Interfaces and voice: Telegram, Web, Voice and ESP32 connect to the system. They have different capabilities and permissions; voice uses dedicated speech services.
  • Specialized services: Home Assistant, Media / Reading, Archivist, Context Observer, Observability and Watch retain their own execution boundaries. Primary can call supported services directly.
  • Content and knowledge: Content preserves original attachments and derived representations. Archivist provides source-backed answers; image perception is configured for the owner's Telegram interface, subject to provider availability.
  • Durable tasks: Task / DSH handles work with its own lifecycle. Persistent state supports progress, cancellation and recovery without automatically replaying uncertain external actions.
  • Research and development: Task / DSH composes tools for investigation, coding and specialized compute. Remote changes and preview publication depend on the task's approved resources and permissions.

What I designed and built

I designed the interaction and architecture, built the orchestration and integrations, and deployed the system across dedicated hosts.

V2 separates interfaces, decision and orchestration, intelligence and capabilities, and specialized services. Interaction Decision interprets the request. Primary can respond, call a specialized service directly, or delegate work with its own lifecycle to Task / DSH.

LLM Fabric routes model requests and provides inference access. Intent, workflow and permission decisions remain with Interaction Decision, Primary and the service owners.

Interfaces
Telegram · Web · Voice · ESP32
Decision & orchestration
Interaction Decision · Primary · Task / DSH
Intelligence & capabilities
LLM Fabric · Speech · Vision · Content / Knowledge · Tools
Specialized services
Home Assistant · Media / Reading · Archivist · Context Observer · Observability · Watch
Capabilities vary by interface. Primary can call a service directly or delegate durable work to Task / DSH. Fabric routes inference; services keep their own execution.

Specialized local compute

The compute roles match the architecture on the home page:

  • ia01 — primary text: ASUS GX10, DGX Spark-class, with NVIDIA GB10 unified memory. Qwen 3.8 Flash Next runs on vLLM as a single-node provider.
  • ia02 — vision: a second ASUS GX10 / NVIDIA GB10 serves Nemotron 3.5 Super VL through vLLM as a separate vision provider.
  • ms03 — speech: MS-02 Ultra with NVIDIA RTX PRO 4000 Blackwell SFF. Speech Plane uses Parakeet and Whisper for ASR, Kyutai for speech, and TitaNet for standard diarization, with NeMo, CTranslate2 and Moshi serving these roles. Realtime voice has its own speech service.
  • Workstation — on demand: NVIDIA RTX 5090 32 GB, with Qwen 3.8 · 27B configured through NInfer. This optional provider supports specialized compute and experiments when available.

Media with provenance

The voice path uses dedicated speech services on ms03, independently of the optional workstation. Speech Plane handles transcription, synthesis and diarization; the realtime voice service handles live speech interaction.

Content keeps original attachments and their derived evidence. The configured image path connects Telegram and Content to Nemotron VL through Fabric, producing observations for Interaction Decision. Existing Media / Reading workflows keep their own execution; identifying a title does not authorize an acquisition.

This image-perception activation is limited to the owner's Telegram interface. Web, Voice and ESP32 retain their own capability coverage. Image observations support a decision; actions still require explicit permissions.

Control and reliability

Durable task and service state support recovery across interruptions. Recovery preserves recorded progress and reconciles uncertain external effects. Separate services and isolated workspaces complement explicit permissions and human approvals.

At verification, ia02 answered direct health and model checks, but Fabric reported the vision provider unavailable. The optional workstation provider was also offline. Availability is checked per provider.

Realtime voice is deployed and audible output has been exercised. Transcription accuracy, acoustic echo handling, full-duplex and barge-in remain under validation. Visual identification can still be wrong; neither a model observation nor a successful health check proves end-to-end reliability.