Hermes sidecar vs terminal agent: no guidance on which surface to use for what

[theNetworkChuck]

The gap

The sidecar docs explain how to install and run it, and are admirably honest about the security controls and their limits. What they don't explain is what it's for relative to the terminal-based agent.

Today the boundary reads as "the sidecar is for remote communication," but that leaves the practical questions open:

• What can the sidecar actually do that the terminal agent can't, and vice versa?
• What are its real capability limits, as opposed to its enforcement limits?
• Given a task, which surface should I reach for?

HermesSidecar.md has an ## Honest limits section, but it scopes to enforcement and isolation (guard plugin, deny rules not being a sandbox, plugins being opt-in). That's a different question from capability lanes.

Why it matters

Without stated lanes, every adopter re-derives the boundary by trial and error, and lands somewhere different. For anyone teaching LifeOS to a broader audience, "it depends" is a hard answer to give.

Suggested shape

A short section in HermesSidecar.md covering:

1. Capability surface per lane — what the sidecar can do, what the terminal agent can do, where they overlap.
2. Limitations per lane — the honest "don't try this here" list, separate from the security posture.
3. When to use which — a handful of representative tasks routed to a lane, with the reasoning.

Happy to draft this against my own install if that's useful.

[Piroshki]

Agree with this. I've finally figured it out, but it took a while to figure out the lanes.

[danielmiessler]

Landed: a "Which surface for what" section with a table of where, writes, gates and memory, limited to what the code enforces. Next release. Thanks.