The Agent Beyond the Terminal

Hermes Agent becomes a different kind of system when the same learning loop can receive a message from a chat platform, run a scheduled routine, or switch model providers without losing its scope and controls. This chapter follows that operational lifecycle: how an external message is routed to the right session, how profiles keep identities separate, how cron extends work across time, and what provider portability changes. The aim is to judge continuity as infrastructure rather than assume that “available everywhere” means “one unrestricted identity everywhere.”

A message becomes a scoped agent session

A gateway receives a raw event from a platform adapter and normalizes it into a common message shape. Before Hermes asks the model to do anything, the gateway resolves the conversation context: which profile is active, which platform and chat are involved, whether the conversation is private or a group, and whether a thread or topic matters. That context becomes a session key rather than an informal label.

Authorization happens before the agent turn. Hermes can use platform-specific allowlists, global allowlists, an allow-all setting, or a pairing flow in which an operator approves a one-time code. The default posture is denial when no authorization path is configured. This order matters: a learned user profile or a powerful skill should not become available merely because an unknown sender can reach a bot endpoint.

Once the event is authorized, the gateway creates or resumes an AIAgent for that scoped session. If the session is already running, a new message may be queued or used to interrupt the current work; commands such as stop or approval need a path that can reach the busy agent. The agent executes through the same loop described earlier, with the platform adapter receiving progress and the final response. Delivery then returns through the originating adapter or, where configured, to another target.

sequenceDiagram participant U as User or schedule participant A as Platform adapter participant G as Gateway participant S as Profile and session store participant C as AIAgent loop participant P as Provider runtime participant D as Delivery target U->>A: Inbound message or trigger A->>G: Normalize event G->>S: Authorize and resolve scoped session S-->>G: Profile, history, and routing context G->>C: Start or resume turn C->>P: Resolve model and execute work P-->>C: Response and tool evidence C->>S: Persist session and usage C-->>G: Final result G->>D: Deliver to origin or target

The gateway's value is not simply the number of adapters it can load. It gives one agent core a durable ingress and egress path while keeping routing and authority explicit. A Telegram message, a CLI input, and an IDE request can share the same kinds of agent behavior without sharing the same session or permissions by default.

The routing boundary also controls what happens when a session is busy. An incoming message does not simply start a second unconstrained agent against the same conversation. The adapter can queue it and signal an interruption, while the gateway can handle a small set of commands—such as stopping work or answering an approval request—through a path that remains available during the active turn. This preserves the message order and makes a user's attempt to change course part of the session's control flow rather than an accidental competing write.

The same ownership idea applies to delivery.