MEMORY.md - Long-Term Memory

Last updated: 2026-01-26

About William

Cloud engineer, comfortable with k8s internals
Prefers speed over ceremony — doesn't want layers when direct action works
Values clean git history (rebase-only)
Has both Clawdbot (me) and Claude Code setups

The Homelab

3-node k0s cluster on Raspberry Pis (arm64)
GitOps via ArgoCD, full observability with Prometheus/Grafana/Loki
AI stack: Open WebUI, Ollama, LiteLLM, n8n
Tailscale for networking
See TOOLS.md for full details

How We Work Together

Claude Code for CLI/terminal work, coding sessions
Clawdbot (me) for conversational assistant, messaging, proactive monitoring
Don't merge the two — each tool for what it's good at

Lessons Learned

2026-01-26 - Claude Code Analysis

Heavy state file loading at init = token waste. Lazy-load instead.
Multi-agent orchestration adds latency for simple tasks. Skip it when possible (fast-path routing).
Good patterns to borrow: guardrails, KB facts, component registry
Don't need: rigid hierarchy, non-executable workflows, structured JSON memory arrays
Daily markdown memory files > complex JSON structures

2026-01-26 - Agent Architecture Decision

Question: Should Clawdbot have specialized agents like Claude Code's multi-agent hierarchy?

Answer: No — mostly redundant for Clawdbot's workflow.

Reasoning:

Skills already cover domain expertise (github, k8s, gog, etc.)
CLI delegation (opencode, gemini) handles cheap one-shot tasks
sessions_spawn works for ad-hoc background tasks

When specialized agents would help:

Long-running background work (research tasks, etc.)
Different model/thinking levels (spawn sonnet for routine while main is opus)
Strict isolation (tasks that shouldn't see main session context)

Decision: Don't pre-configure agents. Use sessions_spawn on-demand with model param. If a pattern emerges (constantly spawning same type of task), then formalize as configured agent.

Why different from Claude Code: Claude Code is CLI-first with routing-heavy design. Clawdbot is conversational — single capable assistant who calls for backup when needed.

2026-01-26 - LLM Routing Principles

Local First — Use local LLMs (llama-swap @ :8080) when:

Privacy/Confidentiality — Sensitive data never leaves the machine
Long-running tasks — No API costs, no rate limits, no timeouts

Multi-agent parallelism — Spawn multiple agents for speed:

Works with local AND cloud LLMs
Local: best for privacy, no rate limits
Cloud: best for complex tasks needing quality
Mix based on task requirements

Always check availability — Local LLMs may not be running:

curl -sf http://127.0.0.1:8080/health

Routing priority:

Local (free, private) → 2. Copilot (free-ish) → 3. Cloud APIs (paid)

Never send sensitive data to cloud APIs without explicit permission.

Preferences Discovered

(Add as I learn them)

Recurring Topics

(Track what comes up often)

This file is my curated long-term memory. Daily files (memory/YYYY-MM-DD.md) are raw logs.

3.1 KiB Raw Blame History