Summary
Should a managed agent be able to publish its own final ACP reply for a completed turn, as a per-agent opt-in?
Today a managed agent completes a turn and its final assistant text is not published to the channel on its own. We run a 12-agent desk against a self-hosted relay, and the gap means an operator has to go looking for each result rather than seeing it where the conversation is.
We have a working implementation and would rather converge on yours than carry a fork. Happy to close this if the answer is "no" or "not that shape".
What we built
A per-agent opt-in, honouring what desktop/src/features/agents/AGENTS.md already says about this area (no process-global switch, no implicit enabling of existing agents, and the setting participates in the effective spawn config so a running instance is marked for restart):
BUZZ_ACP_AUTO_REPLY=true in an agent's effective environment authorises the harness to publish one final reply per completed single-trigger turn. Any other value leaves it off (fail-closed).set_managed_agent_auto_reply Tauri command, mirroring set_managed_agent_auto_restart.- A
Switch on the agent card in UnifiedAgentsSection, beside RestartDiffBadge.
SpawnConfigSnapshot stores the canonicalised boolean rather than the raw string, so "false" and absent are indistinguishable and toggling off does not raise a phantom "Restart required".
Verified live on a 12-agent desk: records → process env → harness config (auto_reply=true in the startup line) → an attributable reply published under the agent's own pubkey.
Design questions we would rather you answer than guess
- Per-agent, or per-channel? We chose per-agent because that is what rule 12 describes. Per-channel would be a different shape and would change the storage.
- Where should the opt-in live? We put it in the agent's
env_vars, which turned out to be a mistake: AgentInstanceEditDialog owns that map and saves it wholesale, so any unrelated agent edit silently clears the flag. A dedicated record field alongside auto_restart_on_config_change avoids that. If you want this feature at all, we would follow whichever you prefer.
- Is the harness the right layer? We considered doing this as an MCP lifecycle hook per
docs/MCP_DRIVEN_HOOKS.md, but publishing as the agent needs the app's relay identity, which a hook does not have. If there is an intended extension point we missed, we would rather use it.
Offer
If this is wanted, we will open a PR against current main. If not, we will close this and stop carrying it — either answer is more useful to us than the current state.
Summary
Should a managed agent be able to publish its own final ACP reply for a completed turn, as a per-agent opt-in?
Today a managed agent completes a turn and its final assistant text is not published to the channel on its own. We run a 12-agent desk against a self-hosted relay, and the gap means an operator has to go looking for each result rather than seeing it where the conversation is.
We have a working implementation and would rather converge on yours than carry a fork. Happy to close this if the answer is "no" or "not that shape".
What we built
A per-agent opt-in, honouring what
desktop/src/features/agents/AGENTS.mdalready says about this area (no process-global switch, no implicit enabling of existing agents, and the setting participates in the effective spawn config so a running instance is marked for restart):BUZZ_ACP_AUTO_REPLY=truein an agent's effective environment authorises the harness to publish one final reply per completed single-trigger turn. Any other value leaves it off (fail-closed).set_managed_agent_auto_replyTauri command, mirroringset_managed_agent_auto_restart.Switchon the agent card inUnifiedAgentsSection, besideRestartDiffBadge.SpawnConfigSnapshotstores the canonicalised boolean rather than the raw string, so"false"and absent are indistinguishable and toggling off does not raise a phantom "Restart required".Verified live on a 12-agent desk: records → process env → harness config (
auto_reply=truein the startup line) → an attributable reply published under the agent's own pubkey.Design questions we would rather you answer than guess
env_vars, which turned out to be a mistake:AgentInstanceEditDialogowns that map and saves it wholesale, so any unrelated agent edit silently clears the flag. A dedicated record field alongsideauto_restart_on_config_changeavoids that. If you want this feature at all, we would follow whichever you prefer.docs/MCP_DRIVEN_HOOKS.md, but publishing as the agent needs the app's relay identity, which a hook does not have. If there is an intended extension point we missed, we would rather use it.Offer
If this is wanted, we will open a PR against current
main. If not, we will close this and stop carrying it — either answer is more useful to us than the current state.