Exact staff and agent playbook for building an Obsidian/LLM Wiki knowledge system around Hermes Agent
This manual explains how to build a practical, staff-run, agent-assisted knowledge base around Hermes Agent. The idea is simple:
The goal is not to dump every file into AI. The goal is to create a disciplined source trail that staff and agents can trust. Every important claim should have a source, every source should have a place, and every reusable procedure should become a skill or wiki page.
A private, Obsidian-compatible markdown knowledge base that Hermes can read, update, cross-reference, lint, and use when answering business questions.
Assign these roles before building. One person can hold more than one role, but every role must be covered.
| Role | Who | Responsibility |
|---|---|---|
| Owner | Chris or appointed lead | Approves scope, access, publication boundaries, and automation risk. |
| Wiki Lead | Staff operations lead | Maintains SCHEMA.md, index.md, log.md, page quality, tags, and naming rules. |
| Source Collector | Staff/admin | Saves approved sources into the raw folders with source URLs, dates, and context. |
| Agent Operator | Hermes user | Runs ingest/query/lint prompts, verifies outputs, and fixes errors. |
| Review Lead | Manager or subject expert | Checks legal, technical, public-company, HR, or client-sensitive content before sharing. |
| Automation Lead | Technical operator | Creates cron jobs, API connections, sync jobs, backups, and health checks. |
| Privacy Gatekeeper | Owner/manager | Decides what may enter the wiki, what may leave it, and what must be redacted. |
The second Jack Roberts source, Every Hermes Concept explained for Normal People, adds the beginner layer that staff need before they can safely build the knowledge-base system. The earlier manual explains the wiki. This section explains the operating brain around the wiki.
| # | Concept | Plain meaning for staff | Manual action |
|---|---|---|---|
| 1 | Agent, not chatbot | A chatbot answers. An agent can use tools, inspect files, browse, run commands, schedule tasks, and create outputs. | Give Hermes concrete outcomes and permission boundaries, not vague chatter. |
| 2 | Long-term assistant | Hermes is closer to a long-term assistant that learns how you work than a one-off coding tool. | Use Hermes for recurring business operations, not just single questions. |
| 3 | One brain, many mouths | The same Hermes can be reached through Telegram, terminal, dashboard, Discord, WhatsApp, Slack, and other gateways. | Keep instructions consistent across interfaces; do not create separate contradictory workflows. |
| 4 | Where Hermes lives | Hermes can run locally on a Mac/computer or remotely on a VPS. Local is simple and tangible; VPS is always-on but needs security. | Choose local for pilot/training; use VPS only when uptime, remote access, or automation requires it. |
| 5 | OAuth vs API keys | OAuth means sign in and approve access. API keys are secret strings that unlock services. | Prefer OAuth where possible. Never paste API keys into public chats, manuals, or wiki pages. |
| 6 | Model as the brain | Hermes is the agent framework; the selected model is the thinking engine behind it. | Pick the right model for the job: cheap for routine work, stronger for complex/legal/research planning. |
| 7 | Local-hosted models | The model itself can run on your own hardware for privacy, but power is limited by the machine. | Use local models for privacy-sensitive drafts where quality is acceptable; use approved cloud models for heavier reasoning. |
| 8 | Never start from zero | Hermes memory remembers durable user facts and past sessions; the wiki remembers source-grounded external knowledge. | Before asking staff to re-explain context, search memory/session/wiki first. |
| 9 | Character Bible / persona | System/persona instructions define tone, values, style, escalation rules, and how Hermes should behave. | Create a business persona file for staff-facing outputs: plain, careful, source-grounded, no secrets. |
| 10 | Integrations | Hermes becomes more useful when connected to approved tools: calendar, meeting notes, email, docs, drives, CRM, websites. | Connect only approved sources and document each connector in the wiki. |
| 11 | Computer access | When Hermes runs on a computer, it can read/write files, use browser tools, run shell commands, and produce PDFs. | Keep a clear working directory and backup before allowing file-changing actions. |
| 12 | MCP connectors | MCP is a standard way to give Hermes structured access to external tools. | Use MCP for repeatable connectors, but test each one with least-privilege access first. |
| 13 | Skills as muscle memory | Skills are reusable workflows Hermes can load when a task repeats. | Turn recurring staff processes into skills or SOP pages, not scattered chat history. |
| 14 | Slash-command controls | Commands such as queue, background, stop, reset, compress, and status control the session. | Train staff on these commands before allowing autonomous workflows. |
| 15 | Safety and house rules | Agents are powerful; give the least access needed and keep secrets out of memory/wiki/chat. | Use the privacy gate before connecting email, drives, websites, CRM, or payment systems. |
| 16 | North Star / goals | Instead of one question at a time, Hermes can organize work around a goal and break it into steps. | Use goal prompts for projects: launch a page, prepare a dossier, build a source library. |
| 17 | Subagents | Hermes can split work among smaller agents working in parallel. | Use subagents for research batches, audits, and parallel content review; verify their outputs. |
| 18 | Cron / heartbeat | Scheduled jobs let Hermes check or do things daily, weekly, or after a delay. | Use cron for briefings, lint checks, backups, and approved source ingestion. |
| 19 | Token and cost discipline | Every request has overhead; long contexts, wrong models, and runaway jobs waste money. | Compress/reset sessions, choose model tiers carefully, and keep cron prompts focused. |
| 20 | Operating system | Hermes is not just chat; it can become the interface across business knowledge, agents, tools, and workflows. | Design the system as an operating layer, with rules, ownership, backups, and review. |
| 21 | One brand / one operating brain | Hermes, code agents, wiki, notebooks, meetings, CRM, and websites should work under one governed system. | Centralize source trails and procedures so staff do not build isolated mini-systems. |
This section turns the beginner tutorial into daily staff behaviour. The point is to make Hermes useful without letting it become messy, expensive, or unsafe.
| Control | Use | Staff warning |
|---|---|---|
| Reset / new session | Start clean when context is stale or confused. | Use before major new projects to avoid wrong assumptions. |
| Compress | Summarize long context so the session can continue. | Good for long builds, but verify important details survived. |
| Stop | Interrupt a bad or unsafe run. | Use immediately if Hermes starts changing the wrong files or exposing private data. |
| Queue | Line up a follow-up prompt for the next turn. | Do not queue conflicting instructions. |
| Background | Run a separate non-blocking task. | Do not use for sensitive writes unless the prompt is very specific. |
| Cron | Schedule recurring work. | Only create cron jobs with self-contained prompts and privacy limits. |
| Subagent/delegation | Split parallel research or review tasks. | Subagent claims must be verified before publication. |
Use Hermes as an agent, not a chatbot.
Outcome wanted: [PDF / wiki ingest / source note / website update / CRM dossier / briefing]
Source lane: [meeting / email / document / video / article / SOP]
Privacy level: [public-share / internal / private / review-required]
Skills to use: [company-knowledge-wiki, youtube-content, pdf-generation, etc.]
Boundaries: do not store secrets; do not publish externally without approval; cite sources; verify the result.
Report back with files changed, live links if any, and review flags.The second video is especially useful because it explains why the operating system must be governed. Hermes becomes powerful when connected to tools, but every connection creates responsibility.
| Question | Yes/No | Action |
|---|---|---|
| Does this connector expose private or client data? | If yes, owner/privacy approval required. | |
| Can it write, send, delete, post, buy, or change records? | Start read-only or require explicit approval per action. | |
| Is the connector needed for the current workflow? | If no, do not connect it. | |
| Is there a source note or SOP for how it is used? | If no, create one before automation. | |
| Can the output be verified? | If no, do not automate it yet. |
The self-improving knowledge base should not become an uncontrolled memory dump. The beginner tutorial adds the missing operating rules: understand the agent, pick the right brain, connect only the right tools, schedule only safe recurring jobs, and keep the wiki as the source-grounded layer that staff can audit.
Use one clear root folder. Recommended default:
~/knowledge-wikiInside it, create this structure:
knowledge-wiki/
├── SCHEMA.md
├── index.md
├── log.md
├── README.md
├── raw/
│ ├── articles/
│ ├── transcripts/
│ ├── meetings/
│ ├── emails/
│ ├── documents/
│ ├── videos/
│ └── assets/
├── entities/
│ ├── people/
│ ├── companies/
│ ├── projects/
│ └── places/
├── concepts/
├── operations/
│ ├── sops/
│ ├── checklists/
│ └── automations/
├── comparisons/
├── queries/
├── source-notes/
├── reviews/
└── _archive/hermes --version
hermes doctor
hermes status --all
hermes tools list
hermes skills listIf this is a messaging-platform Hermes, restart the gateway after config/tool changes:
hermes gateway status
hermes gateway restartmkdir -p ~/knowledge-wiki/{raw/{articles,transcripts,meetings,emails,documents,videos,assets},entities/{people,companies,projects,places},concepts,operations/{sops,checklists,automations},comparisons,queries,source-notes,reviews,_archive}Add this line to ~/.hermes/.env or the active Hermes profile env file:
WIKI_PATH=/Users/YOUR-USER/knowledge-wikiOn Chris's Mac, the path pattern will normally be:
WIKI_PATH=/Users/macfebruary-20-2026/knowledge-wikihermes gateway restart
# or, for terminal sessions, exit and reopen hermescd ~/knowledge-wiki
git init
git add SCHEMA.md index.md log.md README.md operations source-notes entities concepts comparisons queries
git commit -m "init: create knowledge wiki structure"~/knowledge-wiki.raw/assets/.Create SCHEMA.md first. Staff and agents must obey it.
# Knowledge Wiki Schema
## Domain
This wiki stores approved operational knowledge, source notes, meetings, research, CRM-adjacent context, public-policy notes, marketing ideas, and staff procedures for Chris Anderson's business ecosystem.
## Hard Rules
- Never store passwords, API keys, recovery codes, bank credentials, or private login details.
- Raw sources are immutable. Do not edit raw files after capture.
- Every non-raw page must have YAML frontmatter.
- Every claim that may be disputed must cite a source file or URL.
- Every new or updated page must be added to index.md.
- Every ingest, query worth saving, lint, and archive action must be logged in log.md.
- Use [[wikilinks]] to connect pages.
- Use confidence labels: high, medium, low.
- Mark contradictions instead of hiding them.
## Frontmatter
---
title: Page Title
created: YYYY-MM-DD
updated: YYYY-MM-DD
type: entity | concept | operation | comparison | query | source-note | review
tags: [approved-tag]
sources: [raw/path/or/source-note]
confidence: high | medium | low
contested: false
---
## Approved Tags
- ai-operations
- staff-training
- marketing
- legal-adjacent
- public-company
- crm
- property
- mining
- restaurant
- website
- automation
- source-watch
- privacy
- finance
- policy
- meeting
- email
- youtube
- document
- procedure
## Page Rules
- Create a page when a person/company/project/concept is central to one source or appears in two or more sources.
- Add to an existing page when the topic already exists.
- Split pages over about 200 lines.
- Do not create pages for passing mentions.
- Prefer short, scannable pages with links to deeper pages.
## Contradictions
When sources disagree:
1. Keep both claims.
2. Note date, source, and context.
3. Add contested: true.
4. Add a "Contradictions / open questions" section.
5. Ask the owner/review lead before public use.
# Knowledge Wiki Index
> Every wiki page must be listed here with a one-line summary.
> Last updated: YYYY-MM-DD
## People
## Companies
## Projects
## Concepts
## Operations / SOPs
## Comparisons
## Saved Queries
## Source Notes
# Knowledge Wiki Log
> Append-only record of actions.
> Format: ## [YYYY-MM-DD] action | subject
## [YYYY-MM-DD] create | Wiki initialized
- Created folder structure.
- Added SCHEMA.md, index.md, log.md, README.md.
- Owner approval: pending/approved.
# Knowledge Wiki
This is a private source-grounded knowledge base for staff and Hermes agents.
Start here:
1. Read SCHEMA.md.
2. Read index.md.
3. Check recent log.md entries.
4. Save raw sources before creating analysis pages.
5. Never store secrets.
Create a dedicated Hermes skill so every agent follows the same process. Skill name suggestion:
company-knowledge-wiki---
name: company-knowledge-wiki
description: Use when reading, querying, ingesting, maintaining, linting, or publishing from the company knowledge wiki.
tags: [wiki, knowledge-base, operations, staff]
---
# Company Knowledge Wiki
## Trigger
Use this skill when the user mentions the wiki, knowledge base, source notes, meeting notes, staff manual, CRM context, business research, or asks "what do we know about...".
## Location
WIKI="${WIKI_PATH:-$HOME/knowledge-wiki}"
## Orientation - mandatory every session
1. Read $WIKI/SCHEMA.md.
2. Read $WIKI/index.md.
3. Read the last 30 entries of $WIKI/log.md.
4. Search existing pages for the topic before creating anything new.
## Ingest workflow
1. Capture raw source into raw/ with source URL, date, and hash.
2. Create a source note under source-notes/.
3. Identify entities, concepts, projects, and claims.
4. Update existing pages before creating new pages.
5. Add wikilinks and confidence labels.
6. Update index.md.
7. Append log.md.
8. Report every file created/updated.
## Query workflow
1. Orient first.
2. Read relevant pages.
3. Answer with source-page citations.
4. If the answer is reusable, save it under queries/ and update log.md.
## Public output rule
Before publishing or sharing externally:
- Remove private contact details unless approved.
- Remove secrets and credentials.
- Mark uncertain claims.
- Include source links or source-note references.
- Ask for human review on legal, finance, public-company, HR, health, and family/custody topics.
Ask Hermes:
Create a new Hermes skill called company-knowledge-wiki using the manual's skill content. Save it under ~/.hermes/skills/company-knowledge-wiki/SKILL.md. Then list the skill and confirm it loads.Verification:
hermes skills list | grep company-knowledge-wikiEvery source must enter through a lane. This stops staff from mixing private notes, public articles, and unverifiable social content into one messy folder.
| Lane | Examples | Raw folder | Review needed |
|---|---|---|---|
| Meetings | Granola, Teams, Google Meet, Zoom notes | raw/meetings | Yes if client/legal/HR |
| Approved email threads or summaries | raw/emails | Yes; redact private info before public output | |
| Documents | PDFs, scans, contracts, letters, reports | raw/documents | Yes; legal/financial sensitivity |
| Videos | YouTube, TikTok, Instagram, Facebook | raw/videos or raw/transcripts | Fact-check before treating claims as true |
| Articles | Web pages, blogs, news, policy docs | raw/articles | Source-quality review |
| CRM context | Referral notes, public professional bios | entities/people + source-notes | Keep private contact data internal |
| Operations | SOPs, checklists, staff instructions | operations/sops | Manager approval before staff rollout |
Source title:
Source URL or origin:
Date captured:
Captured by:
Why this matters:
Public/private/internal:
Reliability: high / medium / low
Known caveats:
Related people/companies/projects:
Recommended wiki pages to update:
source-notes/.Please ingest this source into the company knowledge wiki.
Source path:
[insert path]
Context:
[why this matters]
Follow company-knowledge-wiki exactly:
- orient first by reading SCHEMA.md, index.md, and recent log.md;
- save or verify the raw source;
- create/update source note;
- update existing pages before creating new pages;
- add wikilinks and confidence labels;
- update index.md;
- append log.md;
- report every file changed.
Do not publish externally. Do not store secrets.Use this when staff want Hermes to answer from the wiki instead of general memory.
Use the company knowledge wiki to answer this.
Question:
[insert question]
Required steps:
1. Read SCHEMA.md, index.md, and recent log.md.
2. Search the wiki for relevant pages.
3. Read the relevant pages before answering.
4. Cite the wiki pages and source notes used.
5. Separate confirmed facts from assumptions.
6. If the answer would be useful later, save it under queries/ and update log.md.The source video that triggered this manual is a good example: first capture the transcript, then turn it into an internal guide. Do not rely on the title alone.
python3 ~/.hermes/skills/media/youtube-content/scripts/fetch_transcript.py "YOUTUBE_URL" --timestamps > raw/transcripts/source-name-transcript.jsonmkdir -p /tmp/youtube_transcript
cd /tmp/youtube_transcript
yt-dlp --skip-download --write-auto-sub --write-subs --sub-lang en --sub-format vtt -o '%(id)s.%(ext)s' 'YOUTUBE_URL'Ingest this YouTube transcript into the wiki as a source.
Create:
- raw transcript file record;
- source note with URL, title, channel, date captured, limitations;
- concept page if the idea is central;
- operations/SOP page if the source contains a repeatable workflow;
- index and log updates.
Keep claims source-grounded. Do not treat a creator's opinion as proven fact.raw/meetings/YYYY-MM-DD-meeting-topic.md.---
title: Meeting - [topic]
date: YYYY-MM-DD
participants: [names or roles]
source_type: meeting
privacy: internal
confidence: medium
---
## Purpose
## Decisions
## Action items
## Open questions
## Pages to update
Once connectors are approved, create a daily job that checks the meeting-notes export folder and asks Hermes to ingest only new approved files.
Schedule: every weekday at 9:00 AM
Prompt: Check the approved meeting-notes folder for new files since the last run. For each new file, ingest it into the company knowledge wiki using company-knowledge-wiki. Do not publish externally. Report files updated.AI-Knowledge-Approved.Title: Email thread - [topic]
Date range:
Participants:
Mailbox/label:
Reason saved:
Private details removed:
Key facts:
Decisions:
Follow-up required:
Related wiki pages:
Check only the approved email label/folder named AI-Knowledge-Approved. Summarize new threads into source notes without storing passwords, payment details, private family details, or unnecessary personal data. Update project/company pages only where the thread contains durable business facts. Append log.md.raw/documents/.# If text-based PDF
python3 -m pymupdf gettext input.pdf -o extracted.txt
# If using OCR/document extraction tools, save output as:
raw/documents/YYYY-MM-DD-document-name.extract.txtExtract the operational facts from this document for the wiki.
Separate:
- confirmed facts;
- deadlines;
- people/entities;
- obligations/requests;
- risks;
- questions for human review.
Do not provide legal advice. Update the wiki with confidence labels and source references.Automation should be added only after the manual process works. Start small and add one lane at a time.
| Job | Schedule | Purpose | Risk |
|---|---|---|---|
| Daily meeting ingest | Weekdays 9:00 AM | Process approved new meeting summaries. | Medium - privacy/consent. |
| Weekly wiki lint | Friday 4:00 PM | Find broken links, missing index entries, low-confidence pages. | Low. |
| Weekly source digest | Monday 8:00 AM | Summarize new approved sources and ask what to ingest. | Low/medium. |
| Monthly backup check | 1st day monthly | Verify wiki backup, Git status, and archive readability. | Low. |
hermes cron create '0 9 * * 1-5'
# Then paste a self-contained prompt with source folders, wiki path, privacy rules, and delivery target.You are maintaining the company knowledge wiki at $WIKI_PATH.
Task: ingest approved new meeting files only.
Rules:
- Read SCHEMA.md, index.md, and recent log.md first.
- Process only files in raw/meetings/_approved-inbox/.
- Do not process private/unapproved folders.
- Do not store secrets.
- Update source notes, relevant pages, index.md, and log.md.
- If a file contains legal, HR, medical, family/custody, or financial advice, mark it review-required and do not summarize sensitive details.
- Deliver a concise report with files changed and review flags.[[wikilinks]].Run a health check on the company knowledge wiki.
Check for:
- broken wikilinks;
- orphan pages;
- pages missing from index.md;
- invalid frontmatter;
- tags not in SCHEMA.md;
- source notes missing for raw files;
- pages over 200 lines;
- contested or low-confidence pages needing review.
Report issues by severity and append the lint result to log.md.The wiki is private. Public PDFs are outputs created from reviewed, redacted wiki material.
CHROME='/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
"$CHROME" --headless --disable-gpu --no-sandbox --print-to-pdf=/tmp/manual.pdf file:///tmp/manual.htmlFor Managing Expectations, store public downloads under:
assets/downloads/Then link from a resource page or article after approval.
Create a new company knowledge wiki at ~/knowledge-wiki using the LLM Wiki pattern. Build the folder structure, SCHEMA.md, index.md, log.md, README.md, and an operations/sops folder. Use privacy-first rules: no credentials, no secrets, no private-public mixing. After creating it, verify files exist and report the structure.Use youtube-content and company-knowledge-wiki. Fetch the transcript for [URL], save it under raw/transcripts, create a source note, then turn the useful procedure into operations/sops/[slug].md. Update index.md and log.md. Include source URL and limitations.Create a staff SOP from these source notes. The SOP must include purpose, scope, roles, prerequisites, exact steps, verification, escalation, privacy rules, and a checklist. Save it under operations/sops, add it to index.md, and log it.Answer using only the company knowledge wiki and clearly mark anything not found. Cite page names/source notes. If the answer requires legal/financial/regulatory judgment, state that human review is required.Draft a public PDF from approved wiki pages only. Remove private names, credentials, internal paths not needed by readers, and sensitive details. Include source links and caveats. Save HTML and PDF. Verify PDF text contains the table of contents and all major headings.| Phase | Time | Outcome |
|---|---|---|
| Preparation | Day 0 | Owner approves scope, access, and first pilot domain. |
| Setup | Day 1 | Hermes checked, folder created, Obsidian connected, schema written. |
| Manual pilot | Days 2-7 | 10-20 sources ingested manually; staff trained on source notes. |
| Quality gate | End of Week 1 | Lint report, duplicate cleanup, tag cleanup, privacy review. |
| First automation | Week 2 | One low-risk cron job added. |
| Operations rollout | Weeks 3-4 | SOPs, query prompts, publishing workflow, backups. |
| Scale | Month 2+ | Add approved email/meeting/document lanes and department-specific pages. |
echo $WIKI_PATH in the same environment where Hermes runs.~/.hermes/.env or the active profile's env file.Please ingest this approved source into the company knowledge wiki. Orient first, create/update the source note, update relevant pages, add wikilinks, update index.md, append log.md, and report every changed file. Do not store secrets or publish externally.