Mint and expose broker peer identities automatically #1637

New issue

Closed

opened 2026-08-02 04:43:11 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-02 04:43:11 +00:00

Member

Outcome

Make peer identity an output of broker admission rather than a required operator input.

For the normal collaboration path, the broker mints a short safe identity such as <role>-<ab12>, records it durably, and returns it to the caller. Operators and AOS should not need to invent or coordinate agent ids manually.

Required behavior

An omitted peer id is the normal launch contract.
The broker generates the id from the admitted role plus the canonical dictatable suffix shape.
Collision handling is bounded and deterministic enough to test.
The accepted id is recorded in the broker journal before launch and remains stable for that peer.
Launch responses expose both cluster id and peer id.
List or roster output exposes active peer ids and roles.
Message, logs, stop, and cleanup address peers by the returned id.
Nested peer launches inherit the cluster and receive their own broker-minted ids.
Any retained explicit-id override is an internal or compatibility surface, not required by the ordinary user flow.

Acceptance criteria

A peer launches successfully with no agent-id argument.
Two peers of the same role in one cluster receive distinct ids.
A caller can use the returned peer id immediately for direct messaging.
Failed launches do not leave an active phantom identity.
Restart and journal reconciliation preserve admitted identities.
Protocol, CLI, and integration tests cover id minting, collision handling, response fields, discovery, and cleanup.
Documentation contains no normal-flow step asking the operator to select an agent id.

Depends on

#1592

## Outcome Make peer identity an output of broker admission rather than a required operator input. For the normal collaboration path, the broker mints a short safe identity such as `<role>-<ab12>`, records it durably, and returns it to the caller. Operators and AOS should not need to invent or coordinate agent ids manually. ## Required behavior * An omitted peer id is the normal launch contract. * The broker generates the id from the admitted role plus the canonical dictatable suffix shape. * Collision handling is bounded and deterministic enough to test. * The accepted id is recorded in the broker journal before launch and remains stable for that peer. * Launch responses expose both cluster id and peer id. * List or roster output exposes active peer ids and roles. * Message, logs, stop, and cleanup address peers by the returned id. * Nested peer launches inherit the cluster and receive their own broker-minted ids. * Any retained explicit-id override is an internal or compatibility surface, not required by the ordinary user flow. ## Acceptance criteria * A peer launches successfully with no agent-id argument. * Two peers of the same role in one cluster receive distinct ids. * A caller can use the returned peer id immediately for direct messaging. * Failed launches do not leave an active phantom identity. * Restart and journal reconciliation preserve admitted identities. * Protocol, CLI, and integration tests cover id minting, collision handling, response fields, discovery, and cleanup. * Documentation contains no normal-flow step asking the operator to select an agent id. ## Depends on * #1592 ## Related * #1626 * coilyco-flight-deck/agentic-os#825 * coilysiren/inbox#309 * coilysiren/inbox#310

coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os

2026-08-02 04:43:27 +00:00

Attach composed agents to repo-free Ward collaboration clusters #851

coilyco-ops referenced this issue

2026-08-02 04:43:42 +00:00

Give each Ward collaboration cluster a harness-scoped stable identity #1592

coilyco-ops added the

priority

autonomy

headless

labels

2026-08-02 04:43:51 +00:00