Unique Feature

Hermes Sidecar

A second front door: talk to your LifeOS as an agent — one brain, same rules, new channel.

Hermes is an open agent framework that runs beside your LifeOS and mounts it. Same constitution, same identity, same skills, same understanding of what is sensitive — reachable as its own agent instead of only through a terminal session. It is not a second assistant with its own memory and its own opinions. There is one brain. The sidecar is another way into it.

Why it exists

Every channel bot ever written re-implements the assistant badly: its own prompt, its own memory, its own drift. You end up with three half-copies of yourself that disagree.

The sidecar inverts that. Hermes supplies the engine and the channels; LifeOS supplies the identity, the rules, and the knowledge. When Hermes rots or something better appears, the mount moves — and nothing about who your assistant is has to be rewritten.

The idea that makes it safe

A full mount sounds alarming until you notice what LifeOS skills actually are. They are CLI-first: the real work happens in a small deterministic program that reads its own credentials in its own memory and prints a result.

So the agent invokes the tool and receives the answer. The token does its job without ever entering the model’s context. That single property is what makes it safe to hand an agent the whole tree: a successful prompt injection finds nothing to exfiltrate, because the secrets were never in the conversation.

One message, end to endwhy the answer travels and the credentials don't
AskFrom a chat channel: "what's on my calendar tomorrow?"
GuardThe read guard checks the tool call — skills yes, credential files never.
Skill CLIA small deterministic program reads its own token in its own memory and queries the calendar.
AnswerTomorrow's events come back as text. The token never entered the conversation.
Same brain, same rules: the reply sounds like your assistant because it is your assistant — one identity, one constitution, reached through a different door.

How the integration works

One installer command renders the sidecar from your live LifeOS sources. It generates the agent’s identity file from your constitution and identity, installs and enables a guard plugin with a generated policy, and points the agent at your skills read-only. Re-run it after you change your identity or rules, and the sidecar stays current; a check mode reports drift without writing anything.

Reading is not the security boundary — you want the agent to read everything. The boundary is what can leave, and what can be reached. Four controls hold it: a read guard that vetoes any tool call touching credential material (symlink-, case-, and traversal-aware); a write sandbox that keeps the LifeOS tree read-only at the filesystem level; a typed write API so persistence goes through the same tier-gated memory path a terminal session uses; and provenance tainting, so content from untrusted sources can never silently escalate into privileged tool calls. Every block the guard makes is recorded in an audit trail you can review after the fact.

Code and content never mix. Everything the sidecar ships is install-generic — no identity, no personal paths, no instance literals. Everything personal is read from your own install at render time and written outside the LifeOS tree. The same code produces a correctly personalized sidecar on every machine, with no per-install editing.

Where it fits

The sidecar is optional, and declining costs nothing — LifeOS does not depend on it in any way. Removing it deletes its own directory and leaves no trace in your install. What it buys while present is a second front door: the same assistant, bound by the same constitution, one mount away from wherever agents can go next.