Problem
buzz agents draft-create currently accepts channel, display_name, and
system_prompt. draft-update additionally accepts runtime, provider,
model, and respond_to.
That asymmetry means an agent can propose a configured update from chat, but
cannot propose the same configuration when creating a colleague. The owner has
to reconstruct those choices in the review dialog even though they are ordinary
non-secret fields already understood by the CLI and Desktop.
Proposed boundary
For a first parity pass, make these optional fields use the same names,
validation, and semantics for both create and update:
runtimeprovidermodelrespond_to
Desktop should resolve runtime/provider/model combinations through the runtime
catalog and show the effective values in the normal editable review dialog.
Unknown keys and unavailable combinations should fail validation rather than be
silently dropped.
There are other non-secret candidates that the current UI can represent, but I
would like maintainer direction before expanding the portable contract:
- parallelism;
- instance name pool;
- reasoning effort; and
- selected-people access policy.
Selected-people update support already has active work in #3912, so this issue
should coordinate with that PR rather than duplicate it.
Explicit non-goals
This field-parity change should not carry:
- environment variables, credentials, or secret references;
- executable MCP commands;
- managed-agent key export or secret return;
- automatic approval; or
- standing delegation / an
apply intent.
Those fields change the authority and secret-handling model and need their own
design. The default here remains an editable owner-reviewed draft.
Lifecycle honesty
The CLI's immediate relay response proves publication only; it does not prove
that Desktop retained, presented, dismissed, or applied the draft. I suggest a
separate, owner-signed encrypted lifecycle receipt contract so field parity does
not make delivery claims stronger than the implementation can prove. That can
land independently if it would make this issue too broad.
Acceptance criteria
- Create and update share the maintainer-approved non-secret field set.
- Both the CLI builder and Desktop parser strictly allowlist and validate it.
- The review dialog displays the effective requested configuration and remains
editable before save.
- No request field bypasses explicit owner review.
- No secret-bearing or delegated-apply surface is introduced.
Related work
Problem
buzz agents draft-createcurrently acceptschannel,display_name, andsystem_prompt.draft-updateadditionally acceptsruntime,provider,model, andrespond_to.That asymmetry means an agent can propose a configured update from chat, but
cannot propose the same configuration when creating a colleague. The owner has
to reconstruct those choices in the review dialog even though they are ordinary
non-secret fields already understood by the CLI and Desktop.
Proposed boundary
For a first parity pass, make these optional fields use the same names,
validation, and semantics for both create and update:
runtimeprovidermodelrespond_toDesktop should resolve runtime/provider/model combinations through the runtime
catalog and show the effective values in the normal editable review dialog.
Unknown keys and unavailable combinations should fail validation rather than be
silently dropped.
There are other non-secret candidates that the current UI can represent, but I
would like maintainer direction before expanding the portable contract:
Selected-people update support already has active work in #3912, so this issue
should coordinate with that PR rather than duplicate it.
Explicit non-goals
This field-parity change should not carry:
applyintent.Those fields change the authority and secret-handling model and need their own
design. The default here remains an editable owner-reviewed draft.
Lifecycle honesty
The CLI's immediate relay response proves publication only; it does not prove
that Desktop retained, presented, dismissed, or applied the draft. I suggest a
separate, owner-signed encrypted lifecycle receipt contract so field parity does
not make delivery claims stronger than the implementation can prove. That can
land independently if it would make this issue too broad.
Acceptance criteria
editable before save.
Related work
buzz agents draft-create/draft-update(GUI Advanced parity) #3115 — broader CLI Advanced parity discussion