Designing a Unified Multi-Platform Agent

Bringing Module 6 Together

You now have the individual pieces: the gateway connecting multiple platforms (Lesson 16), voice and cron adding new interaction modes (Lesson 17). This lesson is about design, not new configuration: how do you decide what a unified multi-platform agent should actually look like, rather than just turning on every adapter with default settings?

The Core Principle: Shared Knowledge, Scoped Capability

flowchart TB
    subgraph SHARED["Shared across every surface"]
        MEM[("Memory, Module 4")]
        SKILLS[("Skills, Module 4")]
    end

    CLI["CLI / TUI\n(you, full trust)"] --> SHARED
    TG["Private Telegram\n(founders only)"] --> SHARED
    DC["Public Discord\n(community server)"] --> SHARED

    CLI -.tools: unrestricted.-> T1["Toolset: broad"]
    TG -.tools: broad, minus destructive ops.-> T2["Toolset: moderate"]
    DC -.tools: narrow, read-only-leaning.-> T3["Toolset: restricted"]

    style SHARED fill:#fff7ed,stroke:#f59e0b,color:#0F172A
    style CLI fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style TG fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style DC fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style T1 fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style T2 fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style T3 fill:#f0fdf9,stroke:#0D9488,color:#0F172A

What makes the agent useful, its accumulated memory of your projects and preferences, its library of learned skills, should generally stay unified across every surface. That’s the entire value proposition of a persistent agent (Module 4): fragmenting memory per platform would mean re-teaching the agent the same things repeatedly, defeating the point.

What makes the agent safe should not be unified by default. Toolset scoping (Lesson 7.3), applied per platform (Lesson 16’s per-adapter tool configuration), is the lever: a private, trusted surface can reasonably run a broad toolset, while a public-facing one should run a deliberately narrower one. Module 7 goes deep on exactly how to reason about these restrictions; this lesson is about recognizing that the decision needs to be made per surface, not applied uniformly.

# ~/.hermes/config.yaml
gateway:
  telegram:
    enabled: true
    platform_toolsets:
      cli: ["filesystem", "shell", "web_search", "code_execution"]
  discord:
    enabled: true
    platform_toolsets:
      cli: ["web_search"]           # read-only-leaning, no execution or filesystem access
    disabled_toolsets: ["code_execution", "shell", "filesystem"]

A Sensible Rollout Order

Adding every platform at once, on an agent whose core configuration you haven’t yet validated, compounds every possible failure mode simultaneously. A more tractable order:

1. CLI only (Modules 1-5). Validate model choice, tool behavior, memory, and skills in a fully controlled, single-user environment.
2. One trusted platform (Lesson 16), typically a private chat you and a small trusted group use. Confirm gateway behavior, session continuity, and delivery formatting.
3. Cron for that trusted platform (Lesson 17). Confirm scheduled, proactive behavior works before anyone outside your control can trigger the agent.
4. A public or lower-trust platform, with a deliberately narrower toolset from the start, not the same configuration as step 2, scaled down later.

Common Design Mistakes

• Copying the private-chat toolset to a public one “to start.” The intention to restrict it later rarely survives contact with a working, permissive deployment, restrict from the beginning.
• Assuming memory unification means no per-platform context at all. It’s reasonable for the agent to know it’s currently in a Discord community server versus a private DM, and to adjust tone or verbosity accordingly, unified memory doesn’t mean identical behavior everywhere.
• Skipping hermes gateway status checks after any config change. A toolset restriction typo can silently disable more (or less) than intended; verify after every change, the same diagnostic-first habit from every earlier module.

Exercise: sketch (on paper or in a text file) the toolset restrictions you’d apply across three hypothetical surfaces for your own use case: a private CLI session, a semi-trusted internal team channel, and a public-facing surface. For each, list which of the built-in tool categories from Lesson 8 you’d enable, and justify the public surface’s restrictions specifically, that justification is the input Module 7 will formalize into an explicit guardrails policy.