Agent-readable docs index: /llms.txt. Full docs in one file: /llms-full.txt. Download /docs.zip to grep all markdown files locally.
Agent profiles are not a filesystem sandbox. A Hermes profile isolates config, memory, and sessions — but the agent still has the operating-system user's full file access. If two employees' agents share one uncontained host, each can read the other's vault. The profile boundary is not the tenant wall.
The tenant wall in this system is physical: it holds only where a personal agent can literally reach one person's files and no one else's. So a personal agent runs only in one of these two places:
On the employee's own device
Against their synced vault. This is the default and the simplest safe option — the OS account already scopes file access to that person.
Server-side, in a container
A container (e.g. a Hermes Docker terminal backend) that mounts only that person's compiled vault. The mount is the boundary.
Never co-host multiple employees' agent profiles side-by-side on one uncontained host. That is the single configuration that turns a structural guarantee back into a promise an agent could break.
Want the container branch end-to-end? The two-box reference deployment is the worked example: chat-only users, one hermes container per person, the sync plane, sizing, and a full runbook.

Why the compiler doesn't save you here

The compiler guarantees that a person's vault contains only what they may see. That guarantee is about what gets written to disk. It says nothing about what a process running as your OS user can open() elsewhere on that disk. Keeping agents to one-vault-per-host (device or container mount) is what preserves the boundary at runtime.
Remote access does not change this rule. brain mcp-router is not a personal agent and holds no vault; each brain mcp --http process serves exactly one person's compiled vault and answers only to that person.

Server-side jobs are different

The server assistant agent is supposed to have full master access — it ingests transcripts, routes knowledge, and maintains dashboards across all spaces. Run it with master access, on cron and on Inbox drops. The deployment rule above is about personal agents, which must never see more than their one slice.
The mechanical half of that server-side loop is a single command on a schedule:
# refresh everyone: write back edits, sweep drafts, recompile, triage doctor findings (+ reindex)
# flock -n: one cycle at a time — an overlapping tick skips rather than racing the run in flight
*/10 * * * * flock -n /var/lock/brain-cycle brain cycle --master /srv/brain/master --out /srv/brain/compiled --index --json >> /var/log/brain-cycle.log 2>&1

# integrity check — nonzero exit on any error finding
0 * * * * brain doctor --master /srv/brain/master --out /srv/brain/compiled --json >> /var/log/brain-doctor.log 2>&1
brain cycle runs write-back → promotion sweep → recompile → triage in the one order that's safe; a held edit or a failed write-back exits nonzero without halting the refresh. The closing triage step routes actionable brain doctor findings to each responsible person as a rolling Inbox digest their agent processes (see brain triage), so content maintenance closes its own loop instead of waiting for someone to read the doctor log. The --index flag also refreshes each vault's search index — worth it when agents run server-side (container mounts) rather than on employee devices; an index failure only warns, it never fails the cycle. brain doctor is the read-only health check — point it at both the master and the compiled root so it can catch a _meta/ leak or a crashed-compile tombstone before anyone syncs.
A server that holds the master needs a backup story too — the master vault is the one thing nothing can rebuild. Backups & Restore covers what to protect, the encrypted-offsite scripts in deploy/, and the restore drill for each failure.
Server-side indexing needs an embedding provider in the cron environment, and its cache lives at _meta/cache/ so a chunk shared across people embeds once. If no provider is set, --index still builds keyword-only indexes. Enabling a provider later does not backfill vectors into an existing index — run brain index --vault <path> --full once per vault (see the reference deployment). Note that configuring a provider means note text is sent to that endpoint — use a self-hosted or company-proxy endpoint if that matters.
Powered byHolocron