Agent identity and config need a home: execution pinned to the creating machine, edits routed to it

[akeemjenkins]

The contract users assume (and the product currently breaks):

1. As a user of Buzz, when I create an agent on a machine, that agent's execution environment is ALWAYS and only ever on that machine.
2. As a user of Buzz, when I update any part of an agent's configuration (avatar, system prompt, runtime, etc.) from a machine that is NOT where the agent was created, the config change should be saved to the machine that created the agent.

What happens instead (repro on desktop-v0.5.9, same owner, same community, two machines):

• Machine A creates and hosts "Gary V", pubkey f75feca8…, with a configured runtime (mcp_command, env).
• Machine B opens the edit form for "Gary V" and saves a change. Result: machine B mints a brand-new identity 19452117… with a fresh keypair and none of machine A's configuration, and adds it to the community.
• Side effect: the edit event overwrites machine A's agent avatar with the runtime default icon, while the new clone carries the avatar set on machine B.
• Mobile mention autocomplete now shows two "Gary V" entries with different avatars. Messages route to whichever identity the sender picks, and the clone answers with a bare environment.

Why (from the source): update drafts are keyed by (channel, agent_name) rather than agent pubkey (crates/buzz-cli/src/commands/agents.rs, UpdateAgentDraft), and managed-agent records live per desktop instance. A name lookup on a non-hosting device finds nothing and falls through to create-with-new-keys.

Related open issues this would resolve as a class: #2648 (second install duplicates default agents), #5319 (mention from second device mints a duplicate, post-#4913), #2423 (rename/re-add desyncs identity), #5360 (team creation mints duplicates), #2973 (duplicates cannot be archived), #3840 (mobile autocomplete shows archived identities).

Suggested direction: treat the agent's pubkey as its only identity and record its hosting instance with it. Non-hosting devices publish config-update events addressed to the pubkey (the kind-30177 retained-event sync in managed_agents/reconcile.rs looks like most of the plumbing already); the hosting desktop applies them. Name resolution (mentions, edit forms) must only ever resolve to existing identities, never create. Exactly one harness per identity, on the hosting machine.

Happy to provide configs, timestamps, and transcripts from both machines. We run Buzz agents in production (our marketing agent posts through this setup) and hit every issue above in one afternoon.

[wolfyy970]

I agree with the failure, but I would not make the creating machine permanent authority. The durable object is the agent instance pubkey. Its portable definition can move, while its execution target is an explicit binding. A save from machine B must address the existing pubkey, update the shared definition or instance state, and never mint another identity. B should show “Runs on machine A” and whether the change has reached that running generation.

Secrets, credentials and machine-specific launch config stay on the selected target. Moving the agent is a separate owner action that rebinds the target after readiness checks. #4999 supplies much of the private cross-device transport, but this issue exposes the missing target identity and pubkey-addressed edit contract. #5575 makes duplicate pubkeys visible; it does not make the duplicates acceptable.