OpenLife

The open-source runtime where AI agents keep working beyond the prompt.

Give OpenLife a mission. It preserves project context and memory, coordinates agents, continues execution in the background, and lets you follow the work from your terminal or Telegram.

Built for founders shipping AI products.

Website · Get started · Commands · Architecture · Manifesto

From intent to continuous execution

Most AI tools are built around a session:

Prompt → Response → Session ends

OpenLife is built around a mission:

Intent → Mission → Context → Agents → Execution → Evidence → Next action
                         ↕
                  Persistent memory

A mission can begin in the terminal, continue through a background daemon, survive restarts, use specialized agents and skills, and remain observable through local commands or Telegram.

Work should not die when the prompt ends.

OpenLife calls this category an Autonomous Work Runtime: the infrastructure between human intent and persistent agent execution.

A mission in 30 seconds

Run a one-time task:

openlife ask \
  "Analyze this repository, identify the highest-impact product improvement, and create an implementation plan." \
  --mode task

Start work that remains active in the background:

openlife ask \
  "Keep improving onboarding: inspect the product, propose changes, implement approved stories, run tests, and report progress." \
  --mode service

Follow and control the service:

openlife service status <serviceId>
openlife service events <serviceId> --limit 20
openlife service pause <serviceId> --reason "reviewing the current release"
openlife service resume <serviceId> --reason "continue execution"

From Telegram:

/core status
/core memory onboarding
/core run npm test
/core flow run release-check

Why founders use OpenLife

Founders building AI products rarely need another isolated chatbot. They need a system that can understand the product, retain decisions, coordinate work, operate across tools, and keep execution moving.

OpenLife connects those pieces in one local-first runtime:

| Need | OpenLife capability | |---|---| | Turn an objective into executable work | Missions in Task or Service mode | | Preserve product and engineering context | Stories, semantic code retrieval, codebase graph and persistent memory | | Use the right specialist for each step | Agents, squads, skills, workflows and capability packs | | Continue after the terminal closes | Long-running daemon, persistent queue, jobs and schedules | | Work with existing AI coding tools | Codex and Claude Code host-native execution | | Track and control autonomous work | Status, events, logs, evidence, governance and Telegram | | Move from idea to production | Scaffold, design, story execution, pull request and deployment |

Core capabilities

Persistent missions

Use Task mode for bounded work and Service mode for ongoing execution. Services can be inspected, paused, resumed and audited through their event history.

openlife ask "Create a launch plan for this product" --mode task
openlife ask "Monitor and improve activation every day" --mode service

Complete project context

OpenLife can compose relevant context from three project layers:

1. product stories and acceptance criteria;
2. semantically retrieved code chunks;
3. symbols and relationships from the codebase graph.

openlife index build
openlife graph build
openlife ask "How does authentication work in this project?"

The runtime ranks and budgets this context before passing it to the selected model or coding host.

Persistent memory

OpenLife treats memory as runtime infrastructure, not chat history. Local memory is the default and remains available across sessions and process restarts.

export OPENLIFE_MEMORY_PROVIDER=local

Optional memory backends include Mem0, Honcho, Supermemory and Redis Agent Memory Store. When configured, local storage can remain available as a resilient write-through layer.

Agents, squads and skills

OpenLife includes a runtime catalog for specialized execution:

.catalog/
  agents/
  skills/
  mcps/

squads/
  product/
  engineering/
  design/
  qa/
  devops/

• Agents provide specialized roles and decision patterns.
• Squads coordinate multiple agents around a mission.
• Skills package reusable execution capabilities.
• Workflows connect repeatable steps, conditions and handoffs.

Multiple execution surfaces

OpenLife can operate through:

• the local CLI;
• a long-running background daemon;
• Telegram;
• authenticated HTTP endpoints;
• scheduled workflows and persistent jobs.

Provider-independent execution

Use the coding environments and model providers that fit your product.

Host-native execution:

Codex · Claude Code

API and local providers include Anthropic, OpenAI, Gemini, OpenRouter, Ollama and other OpenAI-compatible or local runtimes.

Supported inference strategies include:

cli-only · hybrid · api-only · local-only

How OpenLife works

OpenLife has two cooperating execution profiles distributed through the same CLI package.

                         Human intent
                              │
               Terminal · Telegram · HTTP · Schedule
                              │
                              ▼
                    Mission + Governance
                              │
              ┌───────────────┴────────────────┐
              │                                │
              ▼                                ▼
     openlife-core                     openlife-agent
   local CLI runtime                 background daemon
              │                                │
              └───────────────┬────────────────┘
                              │
                    Core ↔ Agent Bridge
                              │
       ┌──────────────────────┼──────────────────────┐
       ▼                      ▼                      ▼
 Persistent memory     Agents and skills      Jobs and events
       │                      │                      │
       └──────────────────────┼──────────────────────┘
                              ▼
            Artifacts · Code · Tests · PRs · Deployments

openlife-core

The local execution body. Use it for interactive missions, repository analysis, agents, workflows, story execution, product scaffolding, pull requests and deployments.

openlife ask "What should we build next?"
openlife status
openlife agents list
openlife squads list
openlife skills list

openlife-agent

The continuous execution body. It runs as a long-lived process, receives work from channels, maintains a persistent mission queue and coordinates with the CLI.

openlife up
# or
openlife start --daemon

Core ↔ Agent Bridge

The two profiles share three primitives:

• discovery through a local gateway manifest;
• memory through the same persistent state layer;
• bidirectional work channels through authenticated HTTP, events and the local CLI inbox.

openlife bridge status
openlife bridge push status
openlife bridge pull
openlife bridge listen
openlife bridge memory "pricing decision"

Read the Core ↔ Agent Bridge guide.

Quickstart

Requirements

• Node.js 20 or newer
• npm 10 or newer
• optionally: Codex or Claude Code
• optionally: a Telegram bot for autonomous remote control

1. Install

npm install -g @openlife/cli

2. Run the installer

openlife init

The installer guides you through:

• the runtime profile: local core, autonomous agent or both;
• one or more supported coding hosts;
• model providers and authentication;
• model routing and fallback order;
• Telegram and service configuration when autonomous mode is enabled;
• system diagnostics before completion.

3. Verify the runtime

openlife --version
openlife doctor
openlife status

4. Run your first mission

openlife ask \
  "Understand this repository, summarize the product, and recommend the next three highest-impact actions." \
  --mode task

For the complete installation flow, see INSTALL.md and Getting started.

Build and ship an AI product

OpenLife includes a composable path from product idea to deployment.

# 1. Bootstrap a production-oriented SaaS foundation
openlife scaffold my-ai-product \
  --template=nextjs-supabase-clerk-stripe

# 2. Import or extract a design system
openlife design pull linear
# or
openlife design extract https://your-brand.com

# 3. Execute an implementation story
openlife story execute 1.1

# 4. Push the branch and open a pull request
openlife ship

# 5. Deploy
openlife deploy --provider=vercel

Each command can be used independently. OpenLife can also scaffold from custom Git repositories and deploy through supported provider adapters.

Read the SaaS Forge guide.

Common founder workflows

Product discovery

openlife ask \
  "Analyze our product, competitors, current architecture and user feedback. Produce a prioritized opportunity map." \
  --mode task

Continuous product improvement

openlife ask \
  "Continuously inspect open issues and product signals, group opportunities, and prepare implementation-ready stories." \
  --mode service

Repository onboarding

openlife index build
openlife graph build
openlife ask "Explain the architecture, critical paths and highest-risk modules."

Autonomous story delivery

openlife story execute 2.4
openlife ship

Release operations

openlife flow run release-check
openlife deploy --provider=railway

Safety and governance

OpenLife is designed for autonomous execution with explicit boundaries.

Current controls include:

• explicit consent for destructive actions;
• protected-branch refusal;
• constrained test and command execution;
• separate implementation, push, pull-request and deployment steps;
• environment-based secret handling;
• rotating authentication tokens for the local gateway;
• restricted permissions for local state and indexes;
• Telegram user allowlisting;
• auditable jobs, events, decisions and evidence;
• governance and risk-check commands;
• local embeddings by default for code context.

openlife governance status
openlife governance audit
openlife governance risk-check "deploy the current release"

Autonomy without boundaries is not a runtime. It is a liability.

Community and Enterprise

OpenLife follows an open-core model.

OpenLife Community

The Community runtime is free, self-hosted and MIT licensed. It includes the core local experience:

• CLI and local execution;
• Task and Service modes;
• agents, squads, skills and workflows;
• persistent local memory;
• project context, indexing and code graph;
• local jobs, logs, events and evidence;
• Telegram and local channels;
• host-native and provider-based execution;
• product scaffolding and delivery workflows.

OpenLife Enterprise

OpenLife Enterprise adds the organizational and commercial control layer for companies operating the same local-first runtime, including capabilities such as:

• commercial license management;
• organizations, seats and device activation;
• enterprise administration and billing;
• advanced paid safety controls;
• organizational governance and support.

The core runtime remains local-first. OpenLife does not require automatic upload of local task history, evidence or runtime state to make the Community edition useful.

Learn more at openlife.site and read the open-core model.

Command map

# Missions
openlife ask <message...> --mode <task|service>
openlife task status <taskId>
openlife service status <serviceId>
openlife service events <serviceId>

# Runtime
openlife status
openlife doctor
openlife job list
openlife runtime probe
openlife runtime list

# Agents and capabilities
openlife agents list
openlife squads list
openlife skills list
openlife flow run <workflow-id>

# Project context
openlife story list
openlife index build
openlife graph build
openlife provider setup

# Product delivery
openlife scaffold <name> --template=<template>
openlife design pull <brand>
openlife story execute <id>
openlife ship
openlife deploy --provider=<provider>

# Continuous agent
openlife up
openlife start --daemon
openlife bridge status

# Governance
openlife governance status
openlife governance audit
openlife governance risk-check <goal>

See the complete command manual.

Run from source

git clone https://github.com/GOOODZ/openlife-core.git
cd openlife-core
npm install
npm run build
node bin/openlife.js --help

Run the full test suite:

npm run test:all

Focused suites are also available for the bridge, context system, story loop, deployment adapters, licensing and other runtime surfaces.

🔒 Segurança

• Manifest auth (v1.11+): token 32-byte hex rotativo a cada start do daemon. Arquivo mode 0o600. Basic Auth fixa user openlife-core.
• Telegram allowlist: OPENLIFE_TELEGRAM_ALLOWED_USER_ID — single-user por design e obrigatório para acesso remoto; ausente significa deny-by-default.
• Cloud secrets: API keys lidas só de env/.env. Nunca logadas, nunca escritas no manifest.
• Sigstore provenance: cada publish npm carrega attestation OIDC do GitHub Actions — qualquer consumidor pode verificar que o tarball saiu do commit exato.
• No new network surface (v1.11): Express continua na porta 3000, SSE usa a mesma porta, file-queue é local-only.

Documentation

| Guide | Purpose | |---|---| | Getting started | Install OpenLife and run the first command | | Installation manual | Profiles, hosts, providers, auth and daemon setup | | Command manual | Current CLI surface | | Complete Context | Stories, semantic retrieval and code graph | | Core ↔ Agent Bridge | Discovery, shared memory and bidirectional work | | SaaS Forge | Scaffold, design, story execution, PR and deploy | | Open-core model | Community and Enterprise boundary | | Changelog | Releases and technical changes | | Manifesto | The ideas behind continuous execution |

Contributing

OpenLife is built in the open. Contributions to runtime reliability, providers, agents, skills, workflows, documentation, tests and examples are welcome.

1. Read CONTRIBUTING.md.
2. Create a focused branch.
3. Add or update tests for behavioral changes.
4. Run the relevant test suites.
5. Open a pull request with the problem, approach and verification steps.

Please follow the Code of Conduct.

Project status

OpenLife is under active development. The workflows described in this README are implemented in the current codebase, while interfaces and documentation continue to evolve quickly.

For production use, pin the package version, review the changelog and validate the runtime against your own security and deployment requirements.

License

OpenLife Community is released under the MIT License.

AI should not only answer. It should operate.

OpenLife is where the work continues.

Website · npm · Issues