Skip to content

Expose safe group creation to Hermes agents through agent-control #1385

Description

@Datawav

Problem

Hermes agents can participate in existing Marmot groups, but they cannot initiate a new group. The underlying MDK app runtime already creates a locally canonical group from a name, initial members, and optional description, and it also has a variant for an initial image. That capability is not carried through the local agent-control protocol or registered as a Hermes model tool.

This prevents an agent from completing workflows such as “start a group for this project, title it, describe its purpose, and invite these accounts” without asking a person to create the group in another client first.

Current boundary

  • MarmotAppRuntime::create_group already accepts an account reference, group name, initial member list, and optional description. The adjacent API supports an optional initial image.
  • The AgentControlRequest surface exposes account operations and GroupInfo, but no group-creation request.
  • The Hermes plugin registration registers message deletion and history tools only.
  • MDK already validates group profile fields at the app boundary, including a 256-byte name limit and a 4096-byte description limit (validation).

Requested behavior

Add a model-callable Hermes tool backed by a typed marmot.agent-control.v2 request that lets the selected local Marmot account create a group with:

  • a required group name;
  • an optional description;
  • a bounded list of initial member account references; and
  • a caller-supplied idempotency key so retrying an uncertain request cannot create duplicate groups.

Return the durable group ID and distinguish successful local group creation from incomplete Welcome delivery. Do not report every invite as delivered merely because the group itself was created.

Keep initial group images and additional policy components out of the first tool unless their secret-bearing capability and authorization boundaries are resolved explicitly; #1253 tracks the adjacent group-image capability-key boundary.

Acceptance criteria

  • agent-control defines a typed group-creation request and response with account, name, optional description, initial members, and idempotency key.
  • wn-agent validates the selected account, normalizes and bounds member inputs, uses the existing app-runtime creation path, and returns the created group ID.
  • A repeated request with the same account and idempotency key returns the original result and never creates a second group; reuse with conflicting inputs fails closed.
  • The response represents Welcome delivery separately from local creation, including pending or failed invite delivery without converting a created group into an ambiguous generic failure.
  • The Hermes integration registers a clearly named model tool with a closed JSON schema and routes it through the live adapter/control client.
  • The tool result contains enough routing data for Hermes to address the new group, but does not expose MLS secrets, image keys, plaintext content, or other capability material.
  • Empty-member groups are handled deliberately, duplicate/self member inputs have deterministic behavior, and invalid/oversized names, descriptions, member lists, and account references return stable errors.
  • Tests cover control-protocol serialization, connector dispatch, idempotent retry and conflicting reuse, empty and multi-member creation, partial Welcome delivery, and a live Hermes tool-registration probe through the real plugin entrypoint.
  • Connector and Hermes documentation explain the tool, its metadata limits, authorization boundary, idempotency behavior, and the difference between group creation and invitation delivery.

Related work

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions