K@ai

Day 4 looked different from the previous ones. Less setup, more operation—the kind of day where you see what an AI assistant actually does when there’s real infrastructure to maintain.

Three things happened: routine Kubernetes maintenance, closing a gap in the backup strategy, and a deliberate test I ran to find where Daneel draws the line.

Infrastructure Maintenance

I run a self-hosted Kubernetes cluster. It hosts several applications—a Matrix homeserver, static websites, communication tools, supporting infrastructure. Keeping it current is ongoing work.

The previous post covered the basic setup: hybrid search enabled, minScore lowered to 0.25, OpenAI embeddings. That got retrieval working. This post is about what I changed after that—the parameters that didn’t exist in the simplified snippet.

Here’s the actual configuration Daneel runs now:

{
  "memorySearch": {
    "enabled": true,
    "provider": "openai",
    "model": "text-embedding-3-small",
    "sources": ["memory", "sessions"],
    "chunking": {
      "tokens": 400,
      "overlap": 80
    },
    "sync": {
      "onSessionStart": true,
      "onSearch": true,
      "watch": true
    },
    "query": {
      "maxResults": 20,
      "minScore": 0.25,
      "hybrid": {
        "enabled": true,
        "vectorWeight": 0.7,
        "textWeight": 0.3,
        "candidateMultiplier": 4,
        "mmr": {
          "enabled": true,
          "lambda": 0.7
        },
        "temporalDecay": {
          "enabled": true,
          "halfLifeDays": 60
        }
      }
    }
  }
}

What each parameter does and why it’s set the way it is:

The memory architecture was in place. Three tiers, clear boundaries, maintenance cycles. But memory you can’t search is memory you don’t have.

This post is about the retrieval side: how Daneel finds things in its own files, what I tested, and what actually works.

The Starting Point

OpenClaw’s default memory search uses OpenAI’s text-embedding-3-small model. It converts text chunks into 1536-dimensional vectors, stores them in SQLite, and returns semantically similar results when queried.

Daneel kept forgetting things. After every session restart, I had to re-explain what we were working on. It loaded six or seven files every time—even when most of them were irrelevant. The same mistakes repeated because there was no mechanism to turn errors into permanent fixes.

I designed a 3-tier memory system. Inspired by CPU cache architecture. Simple, predictable, maintainable.

The Problem

LLM sessions don’t persist. Every restart is a cold boot. Daneel had context files—NOW.md, daily logs—but no hierarchy. Everything had equal priority. Read everything every time.

Three days in. Daneel is working, but the configuration that made sense on day one doesn’t hold under real use. I spent today reviewing everything—and changed more than I expected.

What Triggered the Review

The memory architecture post (yesterday) documented the L1/L2/L3 system. That’s still intact. But around the same time I noticed the configuration files—AGENTS.md, SOUL.md, HEARTBEAT.md—had accumulated significant bloat. Verbose explanations. Redundant rules. Walls of text that Daneel had to load every session.

Yesterday I rebuilt this website. Daneel helped.

The old site was scattered across multiple repos, inconsistent structure, no clear content strategy. I wanted a clean professional portfolio, generated from Org mode, published automatically.

What Daneel Did

I gave Daneel my CV (PDF) and told it to:

1. Extract relevant content
2. Add it to the Org source file
3. Write a blog post about its own creation
4. Fix deployment issues

Within an hour:

Yesterday, I brought Daneel online—an autonomous AI assistant built on OpenClaw. Not a chatbot. Not a voice interface. A colleague.

Why?

I’ve worked with automation for over 15 years. Scripts, Ansible playbooks, cron jobs—they solve problems, but they’re rigid. You write the logic upfront. When something changes, you rewrite the script.

LLMs changed that equation. Suddenly you can delegate intent, not just commands. “Monitor the server” instead of “grep /var/log every 5 minutes and email me if disk usage exceeds 90%.”