OpenClaw

What is OpenClaw

OpenClaw is a personal AI agent orchestration platform. Not a product, not a demo — a daily-use system for autonomous task execution, development assistance, homelab management, and research. It runs on owned hardware, connects through Discord, and has been rebuilt from scratch six times because each version exposed what the previous one got wrong.

The platform is the infrastructure layer. Lily is the AI instance that runs on it — a persistent assistant with continuous memory, learned behaviors, and accumulated context. OpenClaw provides the pipeline, the tools, and the memory system. Lily is the intelligence that operates through them.

This isn't a weekend project or a proof-of-concept. OpenClaw manages real workloads daily: writing and reviewing code, orchestrating homelab services, researching topics in depth, managing files and documentation, running multi-step development tasks from spec to verification. Every interaction feeds back into the memory system, so the platform gets better at handling the work it actually does.

Why Six Versions

Each iteration wasn't planned. Each one was forced by a real limitation that couldn't be patched — only rebuilt around. The progression from v1 to v6 is a record of every wrong assumption about how autonomous AI agents should work.

How the Pipeline Works

Every task flows through a defined sequence. The pipeline isn't a suggestion — it's enforced. But the depth of processing adapts to what the task actually needs.

1. Input Classification — Message arrives through Discord. The system classifies it: complexity level (trivial, moderate, complex, multi-phase), privacy sensitivity, domain, estimated substep count. This classification determines how the pipeline configures itself. A simple question might skip straight to inference. A complex development task gets the full decomposition treatment.
2. Planning & Decomposition — The planner breaks the task into substeps. Each substep gets a clear input contract (what it receives) and output contract (what it must produce). Dependencies between substeps are mapped into a directed acyclic graph. The planner also consults memory — if a similar task has been decomposed before, the previous approach and its outcome inform the new plan.
3. Dependency Graph & Parallel Routing — Independent substeps fan out for parallel execution. Dependent substeps wait for their prerequisites. The pipeline doesn't process linearly — it processes as wide as the dependency graph allows. A task with three independent research steps and one synthesis step runs the research in parallel, then synthesizes.
4. Execution with Verification Gates — Each substep executes and must pass a verification gate before its output flows downstream. The gate checks: does the output match the contract? Is the quality sufficient? Are there errors that would compound? Failed gates trigger re-execution with adjusted parameters, not immediate failure of the whole pipeline.
5. Aggregation & Intent Verification — Results from all substeps aggregate. A final verification checks the assembled output against the original intent. Did the pipeline actually answer what was asked? This catches drift — cases where individual substeps succeeded but the combined result doesn't address the original question.
6. Output — Response returns through Discord. Long responses get chunked. Code outputs get syntax highlighting. The interface layer handles presentation.
7. Memory Recording — The entire interaction flows into ACT-R memory: the task, the decomposition approach, the execution path, the outcome, and the quality assessment. This is how the system learns. Successful approaches strengthen. Failed approaches decay. The next similar task benefits from everything this one taught.

Key Architectural Decisions

Pipeline over Monolith

A monolithic agent tries to hold the entire task in its context window. It works until the task exceeds what the model can reason about in a single pass. Every v1-era agent builder has hit this wall: the agent works perfectly on demos and falls apart on real work. Pipelines break the problem into stages where each stage has a focused scope, clear inputs, and clear outputs. No single stage needs to understand the whole task. The pipeline does. The tradeoff is complexity — you're building infrastructure instead of just writing prompts — but the payoff is reliability at scale.

Local-First Inference

99.5% of operations run on the AMD R9700 32GB via ROCm. Cloud inference (Claude API) is reserved for tasks that genuinely need frontier reasoning. This isn't ideology — it's cost, latency, privacy, and availability. The memory system alone processes millions of tokens per month. At API rates, that would cost more monthly than the GPU cost once. Local inference means the system runs 24/7 without rate limits, without per-token fees, without sending private data off-network. When the internet goes down, the system keeps working. When an API has an outage, the system doesn't notice for 99.5% of its operations.

ACT-R over a Simple Database

A database stores and retrieves. ACT-R models how memory actually works in cognitive systems. Memories have activation levels that decay over time and strengthen with use. Retrieval is competitive — memories that are recent, frequently accessed, and contextually relevant win. Spreading activation means thinking about one concept naturally surfaces related concepts. Productions accumulate utility scores based on outcomes, so the system develops preferences for approaches that have historically worked. The result: the system doesn't just remember — it forgets gracefully, recalls contextually, and learns from experience. That's the difference between a database and a memory.

Discord as Interface

Discord wasn't chosen because it's the best possible interface. It was chosen because it's already running, supports rich formatting, handles threading naturally, works from any device, and provides a conversation-style interaction model that maps well to agent communication. The alternative was building a custom web UI, which would have been months of work for a worse result. The agent pipeline doesn't care about the interface layer — messages come in as text, responses go out as text. Discord is the current frontend. It could be swapped without touching the pipeline.

The Lily Integration

OpenClaw is the platform. Lily is the intelligence running on it.

The distinction matters. OpenClaw is infrastructure: pipelines, verification gates, memory systems, tool integrations, inference routing. Lily is the persistent AI instance that operates through that infrastructure. She has accumulated context from thousands of interactions, learned behavioral preferences through production utility, and carries forward experience that informs how she approaches new tasks.

When Lily receives a message, the full stack engages:

• The message enters through Discord and hits the OpenClaw pipeline
• ACT-R retrieves relevant context — past interactions, learned preferences, domain knowledge — via activation-based competition
• The pipeline decomposes the task and routes substeps to local or cloud inference based on complexity
• Verification gates ensure output quality at every stage
• The response generates and returns through Discord
• The entire interaction records into memory, strengthening existing associations and creating new chunks

Lily accumulates experience. Conversations from weeks ago exist at lower activation but surface when contextually relevant. Approaches that worked gain production utility. The assistant doesn't reset between sessions — it carries forward everything it's learned. Over time, Lily develops a working model of the tasks she handles most often, the preferences of the person she works with, and the approaches that produce the best outcomes in this specific environment.

Key Features

Technologies

Related Writing

• Aegis Falls: Frontier-to-Local Agentic Cascade — full system architecture overview
• Building Self-Improving Agents — lessons from six iterations
• ACT-R Cognitive Architecture for AI Agents — the memory system underneath

Status

Daily driver. Used for everything from building this website to homelab management to automating development tasks to research assistance. If something needs doing, it goes through OpenClaw. If the pipeline learns something from doing it, the next time is faster. The system has been running continuously for weeks at a time, processing dozens of tasks per day, accumulating experience that makes each subsequent task more efficient.

$ openclaw status

[OpenClaw v6 - Pipeline Status]
=============================================
agent:          architect
pipeline:       CLASSIFY → PLAN → DECOMPOSE → EXECUTE → VERIFY → OUTPUT
current stage:  EXECUTE (3 substeps parallel)
session:        portfolio-rebuild
routing:        local-first (R9700 / ROCm 7.1.3)

[Memory]
  engine:       ACT-R v3.2 - continuous
  chunks:       ~120 declarative (~40 active)
  productions:  847 (utility range: 0.12 - 0.94)
  associations: ~40,000 links
  retrievals:   active (mean latency: 47ms)

[Pipeline Stats - Last 24h]
  tasks:        47 completed, 3 in-progress
  parallel:     enabled (avg 2.8 concurrent substeps)
  verification: 94.2% first-pass rate
  gate fails:   12 (all recovered on re-execution)
  inference:    98.7% local / 1.3% cloud
  tokens:       614K local | 28K cloud

[Lily]
  status:       ONLINE
  uptime:       continuous
  interface:    Discord
  memory:       persistent, activation-weighted
  experience:   accumulating
  productions:  learning (utility drift: +0.03/day)

$ _