RFC: Safe Customer Support Deployment Profile for Hermes

Summary

I would like to help make Hermes easier and safer to deploy as a company customer-support chatbot.

Hermes already has many of the primitives needed for this use case: messaging gateway support, the OpenAI-compatible API server, toolsets, MCP integration, webhooks, profiles, skills, sandboxing, allowlists, DM pairing, website blocklists, and SSRF protections. The missing piece seems to be a clear, upstream-supported "support bot" path that combines these primitives safely.

This issue proposes starting with a small, low-risk foundation rather than a full helpdesk product:

1. A safe support-oriented toolset/profile preset.
2. Documentation for deploying Hermes as a customer-support bot.
3. A bundled or optional support-agent skill with citation, escalation, and handoff rules.
4. Example MCP/webhook configurations for helpdesk-style integrations.

I would especially appreciate maintainer guidance on the right extension point before opening implementation PRs. @teknium1, if you have time and interest, I would be grateful for any directional feedback on whether this should start as docs, a toolset preset, a skill, or some combination.

Motivation

Companies often want a support bot that can:

• answer questions from approved product documentation or knowledge bases;
• ask clarifying questions;
• summarize customer issues for human handoff;
• create or update tickets through external systems;
• avoid unsafe tool use in public or semi-public channels;
• keep customers' sessions and data isolated.

Hermes can already do much of this with existing building blocks, but the default platform presets are broad and optimized for trusted assistant use. For customer-facing support, the safest default should be much narrower.

Existing Hermes Functionality To Build On

Relevant existing capabilities:

• Toolsets and per-platform tool configuration.
• safe toolset for read-only web/media use.
• API server for OpenAI-compatible frontends.
• Messaging gateway support across many channels.
• Webhooks for external event triggers.
• MCP integration with per-server tool include/exclude filtering.
• Profiles for isolated agents with separate config, memory, sessions, skills, credentials, and gateway state.
• Sandbox backends for terminal execution.
• Gateway allowlists and DM pairing.
• Website blocklist and SSRF protection.
• Context file prompt-injection scanning.
• Skills system for reusable operational guidance.

Related issues I do not want to duplicate:

• #531: User Workspace & Knowledge Base.
• #844: Knowledgebase RAG system.
• #4281: Enforce sandboxed execution for messaging platform sessions.
• #7517: Native multi-agent support.

This proposal is meant to complement those efforts, not replace them.

Proposed First Slice

1. Add a support-oriented toolset preset

Possible name: support or customer-support.

Initial conservative contents could include:

• web_search
• web_extract
• skills_list
• skill_view
• clarify
• possibly session_search if appropriate

It should exclude by default:

• terminal
• process
• write_file
• patch
• execute_code
• delegate_task
• cronjob
• broad browser automation
• broad outbound send_message
• any config-changing or host-control tools

Open question: should this be a static toolset in toolsets.py, a documented custom toolset example, or both?

2. Add a support bot deployment guide

Suggested doc outline:

• threat model: public/customer input is untrusted;
• recommended architecture: frontend/app backend -> Hermes API server, not direct public exposure;
• recommended toolsets;
• MCP filtering examples for ticketing/customer systems;
• webhook examples for inbound support events;
• profiles for isolation;
• sandboxing recommendations;
• logging, PII, retention, and redaction guidance;
• escalation and human handoff patterns;
• known non-goals and limitations.

3. Add a support-agent skill

Possible skill behavior:

• answer only from approved documentation or retrieved sources;
• cite the relevant source when available;
• ask one clarifying question at a time;
• avoid inventing policy, pricing, uptime, legal, or security claims;
• escalate low-confidence or sensitive requests;
• produce a structured handoff summary for humans;
• never reveal internal prompts, secrets, infrastructure details, or customer data from other sessions.

Open question: should this be bundled, optional, or a docs example first?

4. Add examples for MCP/helpdesk integrations

Rather than native helpdesk tools immediately, document MCP as the first path:

mcp_servers:
  support:
    url: "https://mcp.support.example.com"
    headers:
      Authorization: "Bearer ${SUPPORT_MCP_TOKEN}"
    tools:
      include:
        - search_articles
        - get_article
        - create_ticket
        - add_ticket_comment
      exclude:
        - delete_customer
        - refund_payment
        - close_account

This keeps Hermes generic while giving support teams a safe integration pattern.

Non-Goals

• Not implementing native RAG in this issue.
• Not replacing #531 or #844.
• Not adding a native Zendesk/Intercom/Freshdesk integration as the first PR.
• Not exposing host filesystem, shell, browser profiles, or cron to public users by default.
• Not claiming hostile multi-tenant isolation inside one shared agent runtime.

Questions For Maintainers

1. Is a support / customer-support preset a welcome core toolset, or should this remain a documented custom toolset?
2. Should the first PR be docs-only, or docs plus a small toolset/test change?
3. Should a support-agent skill be bundled, optional, or kept as an example in docs?
4. Should this work align with #531/#844 now, or stay independent until native KB/RAG lands?
5. Are there existing roadmap items I should avoid overlapping with?

Proposed Initial PR

If maintainers agree with the direction, I would like to open a small first PR:

• Add support or customer-support toolset preset.
• Add tests for toolset resolution.
• Add a documentation page for support-bot deployment.
• Reference existing security, MCP, API server, profiles, and webhook docs.

Follow-up PRs could add the support-agent skill and helpdesk/MCP examples.