protagonista

I’d like external agents to hand tasks to workspaces on my Unraid box through Agent Relay, using a thin external bridge connected as a Relay remote, without maintaining a plugin fork or adding another task store. What stops me today. A remote can only read its inbox, list contacts and send direct messages (RelayMcpTools::EXTERNAL_TOOLS). DMs seem deliberately wrong for this: recipients are told to treat their contents as untrusted data rather than instructions, and DMs have no request lifecycle or cancellation. What I actually want to use is the existing relay_request mechanism: a request to a topic’s assigned actor, with its pending → acknowledged → resolved/failed/timed_out lifecycle and actor auto-launch. As far as I can tell from the current source, remotes can’t use it. The narrow ask: could an administrator grant a specific remote permission to call relay_request and relay_request_status for specific topics? For example, this could be configured on the remote’s row under Settings → Agent Relay and default to disabled. That seems to preserve Relay’s existing trust model: The assigned actor remains the only workspace allowed to act on the request, and it still decides what to do. The administrator explicitly decides which remote can submit requests to which topics. Direct messages remain untrusted and unchanged. The existing request file remains the authoritative record; an external bridge doesn’t need its own task database. Topics provide stable external targets even when the workspace/session assigned as actor changes. My immediate use case is an A2A bridge: an A2A task could map directly to a Relay request ID and map the Relay request lifecycle onto A2A task states. But the proposed permission isn’t A2A-specific; it would just expose the existing actionable-request primitive to explicitly trusted remotes. Two optional follow-ups would make that integration more complete, but aren’t necessary for the basic use case: Sender-side cancellation (relay_cancel_request, or similar), with a cancelled state visible to the actor. Per-token rather than per-IP rate limiting, since multiple remote identities behind one bridge host currently share the same 30/minute budget. I’m happy to test this against a pre-release and can sketch the grant data shape if useful. I’d also be interested if there’s a constraint in the Relay design or the remote-client ADR that makes exposing requests to authorized remotes undesirable; there may be context that isn’t visible from the public repository.

yeah, Docker + MCP may actually fit my use case better than native Hermes support. I'll try it and see how it works in practice

Would you consider adding ⁠Hermes Agent as a supported agent? My use case is slightly different from the other coding agents: I’d use Hermes as an orchestration/handoff layer on the Unraid box. A Hermes agent running locally could receive a task or message and hand the actual coding work to Claude Code (claude -p) or Codex, both already managed by this plugin. That would let the Unraid machine own its own work: remote agents/users send Hermes a task, Hermes can inspect the local environment, and it invokes the appropriate local coding agent rather than giving the remote side SSH access to the box. Hermes keeps its state under ~/.hermes/, so it seems like it might fit the persistence model you’ve already built for the other agents. It’s Python/uv rather than an npm-only install, but I saw the work you did to generalize installers for Goose, so I thought it might now be a reasonable fit. Happy to test it on my Unraid box if you’re interested in adding it.