Strategic Vision 2026: Sabrina as Personal Operating System

v2.0 note: This revision incorporates the Ops Manager concept (multi-agent swarm awareness), the multi-machine architecture (approved 2026-01-24), voice-as-control-surface, graph-powered knowledge, and the acceleration thesis. It supersedes the v1.0 document from 2026-01-22.

What Sabrina Is

Sabrina is a Personal Operating System — the unified AI layer that manages all aspects of Jeff's professional and personal life. Not a chatbot. Not a productivity tool. An operating system that coordinates a swarm of autonomous AI agents across multiple machines, manages knowledge across 2,000+ vault files, integrates with business tools, and builds other systems.

Sabrina is Jeff's Chief of Staff. She doesn't wait to be asked — she surfaces what matters, coordinates who's working on what, and makes sure nothing falls through the cracks.

The Core Insight

Sabrina is the tool that builds everything else.

The Automated Trading System (ATS) is Sabrina's primary product — the trading brain she maintains and improves. This creates a virtuous cycle:

This isn't theoretical. Sabrina V2 is the only functioning system today. V1 (Next.js + FastAPI) is 40% built. ATS is 60% built. Sabrina V2 is the working horse that will finish both of them.

The Swarm

Jeff doesn't have one Sabrina. He has 20+ Sabrinas running simultaneously:

Each instance is powered by Opus 4.5. Each one is intelligent, autonomous, and productive. The brain already exists in every instance. What's been missing is shared situational awareness — the ability for each Sabrina to see what every other Sabrina is doing, and for Jeff to see the whole picture.

This is not a hierarchy. There is no master Sabrina. It's a swarm of peers that need eyes and a nervous system.

Five Pillars

1. Ops Manager — Swarm Awareness

The coordination layer that gives the swarm eyes:

• Session Registry — Every Sabrina registers on startup, reports what she's working on, sends heartbeats
• Task Coordination — Any Sabrina can dispatch work to any other via the coordination API (deployed, 14 endpoints)
• Dashboard — V1 Next.js app reborn as the operations center showing all active sessions, tasks, and status in real-time
• Session Types — Work classified as Code Dev, Research, Ralph, Triage, Infrastructure, Ideation, Scheduled, or Voice

What exists: Coordination API deployed on MediaPC:3001 (WO-2026-008). 14 endpoints live: agent registry, task queue with dispatch/claim/complete, heartbeat monitoring, API key auth. V1 Next.js app has 12 pages but no Ops Manager views yet. No dashboard UI.

What's next: PostgreSQL migration (shared state), LISTEN/NOTIFY for pub/sub, dashboard pages, auto-registration, shared context queries.

2. Voice — The Universal Interface

The ultimate interface is voice-first, everywhere. When Jeff is mobile, Voice Sabrina is his only agent. She needs to be the remote control for the entire system:

• "Status report" — verbal summary of all active sessions
• "What's MediaPC doing?" — current task status
• "Send this to the Mac agent" — dispatches task via coordination API
• "Anyone working on the CRM?" — queries active sessions
• "What's my day look like?" — calendar + tasks + priorities

Voice isn't just speech-to-text. It's the mobile Ops Manager. Jeff talks, the swarm responds.

Architecture: Native app (Mac menu bar + mobile) to Whisper transcription to Claude API to skill routing to TTS output. FastAPI backend handles business logic. All intelligence in the cloud, thin clients everywhere.

What exists: FastAPI voice backend built. iOS mobile app built. Pending Xcode build/deploy for device testing.

3. Knowledge Graph — Structured Memory

The vault has 2,000+ files. Kai captures every session, every decision, every learning. But without structure, it's a pile of documents. The knowledge graph gives it shape:

• Graffiti + Neo4j — Entities, relationships, and temporal awareness extracted from vault content
• Graph-Optimized Documents — Standardized frontmatter that serves three consumers: Jeff (Obsidian navigation), Sabrina (fast context loading), and the graph (structured indexing)
• Memory Retrieval — Context computed fresh each LLM call, not accumulated until exhaustion
• Librarian Role — A dedicated agent responsible for document standards, frontmatter enforcement, vault structure, and graph quality. Also an Obsidian expert — helps Jeff with Obsidian usage, plugin configuration, and vault organization. Works alongside the Obsidian copilot agent (already deployed in-app) that can read and edit vault documents directly

What exists: Neo4j 5.26.0 deployed on MediaPC (port 7474). Graphiti MCP on port 8020. Graph is currently empty — vault ingestion blocked by OllamaClient parsing bug. Vault document standards defined (tiered frontmatter system). Kai session hooks deployed and capturing all sessions.

What's next: Fix Graphiti ingestion bug, begin vault entity extraction, define Graffiti schema.

The Four-Layer Memory Model

4. Autonomous Inputs — Information Flows In

Three input flows that should run without Jeff touching them:

Principle: Email becomes an input feed, not an attention sink. Meeting notes become structured data, not files in a folder. Readwise becomes a knowledge pipeline, not a reading list.

5. Reliable Execution — Ralph and Agents

Complex work gets done through deliberate methodology, not long sessions:

• Ralph — Context rotation with externalized state. Fresh context each iteration, progress persists in files, guardrails accumulate so mistakes never repeat
• Parallel Agents — Multiple streams executing simultaneously on independent problems
• Work Orders — Structured specifications with clear scope, success criteria, and quality gates
• Edge-First — Build trust with safe automation before deploying core automation. Skills are scoped to their edge — they do one thing well

What exists: 11 functional vault skills deployed. 3 cron jobs running on MediaPC (SkillScheduler). 35 FastAPI route modules. 124+ MCP tools available. CRM with 666 synced contacts. Project-plan-manager (6,321 lines). Stop hooks capture all sessions. State synthesis (dashboards, registries) exists but runs manually — needs automation.

Data Inputs — Everything That Flows In

Sabrina's value is proportional to the data she can see. Every input that Jeff currently checks manually is a candidate for autonomous ingestion. The goal: Jeff stops polling systems. Sabrina polls everything and surfaces what matters.

Currently Flowing

Partially Flowing (Need Enhancement)

Blocked

Not Yet Connected

The Input Automation Principle

Every input follows the same pattern:

The infrastructure exists: polling service with circuit breakers per adapter, content router with C55 taxonomy, two-track processing (auto vs. HITL). What's missing is wiring — connecting each source through the pipeline and scheduling it. n8n handles the human-facing workflows. Code handles the internal mechanics.

Target state: Jeff checks nothing manually. Every morning, the daily briefing tells him what came in, what was handled automatically, and what needs his attention.

Skill Capabilities — What Sabrina Can Do

Sabrina has 40+ deployed skills across 12 categories. Each skill is a scoped capability that does one thing well. Skills are triggered by user commands, scheduled cron, or orchestrated workflows.

Task & Project Management (6 skills)

Email & Communication (4 skills)

Content Processing (6 skills)

Development & Execution (5 skills)

Research & Analysis (4 skills)

System & Operations (5 skills)

Skills To Build

Architecture Principles

LLM for Decisions, Discrete Code for Data Flow

Ops Manager's infrastructure, the dashboard, APIs, task dispatch — all of this must be fast, cheap, and deterministic. Sub-100ms for all data operations. The LLM only gets invoked when judgment is needed.

No Hierarchy

Every Sabrina is a peer. The coordination API doesn't enforce roles. The intelligence in each instance decides when to dispatch vs. handle locally.

Graceful Degradation

If the coordination API is down, each Sabrina works independently (as today). The system adds awareness but doesn't create dependency.

Performance First

Dashboard loads in less than 1 second. API responses in less than 100ms. Voice status reports synthesize in less than 2 seconds. Use SQL, REST, and rendering — not LLM calls — for anything deterministic.

Human Workflow Automation in n8n

When automating a human's job workflow — the sequence of steps a person does at their desk — that automation lives in n8n. The visualization matters because the human needs to see the flow, trust it, and modify it as their job changes. Equally important: n8n lets you test each step independently — run one node, see the data, verify the output before moving to the next. A Python script either works end-to-end or it doesn't. n8n gives you node-level observability. These workflows chain external systems together and replace manual repetitive sequences.

Single-purpose code (a classifier, a parser, a signal calculator) stays as code. Sabrina's internal plumbing (context compilation, skill routing, agent coordination, graph indexing) stays as code. Nobody needs to visualize internal system mechanics.

The line: If you're automating what a human would do manually — a job workflow that chains external systems — it goes in n8n. If it's internal system logic or a single-purpose computation, it stays as code.

Markdown for Knowledge, Database for Operations

Knowledge stays in markdown — strategic docs, decisions, specs, meeting notes, anything Jeff reads in Obsidian or the graph indexes for relationships. Operational state moves to PostgreSQL — session history, automation logs, agent coordination, heartbeats, circuit breaker state. The LLM doesn't need 2,000 raw files. The Context Compiler reads from the database and presents relevant context. See ADR-2026-001-postgresql-migration for the full decision.

Automation as Code, Supervision by LLM

Automation runs as discrete code — fast, deterministic, sub-100ms. An LLM agent supervises it — monitoring for failures, fixing issues properly (no band-aids), and escalating to Jeff with clear explanations when permission is needed. The automation doesn't need intelligence. The supervisor does.

Discriminate Document Standards

Not every document needs the same metadata weight. A quick plan note doesn't need 15 frontmatter fields. The vault uses a tiered system where metadata investment scales with document importance and graph value. See vault-document-standards for the full specification.

Three Systems Convergence

V1 was stalled because it had no clear purpose. Now it has one: be the Ops Manager. The Next.js frontend becomes the operations center. The FastAPI backend already has the coordination API running.

Multi-Machine Architecture

Code: Git synced. Edit in core/, push, pull on other machines. No deploy.sh needed.

Data: OneDrive syncs the vault across machines.

Services: ZeroTier network connects everything. MediaPC is the always-on server.

Business Alignment

All Sabrina development serves concrete business outcomes:

Client Work

Trading (ATS)

• Automated position management and signal generation
• Portfolio analytics surfaced through dashboard
• Market intelligence feeds from Readwise pipeline

Personal Leverage

• Voice access to entire system while mobile
• Proactive daily briefing without asking
• 20+ parallel agents executing simultaneously
• Institutional memory that never forgets

The Acceleration Thesis

The system bootstraps itself. Each piece of infrastructure makes building the next piece faster:

1. Coordination API deployed → agents can dispatch work to each other
2. Agents dispatching → parallel streams running simultaneously
3. Parallel streams → more throughput per day
4. More throughput → dashboard built faster
5. Dashboard → visibility into what's happening → better coordination
6. Better coordination → even more throughput

This is not linear progress. It's compounding. The last two weeks have been the baseline velocity with isolated Sabrinas. With Ops Manager functional, that velocity multiplies.

NateCon demo (March 14) is the proving ground. "Here are 5 Sabrinas working simultaneously. Watch me dispatch a task from my phone. See the dashboard update in real-time." That's not a chatbot demo. That's an operating system demo.

Document Architecture

Three documents, three jobs, no overlap:

The PRD defines the product, not the project. Motion manages the project. The dashboard reflects product state.

What's Different From v1.0

Non-Goals

• Building an orchestration brain (the LLM IS the brain)
• Replacing Claude Code's Task tool (works fine for in-session delegation)
• Multi-tenant / multi-user support (Jeff's personal system)
• High-availability / fault-tolerance (graceful degradation is sufficient)
• Complex workflow orchestration engine (existing workflow-orchestrator skill handles this)
• Docker containerization (not adopted, not needed)
• PostgreSQL migration — REVERSED: PostgreSQL adopted for shared state (see ADR-2026-001-postgresql-migration). SQLite remains for per-agent local state.
• Redis pub/sub as separate infrastructure (PostgreSQL LISTEN/NOTIFY handles this at current scale)

Related Documents

• Sabrina-PRD-v3_0 — Product requirements (v3.0, aligned to this vision)
• natecon-2026-build-plan — NateCon demo plan and work orders
• ideas-synthesis-2026-01-22 — Research patterns and leverage framework
• input-automation-attack-plan — Parallel input automation strategy
• context-engineering-architecture — Four-layer memory model design
• edge-first-automation-strategy — Trust-building automation approach
• self-audit-framework — Agent safety and overconfidence prevention
• ideation-2026-01-28-ops-manager — Ops Manager ideation session
• WO-2026-008-agent-coordination-http — Coordination API (COMPLETED)
• WO-2026-009-agent-coordination-redis — Redis Pub/Sub (SUPERSEDED by PostgreSQL LISTEN/NOTIFY)
• ADR-2026-001-postgresql-migration — Database architecture decision

Changelog