Publish reviewed Berd agent updates to an existing Buzz identity

[joeyblack4]

Problem

I use Berd as the place where an agent definition is created and improved, and Buzz as the place where that agent works with a durable identity and work history.

Berd can export/share an agent and Buzz can import it, but importing an improved copy creates a new Buzz identity. That fragments the agent's activity and makes an improved agent look like a replacement teammate instead of a new version of the same teammate.

Confirmed as a current product gap with Berd 0.6.2 on macOS 26.3. This is a feature request, not a bug report.

What I do today

1. Create or improve the reusable agent definition in Berd.
2. Review the changes before deployment.
3. Manually apply the approved definition changes to the existing Buzz agent using Buzz's owner-reviewed edit-in-place flow.
4. Sync or update skills separately.
5. Confirm the Buzz public key/identity is unchanged before the agent resumes work.
6. Record which Berd definition/version was applied.

I reserve import for creating a genuinely new Buzz agent. This preserves continuity, but the process is manual and drift-prone.

Desired workflow

After the initial agent is created or imported, Berd should support publishing a reviewed update to an existing Buzz identity:

1. Link a Berd agent definition to a specific existing Buzz agent by stable identity/public key, never by display name.
2. Show an exact proposed diff before publishing, including instructions, model/runtime defaults, and declared skill requirements.
3. Require explicit owner review and approval in Buzz.
4. Update the existing Buzz agent in place while preserving its public key, work/activity history, memory, channel membership, and local bindings.
5. Keep credentials, tool connections, grants, and local overrides out of the portable definition unless the owner explicitly changes them.
6. Record the Berd source version or digest and a Buzz deployment receipt so an operator can see what is running.
7. Make drift or conflicts visible; do not silently merge edits made independently in both products.

Why this belongs in Berd

Berd is where the reusable definition is authored and reviewed. It is the natural place to choose a definition version and initiate a publication. Buzz should remain the authority for the running agent's identity, local state, permissions, and final approval.

Non-goals

• Transferring or exporting private keys, credentials, or secrets.
• Silent automatic synchronization.
• Automatically granting tools, connections, or permissions.
• Replacing import-as-new-agent when the operator intentionally wants a clone or new identity.
• Generic bidirectional filesystem synchronization.

Alternatives considered

• Re-import the improved agent: creates a fresh Buzz identity and fragments history.
• Edit only in Buzz: preserves identity but loses Berd as the reviewed source of the reusable definition.
• Build a custom synchronization script: possible, but it would make identity binding and approvals opaque. I am not proposing custom development; I will use the manual edit-in-place workflow for now.

Related Buzz work

This is the Berd side of block/buzz#4301, especially its remaining definition-version, binding, selection, rollout, and audit contract.