K@ai

I stopped asking my personal AI assistant to write code. That decision — more than any prompt engineering trick or model upgrade — improved the quality of what I get back. This post is about why, and what the setup actually looks like in practice.

The problem with asking your personal assistant to write code

My personal assistant, Daneel, knows a lot about me. It tracks my calendar, triages my email, controls my Home Assistant devices, remembers past conversations, and generates a morning briefing before I’ve had coffee. That rich context is exactly what makes it useful for life-admin. It’s also exactly what makes it a poor choice for writing code.

Two weeks ago I published a post about giving Daneel a soul — replacing Asimov’s Laws with a real priority hierarchy and a decision model. Last week I rewrote it again. Not because the first version was wrong, but because running it in production taught me what was missing: harm prevention has to come before “follow instructions,” trust has to be explicit, and an agent that waits to be asked is an agent that will eventually do the wrong thing at the wrong moment. Here’s what changed and why.

The Problem We Had

Our first multi-agent pipeline was a disaster waiting to happen. The architecture seemed clean: spawn workers, each does its thing, updates a shared `status.json` to record completion, and if it’s the last one in its phase, spawns the next batch. Workers know the workflow, workers drive progress. What could go wrong?

Plenty.

The race condition was textbook. Two parallel research workers — `researcher-a` and `researcher-b` — finish around the same time. At `t=0`, both read `status.json`. Both see themselves as the last remaining worker. At `t=1`, both write back with themselves marked completed. One write wins. The other is silently lost. The “winning” worker sees only its own completion, decides the phase isn’t done, and does nothing. The pipeline stalls. No error. No timeout for another ten minutes. Just silence.

On day 2, the agent tried to re-enable a Twitter integration I had explicitly cancelled the night before. It had forgotten. Not because of a bug — because session restarts wipe context, and nothing in the default setup prevents an AI from re-deriving a decision you already vetoed.

That’s when I started building the infrastructure that turned a chatbot into something that actually works.

This is not a tutorial. It’s what running an autonomous AI agent looks like after 10 days: what it costs, what breaks, and what I’d change.

My multi-agent pipeline was failing at random. Not always, not predictably — just often enough to make me stop trusting it. Worker-2 would run, write its output, and then nothing would happen. The orchestrator was sitting there waiting for an announce that never arrived. The bug already had a ticket number: #17000. Description: hardcoded 60-second timeout, no retry. I’d built the entire coordination model on message delivery, and message delivery was the single point of failure. The fix wasn’t more retries. It was getting rid of message-based coordination entirely.

Day 5 was the most varied day yet. Not in complexity—some earlier days had harder problems—but in range. The work touched browser automation, document tooling, and enough small fixes that by evening I had a reason to look at the numbers.

Running a Browser Without a Screen

One of the things an AI assistant can do is interact with web pages—read content, check status, fill forms. But this particular setup runs on a headless Linux server. No display, no window manager, no user session.

I have a small internal tool called Scénář Creator. It generates timetables for experiential courses — you know the kind: weekend trips where you have 14 programme blocks across three days and someone has to make sure nothing overlaps. I built version one in November 2025. It was a CGI Python app running on Apache, backed by Excel.

Yesterday I asked Daneel to rebuild it. Four hours later, version 4.7 was running in production. Here’s exactly what happened.

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.