-
Notifications
You must be signed in to change notification settings - Fork 0
Home
LifeOS is an open-source attempt to build a personal AI system that is actually useful in everyday life.
The short version is simple: instead of treating AI like a single chat window in the cloud, LifeOS treats it more like a local operating layer for planning, coordination, memory, and automation. The project is built around user control, local-first deployment, modular capabilities, and clear system boundaries.
This wiki is the friendly front door for that work. It is here to help new contributors, curious readers, and future builders understand what LifeOS is trying to become, what already exists in the repo, and what Phase 1 is focused on right now.
LifeOS is centered on the idea of a Personal AI Node: a system that runs on user-controlled hardware and helps with real-life coordination.
That can include things like:
- turning goals into plans and tasks
- keeping durable context about projects, people, and resources
- reacting to events from calendars, devices, and local services
- supporting domain modules such as voice, scheduling, fitness, production, or vision
- staying extensible instead of forcing everything into one giant assistant
The goal is not to build a magical black box. The goal is to build an understandable, modular system that can grow with the user.
Phase 1 is the foundation stage. In this repo, LifeOS is not trying to ship the full long-term network vision yet. It is trying to make the Personal AI Node real enough to reason about, run locally, and extend safely.
Right now, the project is best understood as a docs-first platform with early implementation surfaces. The architecture is ahead of the runtime, on purpose. The repo is being used to define stable concepts, contracts, and boundaries so contributors can build toward the same system instead of a collection of unrelated experiments.
At a high level, the current reference architecture has a few major parts:
- Reasoning interprets requests, produces plans, and coordinates actions.
- The life graph stores durable context such as goals, tasks, relationships, and resources.
- The event bus lets services and modules react to changes without being tightly coupled.
- Modules add domain-specific behavior like calendar planning, voice workflows, fitness support, or lightweight homesteading logic.
- Automation turns events into concrete workflows across the local node.
The intended deployment shape is a local microservice system, usually on one home server, with Docker Compose as the practical default.
Even in the current early code, the design direction is visible:
- modules define metadata, permissions, and a bounded responsibility
- modules subscribe to and emit events instead of hard-wiring direct dependencies
- modules participate in a
planandactloop rather than acting like isolated scripts - profiles such as
minimal,assistant,ambient,multimodal, andproductiondescribe different runtime shapes - degraded behavior is called out explicitly so the system can stay useful when a provider is missing
For example, the current module set includes a voice module, calendar module, fitness module, economics module, homesteading module, and a lightweight vision ingestion module. Those modules already describe their event subscriptions, emissions, and fallback behavior, which is an important part of the platform direction.
One of the most important technical ideas in LifeOS is that the system coordinates through events.
That matters because it keeps the architecture modular. A calendar update, a health change, a device signal, or a voice request can all become events that other parts of the node understand. Instead of one central blob trying to know everything, LifeOS can let specialized parts react to shared signals with cleaner boundaries.
This is also what makes room-aware automation, reminders, voice flows, and cross-module planning fit into the same system model.
The life graph is the durable memory layer for the node. It is where LifeOS can represent the structure of a person's life in a more useful way than a chat transcript.
In practical terms, that means the system can model things like:
- goals and milestones
- tasks and plans
- people and relationships
- resources, inventories, and assets
- events and relevant context over time
That graph-oriented view is important because LifeOS is meant to coordinate ongoing life activity, not just answer one prompt at a time.
The current direction is intentionally practical.
LifeOS is aiming for a local-first system that can run on real hardware, use swappable providers, expose clear contracts, and support bounded autonomy. The project is interested in voice, planning, room awareness, dashboards, simulation, and domain modules, but it is trying to approach those areas with explicit architecture instead of vague product language.
The long-term roadmap still reaches toward richer agent meshes, local AI networks, and broader decentralized collaboration. But those are future phases. Phase 1 is about building a strong local base first.
If you are new here, this repository already provides three useful things:
- a coherent vision for a Personal AI Node
- a growing architecture set for reasoning, events, modules, security, and interfaces
- early package and module contracts that show how the system may be implemented
That makes the repo a good place to understand the system shape before the runtime is fully mature.
- Read the Docs Index
- Read the Vision Overview
- Read the Phase 1 Overview
- Read the Architecture Overview
- Read the Reference Architecture
LifeOS is not just an assistant, and it is not just a smart-home controller.
It is a local-first coordination system for real life: one that combines reasoning, memory, events, and domain modules so software can help with goals, routines, environments, and practical decisions without taking ownership away from the user.