Track 1 — Hermes (web dashboard)

Goal: open the Hermes dashboard, see it running on Ollama Cloud, and tour the files that make Hermes tick — Skills, Profiles, Memory, Tools — then edit those files yourself.

Hermes is pre-1.0 and moves fast — if a command here differs from the live docs, the docs win. Check anything version-specific against the live docs. Docs: https://hermes-agent.nousresearch.com/docs/user-guide/features/web-dashboard

1. Open the dashboard

• Dashboard: https://hermes.konomondo.org
• Log in: username trainee · password hermes

That’s the official nousresearch/hermes-agent image. It’s already on Ollama Cloud (default model glm-5.1:cloud, helper models set), so the chat just works — click New chat. To change the model: the model selector (top-right) or Config.

2. Where the editable files live

Hermes runs in its own container, but the parts you author and learn from live in the hermes repo, which you clone into VS Code. In the browser VS Code (https://aiworkspace.konomondo.org), open a terminal and run:

clone-projects        # clones latex-starter + hermes into ~/projects

Now projects/hermes/ holds:

The loop: edit these in VS Code → commit & push (your own GitHub login) → redeploy the stack → the changes are seeded into the running Hermes. The repo is the source of truth.

How a change actually reaches Hermes (and why you must push). There are two copies of the hermes repo: the one you edit in VS Code (projects/hermes/), and the one Hermes reads (/opt/data, inside the Hermes container). They’re different clones — editing in VS Code doesn’t touch /opt/data directly. GitHub is the bridge: on each deploy a one-shot hermes-init step clones the repo from GitHub and copies the files into Hermes. So an unpushed edit never arrives. The full path:

1. Edit in projects/hermes/ → commit & push.
2. Redeploy the stack — in Portainer that’s the stack’s Pull and redeploy button. (It’s a redeploy, not a rebuild — Hermes runs the official image; nothing compiles.)
3. Start a New chat — existing chats keep their loaded SOUL.md/model.

For throwaway experiments you can edit straight in the dashboard, but that lives only in the container and is overwritten on the next redeploy — the repo wins.

⚙️ Stack update — two ways to run Hermes (your team decides). The flow above is the shared model: one Hermes, the repo is the single source of truth, and git (branch/PR) is the safeguard when several people edit the same files. There’s also a newer per-student model: each student gets their own Hermes, and its home volume is shared live with their VS Code — so editing projects/hermes/ is editing what Hermes reads. The loop becomes edit → restart Hermes → New chat (no push, no redeploy), and the home is seeded from the template only on first boot. Pick the shared model when people collaborate on one config; pick per-student when everyone has a personal sandbox. Both ship in the same stack — it’s a deployment choice, not a code change.

3. Guided tour (2–3 minutes each)

In the dashboard, open each screen and connect it to its editable source:

Try it: in VS Code, change a line in projects/hermes/SOUL.md, push, redeploy, then start a new chat in the dashboard and watch the behaviour shift. And note AGENTS.md — project-scoped instructions that complement SOUL.md.

Done when: the dashboard is open and talking to Ollama Cloud, and you can point to where Skills / Profiles / config live in projects/hermes/ and say what each is.

Your Track 1 build — automate the job

The tour is the warm-up. Track 1’s real goal is to automate a job: get Hermes to do what the LaTeX web UI does (topic → image), but unattended, on a daily schedule — a skill + a cron job + memory. That’s its own lesson: Automate with Hermes. (Track 3 builds the latex-mcp infrastructure; Track 1 automates the basic job.)

Concepts behind this: What is Hermes, Skills, Profiles & SOUL.md, AGENTS.md, Memory.