Agent Operating System
JARVIS - Personal AI Operating System
A personal AI operating system that routes models, tools, missions, approvals, memory, and workspaces through one interface. A Fastify orchestrator and Next.js HUD expose the workflow as an operable product.
01 / Scope
A request is not yet a completed execution.
A personal AI operating system connecting a Fastify orchestrator with a Next.js operator interface. Requests, provider choices, approvals and execution results have different roles instead of being hidden in one chat response.
I built the orchestration backend, modular HUD, workspace and approval surfaces, and quality tooling. The public source linked here is pinned to its March 28, 2026 revision.
02 / Responsibilities
From an execution request to an observable result.
Execution request · code / compute
- Request
Resolve context and provider choice
The route validates the payload and resolves the user, memory context, provider credentials and model preferences. An idempotency key is required.
- Run identity
Reuse an existing run or create one
A run is looked up using the user and idempotency key. The replay branch returns the existing record; otherwise the route creates a run and starts asynchronous work.
- Result
Observe the run through events
New work is accepted separately from completion. The SSE endpoint reports updated, completed or failed run states by observing the stored run.
Keep the record separate from the connection
The inspected SSE handler reads run state and closes on completion, failure or a timeout. The run record and the stream are different objects; the page does not promise automatic event replay or exactly-once execution.
What the design separates.
Separate acceptance from completion
The execution route returns an accepted response for new asynchronous work. The SSE handler separately exposes completion and failure, so an HTTP response need not be mistaken for the final result.
Give repeated requests an identity
The public route contains an existing-run lookup and a replay response keyed by user and idempotency key. This establishes the replay branch in source, not a concurrency or exactly-once guarantee.
Make routing inspectable
Provider choice, attempts and fallback information are included in the execution representation. The relevant source is linked below rather than replaced with a fictional dashboard or successful run.
03 / Review cases
Questions at the boundaries.
Review scenarios, not reported incidents or passing runtime tests.
The same execution request is submitted again
- Mechanism
- The existing-run branch returns the stored run with an idempotent-replay marker.
- What to check
- Inspect the linked route and the user/key lookup. Concurrent requests and persisted uniqueness still require a separate runtime test; none was run for this page.
An approval is rejected or already decided
- Mechanism
- The approval endpoint accepts approved/rejected decisions and reports not-found or already-decided outcomes when the store returns no result.
- What to check
- Read the decision handler separately from execution authorization. Do not infer a universal blocking policy from this one endpoint.
The result stream closes before the operator sees completion
- Mechanism
- The SSE endpoint polls stored run state, closes terminal runs and has a timeout. A separate run-read endpoint is also present.
- What to check
- The source makes a subsequent state read possible; it does not by itself establish automatic frontend reconnection or delivery of every intermediate event.
The implementation scope
JARVIS
Orchestrator Backend
API & Workflow Core
- Missions/councils/executions routes
- Provider routing and policies
- Role-gated approvals and workspaces
HUD Frontend
Operator Interface
- Visual core + modular widgets
- Workspace and approval surfaces
- Mission-focused navigation
Quality Loop
Verification & Dogfood
- OpenAPI-generated client types
- E2E smoke coverage
- Dogfood reports with screenshot evidence
Technology
- TypeScript
- Next.js
- Fastify
- PostgreSQL
- Zod
- Playwright
- React Three Fiber
- SSE
04 / Sources & record
Read the basis of the account.
The execution and approval routes and a regression script were inspected in the public repository. Source inspection is not an end-to-end runtime or security certification.
The links are original public source at e2e2ebf, not a reconstructed implementation. The regression script was read, not executed. No runtime screenshots, successful-run counts or performance results were fabricated.
Public source · pinned revision
Execution request and replay branchPayload validation, user/key lookup and asynchronous run creation.Execution result streamRun reads, terminal events and SSE closure.Approval decision handlerApproval creation and explicit approved/rejected decisions.Regression smoke scriptPrompt profiles and capability expectations; test source, not a passing run.Read the existing technical record
The problem
Needed a single product surface that can route ambiguous user requests into research, code, approval, and automation flows while keeping role gates, streaming state, provider fallback, and workspace execution understandable and operable.
The response
Implemented a Fastify backend with typed route modules, auth/role enforcement, rate limits, SSE streams, provider registry/policies, missions/councils/executions, and workspace PTY endpoints. Built a modular Next.js HUD with a visual core, widget routing, OpenAPI-synced client types, and Playwright-backed dogfood coverage.
Overview
- Solo-built personal AI operating system that combines an orchestration backend with a HUD-style operator interface.
- The system is organized around task routing, approval gates, provider control, workspace execution, and evidence-oriented UI modules.
Backend Surface
Orchestration API
- Fastify route modules for auth, providers, assistant contexts, missions, councils, executions, workspaces, memory, approvals, reports, radar, upgrades, and Jarvis session flows
- Role-gated auth/session handling, rate limiting, raw-body parsing, and error normalization
- SSE/event endpoints for mission, council, execution, assistant, dashboard, and notification updates
Runtime & Policy Controls
- Provider routing policies, credential resolution, registry refresh, and token/health workers
- Workspace runtime endpoints for PTY spawn/write/read and shutdown
- Approval-gated high-risk actions with notification delivery channels
Frontend Surface
HUD Interface
- Next.js app with a modular widget shell (Inbox, Assistant, Council, Workbench, Tasks, Reports, Watchers, Dossier, Notifications, Skills, Approvals, Memory, Settings, Model Control, Ideation)
- Visual core page with deterministic engine controls and scene switching
- Deep-linkable workspace routes for core, studio, mission, tasks, approvals, automations, settings, and reports
Typed Client Integration
- OpenAPI-generated frontend types synced from the backend contract
- Client endpoint layer for typed requests/responses across widgets and workflows
Quality Loop
- Playwright smoke coverage for core visibility, HUD intake autoplay, council traces, session restore, and auth/settings flows
- Dogfood reports with screenshot evidence and issue validation artifacts stored inside the repository
- Public GitHub repository available for direct review of code and verification assets