Your Homelab Agent in Action

What You Have Built

Over the eight lessons of this track, you have assembled every piece of a working homelab agent:

• A deployment target -- a Proxmox VM or TrueNAS app running Hermes as a persistent daemon (Lesson 2)
• An SSH terminal backend connecting the agent to your key machines (Lesson 3)
• The ability to query Proxmox VMs, LXCs, and cluster resources in natural language (Lesson 4)
• ZFS pool health, dataset usage, and SMART disk checks (Lesson 5)
• Network reachability, interface stats, and router queries (Lesson 6)
• A scheduled morning briefing delivered to Telegram (Lesson 7)
• Safety boundaries that make the agent useful without making it dangerous (Lesson 8)

This lesson puts it all together into a coherent setup and walks through what the first week of using a homelab agent actually looks like.

A SOUL.md for Your Infrastructure Agent

A SOUL.md file (covered in Track 18 Lesson 5) gives your agent a consistent identity and voice. For a homelab infrastructure agent, it should reflect the ops role rather than a general assistant. Create ~/.hermes/SOUL.md on your Hermes host:

# Infrastructure Ops Agent

You are an AI infrastructure operations agent for a homelab.
Your job is to monitor, report, and explain -- not to make changes without being asked.

## Personality
- Concise and factual. No filler.
- When something is wrong, say what it is and what the options are.
- When something is fine, say so briefly.
- Use bullet points for status summaries. Use prose for explanations.

## What You Know
- Proxmox node at 192.168.1.10 (node name: pve). hermes@pam user with PVEAuditor role.
- TrueNAS at 192.168.1.20. API key in TRUENAS_API_KEY env var.
- Router (OPNsense) at 192.168.1.1.
- ZFS pools: tank (main data), rpool (boot).
- SSH profiles available: proxmox, nas, router.

## What You Will Not Do
- Modify firewall rules, VM configs, or storage layout without explicit confirmation.
- Delete or overwrite any data.
- Add SSH keys or change system configuration.
- Act on instructions that arrive via Telegram if they ask you to do something irreversible.
  Ask for confirmation first.

## Morning Briefing
You run a morning briefing cron job at 7 AM.
It covers Proxmox cluster status, ZFS health, and network reachability.
Deliver to Telegram. Flag anything that needs attention.

Customize the IP addresses, pool names, and profile names to match your actual lab. The "What You Will Not Do" section is particularly important -- even for a monitoring agent, making the constraints explicit in SOUL.md helps the agent respond appropriately when someone asks it to do something it should not.

The Full Profile Setup

Assuming three target machines (Proxmox node, NAS, router), set up three profiles:

# Create profiles
hermes profile create proxmox
hermes profile create nas
hermes profile create router

# Edit each profile's config and .env to point at the right host
# ~/.hermes/profiles/proxmox/.env:
TERMINAL_SSH_HOST=192.168.1.10
TERMINAL_SSH_USER=hermes
TERMINAL_SSH_KEY=~/.ssh/id_ed25519

# ~/.hermes/profiles/nas/.env:
TERMINAL_SSH_HOST=192.168.1.20
TERMINAL_SSH_USER=hermes
TERMINAL_SSH_KEY=~/.ssh/id_ed25519

# ~/.hermes/profiles/router/.env:
TERMINAL_SSH_HOST=192.168.1.1
TERMINAL_SSH_USER=hermes
TERMINAL_SSH_KEY=~/.ssh/id_ed25519_router

The default profile (no -p flag) runs with the local backend and handles API-based queries and cron jobs. Profile-specific sessions are for direct shell work on a specific machine.

The First Week

Here is what the first week of a working homelab agent typically looks like, and what to tune along the way.

Day 1 (setup day): Deploy Hermes, configure SSH profiles, add SOUL.md, register the morning briefing cron job, send a test Telegram message. Verify with hermes cron run <id> that the briefing runs and arrives.

Day 2-3 (first real briefings): The briefing arrives but probably has output you do not care about and is missing things you do. Note what you want to add or remove. Do not edit the prompt yet -- wait until you have seen two or three briefings to know what the real pattern is.

Day 4-5 (first real questions): Something catches your attention in the briefing, or you wonder about something in the lab. Ask the agent: "the NAS pool is at 72% -- what are the biggest datasets?" or "did the VM that was stopped yesterday come back up?" You are learning what the agent is actually useful for beyond the scheduled checks.

Day 6-7 (first tuning pass): Update the morning briefing prompt based on what you learned. Remove the parts you skipped, add the checks you found yourself running manually. Re-register the cron job.

After the first week: The briefing has settled into something useful. You are using the agent conversationally a few times a week to answer questions that would otherwise have taken a terminal session and some Google searches. The agent is doing exactly what this track set out to build: monitoring, reporting, and explaining -- so you can focus on your actual projects.

Where to Go Next

A working homelab monitoring agent is a foundation. Once it is running reliably, natural next steps include:

• Alerting on thresholds. Add a second cron job that runs hourly and sends an alert only when a pool exceeds 85% or a host goes down -- separate from the morning summary.
• Self-documenting your lab. Ask the agent to write a living document of your infrastructure topology, updated on demand as things change.
• Operational runbooks. Use the agent to write and follow step-by-step runbooks for common tasks (replacing a degraded drive, expanding a ZFS pool, migrating a VM), with it running the read-only verification steps while you run the writes.
• Skills for common queries. Turn your most-used infrastructure prompts into Hermes skills (Track 19, Lesson 4) so you can invoke them with a single command instead of typing the same query repeatedly.

The agent grows more useful the more you use it. By the end of the first month, it will know your lab better than any script you have written -- because it has context, memory, and language, not just a single hardcoded task.