K@architecture

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 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.

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.