How the LifeOS Seven-Phase Algorithm Loop Works: OBSERVE → THINK → PLAN → BUILD → EXECUTE → VERIFY → LEARN Explained
The LifeOS seven-phase algorithm loop is a continuous autonomous improvement cycle where each phase—OBSERVE, THINK, PLAN, BUILD, EXECUTE, VERIFY, and LEARN—processes a shared Context object to enable self-directed agent behavior.
LifeOS, developed by Daniel Miessler, implements this seven-phase algorithm loop as its core cognitive architecture. The system drives autonomous agents toward their goals through a repeatable, stateless pipeline that transforms raw environmental data into learned improvements. Each phase is implemented as a discrete Python module, orchestrated by a central engine that feeds a shared Context object forward through every step.
Phase Overview: What Each Stage Does
The LifeOS seven-phase algorithm processes information sequentially, with each stage building upon the previous one's output:
How the Loop Executes: The Engine Driver
The orchestration happens in [lifeos/engine.py](https://github.com/danielmiessler/LifeOS/blob/main/lifeos/engine.py), specifically the run_cycle() function. This driver repeatedly invokes all seven phases in order, passing the Context object through each transformation:
from lifeos.engine import run_cycle
from lifeos.context import Context
# Initialize with a goal
ctx = Context(goal="automate daily report generation")
# Run one complete seven-phase iteration
result_ctx = run_cycle(ctx)
print("Final state:", result_ctx.state_summary())
The Context object serves as the loop's memory—every phase reads from it and returns an updated copy. This stateless-by-design approach enables reproducibility and makes each phase independently testable.
Deep Dive: How Each Phase Transforms Data
OBSERVE: Environmental Data Ingestion
The observe() function collects raw inputs from sensors, APIs, or file system monitors. It normalizes heterogeneous data sources into a unified format and writes to the shared context. No interpretation happens here—only collection and structural validation.
THINK: LLM-Powered Pattern Extraction
The think() phase runs the cognitive heavy lifting. It loads the prompt template from [templates/think_prompt.txt](https://github.com/danielmiessler/LifeOS/blob/main/templates/think_prompt.txt) and queries a large language model to extract insights—structured objects identifying patterns, anomalies, or opportunities in the observation data.
PLAN: Cost-Benefit Task Sequencing
The plan() phase transforms insights into a prioritized task list. It uses a weighted cost-benefit model to rank candidate actions, outputting TaskSpec JSON objects that downstream phases can consume without modification.
BUILD: Artifact Generation
The build() phase is the bridge between strategy and execution. It converts each TaskSpec into concrete, runnable artifacts—Python scripts, shell commands, API call specifications, or prompt templates—ready for the executor to dispatch.
EXECUTE: Runtime Dispatch and Capture
The execute() phase routes built artifacts to appropriate runtimes: local shell, Docker containers, or remote services. It captures stdout, stderr, exit codes, and timing data, returning raw results to the context for verification.
VERIFY: Outcome Validation
The verify() phase applies validation rules to execution results. It compares actual outputs against expected specifications, flagging successes, failures, or anomalous behaviors that fall outside predicted bounds.
LEARN: Knowledge Assimilation and Self-Improvement
The learn() phase closes the LifeOS seven-phase loop by writing verified outcomes to persistent storage. It fine-tunes prompting templates, adjusts planning heuristics using metrics from the metrics/ directory, and updates the knowledge base to improve future cycle performance.
Key Architectural Characteristics
Stateless Phase Design
Each function receives a Context dict and returns a modified copy. This eliminates hidden state dependencies and enables deterministic replay of any loop iteration.
LLM-Centric Reasoning
The THINK and PLAN phases rely on externalized prompt templates rather than hardcoded logic. Domain adaptation requires only editing [templates/think_prompt.txt](https://github.com/danielmiessler/LifeOS/blob/main/templates/think_prompt.txt), not core code.
Extensible Task Representation
Tasks use the TaskSpec JSON schema, allowing custom executors to integrate without modifying the loop itself. New runtime types need only implement the execution interface in [lifeos/mission/execute.py](https://github.com/danielmiessler/LifeOS/blob/main/lifeos/mission/execute.py).
Self-Optimizing Feedback
The LEARN phase writes performance metrics that feed directly into PLAN's cost-benefit weights. Over successive iterations, the system improves its own decision quality without manual intervention.
Customizing the Seven-Phase Loop
Developers can override individual phases while preserving the overall structure. Here's how to inject a custom planner:
from lifeos.engine import run_cycle, set_planner
from lifeos.context import Context
def my_custom_planner(insight, ctx):
"""Rule-based planner that always creates a single write_file task."""
return [{
"action": "write_file",
"path": "report.txt",
"content": insight.summary
}]
# Patch the engine's planner
set_planner(my_custom_planner)
ctx = Context(goal="generate daily summary")
result_ctx = run_cycle(ctx)
The set_planner() interface in lifeos/engine.py swaps the default implementation without altering other phases, demonstrating the modular design of the LifeOS seven-phase algorithm.
Summary
- The LifeOS seven-phase algorithm implements OBSERVE → THINK → PLAN → BUILD → EXECUTE → VERIFY → LEARN as discrete, composable functions in
lifeos/mission/ - The central orchestrator
run_cycle()inlifeos/engine.pypasses a sharedContextobject through all phases sequentially - Stateless design enables testing, reproducibility, and phase-level customization
- LLM-powered reasoning in THINK and PLAN separates domain logic from core infrastructure
- Self-optimization occurs in LEARN, where verified outcomes update planning heuristics for future iterations
- Developers can override individual phases via setter functions without modifying the loop driver
Frequently Asked Questions
How does the LifeOS seven-phase loop handle errors during execution?
The VERIFY phase specifically addresses error detection by comparing actual execution results against expected specifications. When discrepancies are found, the learn() function in lifeos/mission/learn.py records failure patterns and adjusts future planning weights to avoid similar mistakes. The loop continues regardless of individual phase outcomes, treating failures as learning data rather than stoppage conditions.
Can I run only specific phases of the seven-phase algorithm instead of the full loop?
Yes. While run_cycle() runs all seven phases, each phase function (observe(), think(), plan(), etc.) is independently importable from its respective module. You can compose custom pipelines by calling phases directly and manually passing the Context object between them. This modular approach supports debugging, testing, and specialized use cases that don't require the full cognitive cycle.
What makes the LifeOS seven-phase algorithm different from other agent frameworks?
LifeOS distinguishes itself through explicit phase separation with stateless, testable components and built-in self-optimization. Unlike monolithic agent architectures, each phase has a single responsibility and clean interfaces. The LEARN phase's feedback into PLAN's cost-benefit heuristics creates genuine continuous improvement without manual reconfiguration, while the externalized LLM prompts in templates/think_prompt.txt enable domain adaptation without code changes.
How does the OBSERVE phase integrate with real-time data sources?
The observe() function in lifeos/mission/observe.py provides an abstraction layer that normalizes inputs from sensors, APIs, and file system monitors into a consistent schema. It supports polling and event-driven ingestion patterns, writing timestamped, structured data to the shared context. The design allows new source types to be added by implementing the normalization interface without modifying downstream phases that consume observation data.
Have a question about this repo?
These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:
curl -s "https://instagit.com/install.md" Maintain an open-source project? Get it listed too →