Hermes Ops

Context

Hermes Ops is a kengdev delivery pattern (and an anonymized mission name), not a public SaaS. The agent lives in messaging, answers internal requests, reads knowledge and CRM, and only runs critical writes after interactive confirmation. EU VPS, full logs, tracked token budget.

Challenge

Hours lost between Slack, CRM and docs. Ownerless requests, lost context, no trail for hand-done actions.

Solution

Intent router → session memory + long facts → RAG → tools (MCP or equivalent) → free reads / write allowlist + confirm → audit log + turn and token caps.

Baseline

Without an agent: ops reply = find the right channel, doc and CRM status. Messaging benchmarks (e.g. ~1.5h/user/week on recaps/search) show where time goes; a custom agent must beat tool-hopping, not “automate everything”.

Results

• Useful first reply in minutes on documented intents
• CRM writes behind confirmation (buttons / thread)
• Traceability: who asked, which tool, which result
• MVP handoff after allowlist scoping (days, not a big bang)

Architecture decisions

• Choice: EU self-host + logs

  Why: Internal data, CRM, chats: sovereignty and audit.

• Choice: Action allowlist + interactive confirm

  Why: An agent without an approval contract is a demo.

  Rejected: Full-access messaging mode on day one

• Choice: Versioned tools (MCP or equivalent)

  Why: Scopes, tests, rollback: a prompt monolith does not scale as a team.

Limits

• Does not replace judgment on pricing, legal or human conflict.
• Without a token-budget owner, multi-turn bills drift.
• Hermes Ops is not the brand logo page: it is a mission pattern.

Checklist to rebuild this

1. List intents (top 20 ops requests)
2. Write the allowlist: auto / confirm / forbidden
3. Wire 1 channel + 1 knowledge source + 1 CRM read tool
4. Add writes one by one with confirm
5. Caps: tool turns, tokens, session length
6. Audit log readable by a non-dev human
7. Escalation runbook (who takes over if the agent blocks)
8. Weekly cost alert with a named owner