You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
Model Marmot groups as durable coding-session lanes with /new rotation #792 describes OpenCode-specific bidirectional session provisioning, including a TUI-created session materializing a Marmot group. This issue provides the narrower shared control-plane and Hermes-agent capability; it does not implement OpenCode session synchronization.
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_groupalready accepts an account reference, group name, initial member list, and optional description. The adjacent API supports an optional initial image.AgentControlRequestsurface exposes account operations andGroupInfo, but no group-creation request.Requested behavior
Add a model-callable Hermes tool backed by a typed
marmot.agent-control.v2request that lets the selected local Marmot account create a group with: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-controldefines a typed group-creation request and response with account, name, optional description, initial members, and idempotency key.wn-agentvalidates the selected account, normalizes and bounds member inputs, uses the existing app-runtime creation path, and returns the created group ID.Related work