Martin Sukany

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

For many years, I sought an efficient workflow for managing my personal websites. Over two decades ago, I began with pure HTML, progressed to WordPress, then shifted to my own HTML5 and CSS designs, and eventually adopted Obsidian with Hugo. My primary motivation was to generate websites directly from the source in my chosen editor, but this journey often led to considerable headaches.

Two decades ago, I exclusively used Emacs as my work environment, and at that time, Org mode hadn’t caught my interest. However, upon returning to Emacs, I decided to give Org mode a try. I was pleasantly surprised by its power compared to the standard Markdown and Pandoc setup. After experimenting with it, I’m excited to share the results: my websites are now generated from a single site.org file. The only steps I needed to take were to add the ox-org package to my Emacs configuration and invoke a simple function.