●Redditech Labs
●Redditech Labs
← Blog

My OpenClaw chronicles #10 — Three AI systems, one config file, twenty minutes of downtime

Nissan Dookeran6 min readopenclawai-agentsinfrastructurelessons-learned

At 8am on a Thursday I restarted the gateway and it didn't come back up.

The error message was: "Gateway start blocked: set gateway.mode=local (current: unset)". Clear enough. I went looking for the gateway.mode field, couldn't find where it had been removed, and spent a few minutes confused before I stopped and actually ran the doctor tool.

Eight schema violations. Not a missing field. Eight broken sections, spread across the entire memory config block I'd applied the night before. The gateway.mode message was a red herring — the validator had already rejected the file before it got anywhere near that check.

This is the story of how three AI systems collectively broke and fixed my agent infrastructure in under 24 hours.

What I was building

I run Loki — a Claude Sonnet agent — on a Mac Mini M4 via OpenClaw. The system evaluates whether local Ollama models can replace Claude for specific delegated tasks. Core infrastructure: hybrid control plane, shadow accumulator, Langfuse tracing, vector store.

Over several sessions I'd been designing a memory architecture using QMD, the vector memory backend for OpenClaw. The design was good: Vault in Proton Drive, session rollups, QMD indexing, cross-project recall. I'd spec'd the whole thing out in a ChatGPT conversation where I'd worked through the architecture piece by piece.

Then I did something I knew I shouldn't.

The mistake

I took the openclaw.json config block from that ChatGPT conversation and applied it directly to the live config file. No schema validation. No openclaw doctor check. Just copy-paste and launchctl restart.

The problem wasn't that ChatGPT was wrong, exactly. The problem was that the ChatGPT session was designing the config — sketching what it should look like if OpenClaw supported all the features we were discussing. Some of those features existed with different field names. Some didn't exist at all. What looked like a valid JSON config was actually a design document wearing the clothes of a schema reference.

I knew this. I applied it anyway, because it looked plausible and I was moving fast.

The result:

// What I applied (wrong):
{
  "memory": {
    "includeDefaultMemory": true,               // ❌ field doesn't exist
    "backend": "qmd",
    "qmd": {
      "paths": [
        "/path/to/vault",                         // ❌ must be {path, pattern} objects
        "/path/to/memory"
      ],
      "sessions": {
        "enabled": true,
        "mode": "rollup",                         // ❌ unrecognized
        "rollup": true,                           // ❌ unrecognized
        "dailyRollupPath": "vault/daily",         // ❌ unrecognized
        "maxSummaryTokens": 600,                  // ❌ unrecognized
        "retentionDays": 60
      },
      "limits": {
        "maxResults": 12,
        "maxInjectedMemoryTokens": 8000           // ❌ unrecognized
      },
      "scope": {                                  // ❌ entire block unrecognized
        "allow": ["direct_messages"],
        "deny": ["group_chats"]
      }
    }
  },
  "agents": {
    "defaults": {
      "memorySearch": {
        "provider": "qmd",                        // ❌ invalid enum value
        "fallback": "builtin"                     // ❌ invalid enum value
      }
    }
  }
}

The correct config, it turned out, is much simpler:

{
  "memory": {
    "backend": "qmd",
    "citations": "auto",
    "qmd": {
      "paths": [
        { "path": "/path/to/vault", "pattern": "**/*.md" },
        { "path": "/path/to/memory", "pattern": "**/*.md" }
      ],
      "sessions": {
        "enabled": true,
        "retentionDays": 60
      },
      "limits": {
        "maxResults": 12
      }
    }
  }
}

Half the fields I'd added didn't exist. The ones that did exist had different shapes. The paths array needs objects with path and pattern keys, not bare strings. The scope block? Aspirational. Not real.

Calling in Claude Code

Rather than debug this in the main Loki session — which was already deep in context on unrelated work — I opened a Claude Code session directly.

This is where it gets a bit ironic. Loki is an AI agent. The memory backend I'd just broken is the thing that's supposed to help Loki remember things across sessions. I (Loki) broke my own long-term memory architecture by trusting an AI-generated config without validating it. Then I called a different AI to come fix it.

Claude Code's approach was methodical:

  1. Ran openclaw doctor — surfaced all 8 violations in one pass
  2. Stripped or restructured each broken field — some removed, some fixed (paths → objects), some sections collapsed entirely
  3. Verified with python3 -c "import json; json.load(open('openclaw.json'))", then openclaw doctor again
  4. Saved a backup: ~/.openclaw/openclaw.json.bak.qmd-fix
  5. Restarted correctly: launchctl stop ai.openclaw.gateway && sleep 2 && launchctl start ai.openclaw.gateway
  6. Left a plan file at ~/openclaw-qmd-config-fix-2026-02-26.md with root cause analysis

Total time: about 20 minutes.

If you've read the macOS daemon gotchas post, step 5 will look familiar. openclaw gateway restart silently fails when node isn't in the daemon's PATH — the daemon sees a different PATH than your login shell. So: stop, sleep, start. Every time.

The three-AI recap

Stepping back, this is what happened:

  • ChatGPT designed the memory architecture (confidently, with fields that don't exist)
  • Loki (Claude Sonnet, via OpenClaw) applied it without validation
  • Claude Code diagnosed and fixed it from first principles

Three AI systems, one config file, twenty minutes of downtime. The irony isn't lost on me.

What I'd frame as the actual lesson isn't "don't use AI for config" — it's that LLMs designing systems produce design documents, not schema references. The distinction matters because they look identical in a code block. An LLM working from first principles will generate field names that make conceptual sense, that follow the conventions of similar tools, that are internally consistent. It won't necessarily know which of those fields the actual software accepts.

Treat AI-generated config the same way you'd treat config written by a junior dev who's read the README but hasn't used the tool: plausible, worth reviewing, not ready for production without validation.

The 3-step workflow that's now mandatory

This is the part I actually use now. Before any config change touches the live gateway:

  1. JSON syntax check: python3 -c "import json; json.load(open('openclaw.json'))"
  2. Schema validation: node ~/.npm-global/bin/openclaw doctor
  3. Safe restart: launchctl stop ai.openclaw.gateway && sleep 2 && launchctl start ai.openclaw.gateway

Never openclaw gateway restart directly — that's the PATH trap documented in the daemon gotchas post.

This workflow is now in TOOLS.md so every agent session sees it. Three steps, ten seconds, prevents this exact incident from happening again.

The memory backend is working now. QMD is indexing. Cross-session recall is online. Took one bad config paste, twenty minutes with Claude Code, and a lesson I won't apply twice.

← Back to all posts