Agents tab is not community-scoped: card, profile name and public key belong to three different entities — and per-agent settings land on the wrong instance

[eireal]

Environment: Buzz Desktop on macOS (a Windows machine is paired under the same owner identity). Two self-hosted communities: leevia.communities.buzz.xyz and knowhow.communities.buzz.xyz. Builtin agents Fizz / Honey / Bumble, custom agents Nemo and Oracle.

Relay-side state is correct throughout (buzz channels members and buzz users presence agree with expectations). Everything below is local to the desktop client.

Identity model observed

On this Mac each builtin agent has one identity per community, created at different times:

Persona	Mac · leevia	Mac · knowhow
Fizz	bf667ab3… (created 2026-07-30T22:23Z)	9dd15fbb… (created 2026-08-03T20:42Z)
Honey	612eeaae…	56769d9e…
Bumble	f74495db…	0bb9f108…

Custom agents (Nemo, Oracle) instead reuse one key across both communities.

1. The Agents tab renders the same list in every community

Screenshots taken minutes apart, switching only the active community: the agent cards are identical (Fizz PC, Honey PC, Bumble PC). Only the channel list in the sidebar changes. There is no visual cue anywhere that these cards belong to a specific community.

2. Card name, profile name and public key are three different entities

Opening the card labelled Fizz PC:

• profile heading shows Fizz Mac
• Public key shows 9dd15fbb…9dd8 — the knowhow instance
• and it shows the same 9dd15fbb…9dd8 while the active community is leevia, where this persona's instance is bf667ab3… and its buzz-acp process is running.

Same defect on a custom agent: the card labelled Wally PC opens a profile titled Nemo Mac with key 758f820f…44b0. (Wally is an agent created on the Windows machine; Nemo Mac is a different agent that only exists on the Mac. The two got merged into one persona record — see #3204 for the sync side of this.)

The PC suffix comes from the local store: persona records (no pubkey) are named Fizz PC / Honey PC / Bumble PC / Wally PC, while instance records are named Fizz Mac / Honey Mac / Bumble Mac / Nemo Mac. The card renders the persona name, the profile renders the instance name.

3. Instances (2) is the only place both identities appear — and it does not distinguish them

The profile has an Instances 2 row whose two entries are labelled identically and differ only by Current / Stopped. No community, no machine, no key fragment. This is the only control from which the owner can act on a specific instance, and it gives him nothing to choose by.

4. Consequence, reproduced today: a per-agent setting landed on the wrong instance

The owner set "start on app launch" for the three agents he actually works with (the leevia ones). Reading managed-agents.json right after:

Fizz  · knowhow  9dd15fbb   start_on_app_launch=True    updated 2026-08-07T00:49:15Z
Honey · knowhow  56769d9e   start_on_app_launch=True    updated 2026-08-07T00:49:10Z
Bumble· knowhow  0bb9f108   start_on_app_launch=True    updated 2026-08-07T00:49:02Z
Fizz  · leevia   bf667ab3   start_on_app_launch=False   (untouched)
Honey · leevia   612eeaae   start_on_app_launch=False   (untouched)
Bumble· leevia   f74495db   start_on_app_launch=False   (untouched)

The flag was written to the three knowhow instances. The owner had no way to notice: the UI showed him the cards he expected.

Net effect if unnoticed: on the next app launch the client starts the three agents that are not members of any working channel, and leaves the three that are — which is exactly the incident that started this: on 2026-08-06 two agents silently failed to come back and no surface reported it.

What we need

1. Scope the Agents tab to the active community (or label each card with its community/machine). Requested previously on 2026-08-03; this issue is the visual evidence.
2. Make the profile show the instance of the active context — heading, public key and settings must refer to the same entity.
3. Label instances in the Instances list with community and machine, not just Current / Stopped.
4. Apply per-agent settings to the instance the user is looking at, and show which one was written.
5. Product-level: let an agent be bound to a machine + community so the client does not create or display cross-community instances. Desired setup here: knowhow agents live on the Windows machine, leevia agents on the Mac.

5. The Auto-start toggle lives at profile level and is bound to the wrong key

The agent's overflow menu offers: Auto-start (toggle), Duplicate, Export, Archive agent, Delete agent. There is no per-instance control in that menu, and the profile it belongs to is the one showing 9dd15fbb…9dd8 — the knowhow instance. That is why the flag in section 4 landed where it did: the toggle applies to whichever instance the profile decided to show, which is not the one bound to the active community.

The Instances (2) list shows both entries labelled identically (Fizz Mac), tagged Current and Running in one screenshot and Current and Stopped in another taken minutes earlier — with both buzz-acp processes alive in ps the whole time. Neither tag identifies the community or the machine.

Also worth noting for a user with two machines: the only destructive-sounding options offered are Archive agent and Delete agent, both worded at agent level while the entity actually being displayed is an instance. It is not discoverable whether archiving would remove one identity or both.

Evidence

Four screenshots of the Agents tab (same session, switching only the active community) will be attached to this issue by the reporter. All identity/state claims above were cross-checked against the local store ~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json, the runtime receipts in agents/agent-pids/, live ps output, and the relay itself via buzz channels members / buzz users presence.

Related: #3204 (mention picker built from the local agent registry instead of channel members) — same underlying assumption that the local agent list is the source of truth for a community-scoped view.

[eireal]

Follow-up from the reporter's side — we found the mechanism and a workaround, and it sharpens the report.

The Instances row is a selector, not a status list

Clicking the › chevron on the non-current instance makes that instance Current, and the whole profile above re-renders for it. The previously current one flips to Running. So:

Selected row	Public key	Channels	Memories	Avatar
row 1 → Current	9dd15fbb…9dd8 (knowhow)	(none)	1	initials FM
row 2 → Current	bf667ab3…d4f9 (leevia)	7	2	the agent's picture

That explains section 4 of the issue: the Auto-start toggle in the overflow menu writes to whichever instance is currently selected, and the app had preselected the knowhow one — the instance with zero channels — while the user was working in the community where the other instance is a member of seven.

Workaround for anyone hitting this

Before touching any per-agent setting, open the Instances list and click through until the profile shows the instance you actually mean, then apply the setting. Verify in ~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json that start_on_app_launch moved on the intended pubkey — the UI gives no confirmation of which record it wrote.

Which makes two concrete asks sharper

• The row labels Current / Running / Stopped describe selection and process state in the same column, and neither of them names the community or machine. In two screenshots taken minutes apart the same pair read Current/Stopped and then Current/Running, with both buzz-acp processes alive in ps throughout.
• The two signals that did let the owner tell them apart — the channel count and the presence of an avatar — are incidental. An instance with 0 channels in the community you are looking at should not be the one the profile preselects.

[eireal]

One more detail, and it makes ask #4 sharper: the instance selection does not persist.

After selecting the correct instance and applying the setting, reopening the agent card resets Current back to the same instance as before — the one with zero channels in the active community. There is no stored preference for it anywhere in ~/Library/Application Support/xyz.block.buzz.app/ (checked agents/managed-agents.json, agents/global-agent-config.json, agents/teams.json, .window-state.json); it appears to be view state recomputed on each open.

Practical consequence: the workaround from the previous comment is not a one-time fix. The trap re-arms every time the panel is opened. Any user with two instances per agent has to remember, on every single settings change, to click through the Instances list first and confirm the public key in the header — with no confirmation from the UI that the write landed on the instance they meant.

For what it's worth, the settings themselves are stored per instance and stay put once written. Verified in managed-agents.json after the fix: start_on_app_launch=true on the three instances that are channel members, false on the three that are not. So the data model is per-instance and correct — it is only the selection and the presentation that are not.

[eireal]

Useful narrowing from the reporter, with a screenshot: the instance mix-up is specific to the builtin agents. Custom agents do not have it — and the reason is that they use a different identity model, already implemented in the same app.

	Identity model	Instances row	Wrong-instance writes
Builtin (Fizz / Honey / Bumble)	one keypair per machine × community	2 entries, labelled identically	yes
Custom (Nemo, Wally, Oracle)	one keypair per machine, shared across communities	absent — there is only one	no

Screenshot: the card labelled Wally PC opens a profile titled Nemo Mac, key 758f820f…44b0, Channels 4, and no Instances row at all. Nothing to preselect, so nothing to get wrong. The persona/instance name crossing still affects custom agents (that is #3204's neighbourhood, and it is why the card says Wally PC), but every setting the user changes lands on the only identity that exists.

That suggests the cheapest fix for the ask in section 5 is not a new feature: give builtin agents the same one-key-per-machine model the custom agents already use. With a single identity per machine, an agent is simply a member of whatever channels it was added to, in whichever community — which is what already happens today for Nemo Mac (member of channels in leevia, one key, no ambiguity) and what the owner expected all along.

If per-community keys for builtins are deliberate, then the Instances list needs to name the community and the profile needs to preselect the instance that belongs to the active one — but the simpler path is available and already shipping in the same product.

[eireal]

The same defect shows up outside the Agents tab, and this one bit the owner a third time tonight — this time in the channel member list.

Context: three builtin instances were retired (removed from every channel, auto-start off). The owner then re-added "the Mac agents" to two channels from the member picker. What actually got added were the three retired identities. Verified against the relay immediately after:

leevia #general / #welcome-everyone members
  df13988e  Lucho            owner
  9dd15fbb  "Fizz Mac"       bot   <- retired instance
  56769d9e  "Honey Mac"      bot   <- retired instance
  0bb9f108  "Bumble Mac"     bot   <- retired instance
  758f820f  "Nemo Mac"       bot

The three working instances (bf667ab3, 612eeaae, f74495db) publish the same display names — Fizz Mac, Honey Mac, Bumble Mac. So the picker offers six entries with three distinct labels and no way to tell them apart.

Two details from the owner's screenshot of the member dialog worth noting:

1. One member renders as a raw pubkey (0bb9f108…5b49) instead of a name, while the other two in the same list render as Fizz Mac / Honey Mac. Inconsistent resolution within a single dialog.
2. The only usable visual difference is the avatar: the retired instances fall back to grey initials (FM, BM, HM) while the working ones show their picture. That is incidental, not a designed affordance — and it is currently the owner's most reliable way to tell two identities apart anywhere in the product.

So the ask in section 1 is broader than the Agents tab: anywhere the product lists agents — member pickers, member dialogs, mention autocomplete — identity has to be distinguishable. Right now the only thing distinguishing two live identities of the same persona is whether the avatar happened to load.

[eireal]

Two more findings from the same session, and the second one is the worst of the set: channel removals do not stick.

1. Enabling Auto-start for an instance also launches that identity against the other community's relay

Timestamps from agents/agent-pids/ on the Mac, matched against the start_on_app_launch writes in managed-agents.json:

bf667ab3  auto-start written 01:04:24Z   ->  process started on knowhow relay at 01:04:24Z
f74495db  auto-start written 01:04:58Z   ->  process started on knowhow relay at 01:14:47Z
612eeaae  auto-start written 01:04:50Z   ->  process started on knowhow relay at 01:14:49Z

These three are the leevia instances. They are now connected to the knowhow relay while being members of no knowhow channel. A per-agent toggle in one community starts processes in the other.

2. Removing an agent from a channel does not persist across a community switch

The owner removed the three retired instances from a knowhow channel, switched the active community to leevia, switched back to knowhow — and all three were members again. Verified against the relay each time:

01:26Z  Welcome: 5 members (owner + 3 correct agents + 1)   <- after owner removed them
01:47Z  Welcome: 8 members (the 3 removed ones are back)
01:52Z  owner removes them again, switches community, returns
01:53Z  Welcome: 8 members again

Their start_on_app_launch is false throughout (verified in managed-agents.json at each step), so this is not the auto-start flag. Something in the app re-asserts channel membership from local state when it starts or reconciles an instance — the exact trigger is not something I can prove from outside, but the effect is reproducible: the user cannot remove an agent from a channel and have it stay removed.

That makes the naming/selection issues above worse than cosmetic. A user who realises the wrong identity is in a channel has no working remedy short of archiving or deleting the agent — and the overflow menu offers only Archive agent / Delete agent, both worded at agent level while the entity displayed is an instance, with no indication of whether they affect one identity or both.