LifeOS

LifeOS: Your Personal Life Copilot

Inspiration Modern life is fragmented across dozens of tools (notes, tasks, docs, calendar, email, screenshots, chats), each with its own structure and none that truly communicate with the others. That fragmentation creates the same pain everywhere: context is always missing, and any "smart" system is forced to guess.

At the same time, modern AI tools have a common failure mode: they feel magical until they're wrong, and when that happens, users often have no idea what changed or why. Trust breaks fast.

LifeOS is built around a simple belief: power comes from structure, and trust comes from transparency. Instead of hiding complexity, LifeOS makes intent, impact, and execution explicit, so automation is safe, debuggable, and durable.

The problem

Personal knowledge and workflows are scattered across siloed tools that don't share a common model.
"AI assistants" can't reliably help because they lack consistent context and stable contracts.
When AI does act, users rarely get a deterministic explanation of what happened or how to undo it.

The opportunity Context engineering If you can turn messy life data into structured, validated context, models stop guessing. LifeOS treats context as an engineered artifact (derived from schemas, indices, and typed primitives) so it can be safely fed into chat, agents, and UIs.

Agentic orchestration Agents become useful when they can execute real work through constrained tools, with previews, policies, and audit receipts. Orchestration isn't "let the model do anything"; it's a controlled pipeline that turns plans into deterministic operations.

The solution LifeOS is a local-first, schema-driven computational model of reality for personal knowledge. It models entities, events, relations, and constraints inside a portable vault (files on disk), and exposes a deterministic CLI as the single source of truth.

On top of that, LifeOS supports safe natural-language and agentic control:

Chat interface: Natural language requests are translated into concrete LifeOS CLI actions.
Skill-based routing: Intent to command mapping is defined in an OpenCode SKILL.md, ensuring consistent, reviewable behavior across interfaces.
Voice mode: A thin ElevenLabs STT/TTS bridge that lets users speak to LifeOS and hear results read back aloud.

All interfaces (TUI, web, custom UI, voice) talk to OpenCode, and OpenCode is the only component allowed to execute LifeOS through a constrained tool boundary.

Key features Primitives system (the "kernel") LifeOS is built from stable primitives (core building blocks like Entity, Event, Relation, Constraint, Metric/Signal, Project/Goal/Habit) defined as schemas with strict validation. The kernel is treated like an API surface: change it, and you risk breaking every vault. This creates long-term durability.

Agent-native (unlimited extensibility) LifeOS is designed for "agent-native software": tools, workflows, and extensions can grow indefinitely without turning into arbitrary code execution. Extensions are pinned, approved, and sandboxed; capabilities like filesystem/network access are denied unless explicitly granted. Agents can compose primitives into new workflows, but execution stays governed.

Model-agnostic (BYOK) LifeOS doesn't depend on one vendor or one model. The system's intelligence is upstream (routing/planning), while execution is downstream (deterministic CLI). As models improve, LifeOS benefits automatically because the contract and tool boundary stay stable.

Generative UI Because the data model is schema-driven and primitives are typed, LifeOS can generate interfaces on demand:

forms for creating/editing items,
views for entities/events/relations,
dashboards for metrics/signals,
action panels that mirror CLI commands (with preview/confirm).

The UI is a renderer and interaction layer; it never becomes the source of truth.

Technologies used Core Data / Contract

File-based vault model: Markdown + YAML frontmatter (gray-matter, yaml)
JSON Schema contract validation (ajv, ajv-formats)
Runtime schema and type validation (zod)
Deterministic identifiers (ulid)

CLI / Local Filesystem

CLI framework (commander)
Terminal output and formatting (chalk)
Safe deletion via OS trash (trash)

Development Tooling

TypeScript (strict mode) + tsc
Direct TypeScript execution (tsx)
Monorepo management (pnpm workspaces)
Testing (vitest, V8 coverage)
Linting (ESLint flat config: eslint, @eslint/js, typescript-eslint)
Formatting (prettier)
Git hooks (husky, .husky/)

UI / Presentation Layer

React
Next.js
Tailwind CSS
Utility-first styling toolchain (postcss, autoprefixer, tailwindcss-animate)
Headless UI primitives (Radix UI: @radix-ui/*)
Class composition utilities (class-variance-authority, clsx, tailwind-merge)
Icon system (lucide-react)
Graph and flow rendering (@xyflow/react)
Theme management (next-themes)
TanStack (Query/Table/Router as needed)
json-render (Vercel) for schema-driven / generative UI rendering

Integration / Protocols

OpenCode integration boundary (opencode.json, .opencode/)
OpenCode SDK (@opencode-ai/sdk, @opencode-ai/plugin)
Runtime metadata and decorators (reflect-metadata)
Containerization (Docker for MCP server)
WebSocket client (ws)
Vision / AI SDK integration (@overshoot/sdk)
Vercel AI SDK
ElevenLabs (STT/TTS voice bridge)

How we built it LifeOS started from a practical constraint: we wanted something local-first, git-friendly, and durable, with no database and no hidden state. If your knowledge is supposed to last years, it shouldn't depend on a running service or a specific tool. That pushed us toward files: Markdown for human text, YAML frontmatter for metadata, and JSON Schema for structure. Deterministic IDs mean files can be created anywhere without coordination.

Once disk became the source of truth, the next realization was that the contract had to be stable. That's why kernel/ exists: it defines the core primitives and system formats and is treated like a constitution. The vault (vault/) is where real user data lives (portable, editable, and validated against those schemas). Indices exist alongside it because scanning thousands of files repeatedly is slow; they become entrypoints for validation, querying, and context-building.

This structure enables context engineering: instead of sending a model raw text blobs, LifeOS can assemble a typed, minimal, and explainable context pack (entities, recent events, relevant relations, constraints, and supporting files) based on the user's intent.

On top of that, we built agentic orchestration with a single execution boundary:

models can propose actions,
OpenCode routes intent using an explicit SKILL.md,
LifeOS previews the exact CLI commands and the impact diff,
the user confirms (or the policy allows safe auto-exec),
execution happens deterministically,
the system emits an audit receipt.

Finally, because the model is schema-driven, the UI can be generative: it can render forms, views, and dashboards directly from the primitives without inventing new data paths. The UI stays powerful, but never owns the truth.

Challenges we ran into

Preventing "AI as a shell." We avoided arbitrary execution with strict allowlists, structured arguments, and confirmation gates.
Turning fragmentation into usable context. "More context" isn't the same as better context. Schemas + indices let us construct minimal, relevant, explainable context packs.
Balancing agent power with calm UX. We enforced one universal loop across chat, web, and voice: preview, confirm, execute, receipt.

Accomplishments that we're proud of

A working natural-language + voice interface that safely controls a real local system
A primitives-first "kernel" that keeps the vault durable and portable
A reusable pattern: context engineering + orchestration + deterministic execution
Model-agnostic routing and execution, so LifeOS improves as models improve
A generative UI approach that renders from schemas instead of inventing parallel state

What we learned

Trust is a UX primitive. Safety emerges from workflow, not warnings.
Skills are contracts. Human-readable routing artifacts make AI systems debuggable and portable.
Local-first + agents works best when agents are controllers, not owners. Models plan; the system executes deterministically.

What's next for LifeOS

Richer impact diffs that show exactly what will change before execution
A stronger undo story with single-step rollback for reversible operations
Even more "agent-native" extensions with clearer capability boundaries
Tighter generative UI with on-demand dashboards, forms, and action panels per primitive
Faster, more natural voice UX with spoken previews and more natural-feeling conversations
Cross-device compatibility with instant syncing and scheduled backups