arthur@homelab:~$ cat ~/posts/ai-agents-second-brains-and-homelabs.md

AI Agents, Second Brains, and Homelabs

What changes when an AI agent can read the operating history of a real homelab, act on it, verify the result, and improve the record.

mtime 2026-07-04 · 4 min read

There is a specific kind of leverage at the intersection of three things:

a human who writes down what they know;
an AI agent that can inspect, reason, and act;
a real environment where the result can be verified.

That environment could be a codebase or a company knowledge base. The place where it feels most concrete to me is my homelab.

A homelab is not just a pile of servers. It is a living system of storage, networking, DNS, reverse proxies, monitoring, backups, identity, logs, and half-finished ideas. It also has physical constraints: power, heat, USB disks, batteries, Ethernet, firmware, and the uncomfortable fact that every clean abstraction still depends on a machine plugged into a wall.

Give an AI agent access to a maintained second brain about that environment and the interaction stops feeling like a generic chat. It starts to resemble an extra systems engineer with immediate access to the lab’s institutional memory.

Context is the scarce resource

An agent can explain Prometheus, Caddy, Tailscale, Incus, Ceph, or NUT. Generic product knowledge is rarely the hard part. The hard part is knowing this environment:

which Raspberry Pi owns the UPS connection;
which hosts must shut down and how long Incus may need;
where Caddy stores shared certificate material;
which container owns monitoring;
which previous failure changed the runbook;
which values are secrets and must never enter the notes.

Those facts do not live in a product manual. They live in worklogs, config snapshots, incident reports, and the accumulated scar tissue of operating the system.

That changes the useful request from “How do I configure NUT?” to something closer to: “Use the homelab documentation, finish the NUT rollout, connect it to Prometheus and Alertmanager, validate every protected host, and document the result.”

The second request contains an operational program, not a trivia question.

The loop is the product

The most useful pattern is a feedback loop:

I provide intent and acceptable risk.
The second brain supplies local context.
The agent inspects the live system.
It proposes or performs a bounded change.
It verifies the actual result.
It writes the new state back into the second brain.

Every completed loop makes the next one better. A fixed incident becomes a future diagnostic. A copied configuration becomes a drift reference. A rollback command becomes part of the next change plan.

The second brain is both input and output.

Verification separates operations from plausible prose

The homelab is useful because it refuses to remain abstract. Packages are missing. Services are active but broken. Unattended installs encounter prompts. Users cannot read the system journal. A dashboard can be valid JSON and still show no useful data.

One Loki problem made the distinction obvious. Several hosts were missing from Grafana. A generic answer could have listed common Promtail mistakes. Live inspection found the actual chain:

Promtail was absent or inactive on two hosts.
After installation, it still shipped zero journal lines.
Running journalctl as the service account showed a permission failure.
Adding that account to systemd-journal restored ingestion.
Loki then exposed the expected host labels.

The useful result was not an explanation that sounded right. It was a verified data path followed by an accurate worklog.

Documentation is operational infrastructure

Documentation is often treated as a tax paid after the real work. Agentic operations invert that relationship. The documentation is the map used to do the work safely.

“Prometheus is installed” is not enough. A useful record says:

which container owns it;
where the live configuration resides;
where the sanitized documentation copy lives;
which command validates it;
which assumptions are intentional;
which secrets are omitted;
what was tested and what remains uncertain.

I keep narrative notes for why, configuration snapshots for what, and dated worklogs for how it changed. That structure is not full GitOps, but it is executable in spirit. An agent can compare desired history with live state without pretending the documentation is automatically current.

The human is still steering

The agent does not provide priorities, taste, or risk tolerance. I do.

Details such as “Incus shutdown can take a long time,” “do not expose this service publicly,” or “I am not convinced the direct connection is the problem” materially change the work. The agent can tirelessly compare five hosts, but it should not invent the reason for doing so.

The pattern is not “AI manages my homelab.” It is:

human intent
  + durable personal knowledge
  + bounded agentic execution
  + real-world verification
  + documentation feedback
= compounding operational leverage

The next step is not simply more automation. It is better memory: clearer ownership, more reliable runbooks, useful incident records, and honest notes about uncertainty. As those improve, the boundary between notes, config, dashboards, and operations starts to blur.

For now, the result looks ordinary: a Raspberry Pi watching a UPS, a few small servers running Incus and Ceph, Prometheus scraping metrics, Loki collecting logs, and Markdown slowly becoming a living map of the system.

Underneath it is a larger idea: a second brain works remarkably well with AI agents. Add a homelab, and the feedback becomes physical.