UX/infra ideas from Block's `buzz`: reaction-as-approval, visible agent presence + unified activity feed, first-class external-agent participation

## Context

We studied [Block's `buzz`](https://github.com/block/buzz) — a self-hostable "hive-mind" workspace where humans and AI agents share the same rooms as first-class members, built on a signed Nostr event log. Its philosophy (agents-as-network-peers, decentralized, cryptographic identity, code-collaboration-first) is deliberately different from MJ's (agents-as-typed-metadata, centralized, strongly-typed, business-user-first) — but a few of its **UX and platform patterns are directly portable** and line up with work already in flight, notably the Conversations Phase 1 umbrella (#2953) and the Agent Trust spec (#3044).

This issue captures the **top three borrowings** for discussion/prioritization. It is a proposal for consideration, not a committed plan.

> Note: our read of `buzz` is from its README/landing docs, so treat its feature *maturity* as self-reported (several items — approval gates, push, git hosting — are marked "in development" there). The value here is the interaction patterns, not a claim that we're behind.

---

## 1. Reaction-as-approval 🥇 (smallest, highest ROI)

**What buzz does:** an emoji reaction (e.g. 👍) *is* the approval signal that unblocks a workflow step. Governance becomes a one-tap, chat-native gesture instead of a modal.

**Where MJ is today:** HITL is the heavier `MJ: AI Agent Requests` pause/resume flow; Plan Mode already rides on it. `beforeToolInvoked` is a cancel-enforced seam but ships no default consent UX.

**Proposal:** let a reaction on an agent's "Plan" or "confirm this action" message resolve the pending `MJ: AI Agent Requests` record (approve / reject → re-plan). Keep our substrate; borrow only the interaction.

**Why now:** this is the direct antidote to the consent-fatigue risk called out in the Agent Trust spec (#3044) — "confirm what you can't undo" only works if confirming is nearly free. Natural fit alongside the consequence taxonomy in that spec.

**Rough surface:** `@memberjunction/ng-conversations` message-reaction UX → resolve `MJ: AI Agent Requests` → existing resume path. No new substrate.

---

## 2. Visible agent presence + unified per-workspace activity feed

**What buzz does:** agents appear in the member roster with presence state, and everything (messages, agent runs, approvals, changes) flows into one searchable stream — the "hive mind" feel.

**Where MJ is today:** agents act silently behind `contextUser` (no visible identity/presence). We *do* already persist rich audit — `MJ: AI Agent Runs` / `AI Agent Run Steps` / `AI Prompt Runs` + Record Changes — but it's scattered across tables/surfaces, not one timeline. We also already have `agentCharacterConfig` voice-states (idle/listening/thinking/speaking) to reuse.

**Proposal (two parts):**
- **Presence:** show agents as first-class members in the conversation/Project roster with a live state chip (reuse the character voice-states); attribute agent messages/steps to that identity.
- **Activity feed:** a single "what happened here" timeline per Project/Conversation that merges messages + agent steps + record changes + routine fires — surfacing data we already store.

**Why now:** directly reinforces the #2953 Projects direction ("what *agents* remember here", agent-plural memory) and makes Projects-as-workspace feel like a shared room. **Presentation only — we are NOT adopting buzz's cryptographic per-agent identity.**

---

## 3. First-class external-agent participation surface (the strategic infra bet)

**What buzz does:** ships CLI tooling built *for agents* — `buzz-cli` (JSON in/out for tool calls) and `buzz-acp` (a harness for external agents: Goose, Codex, Claude Code) — so any external coding agent can act as a workspace member.

**Where MJ is today:** the primitives exist (MJCLI, `A2AServer`, `MCPServer`/`MCPClient`, `ai-agent-client`) but aren't framed as "the sanctioned way an external agent participates in a conversation."

**Proposal:** define a clean, documented **external-agent participation contract** — a JSON/ACP surface over our existing A2A + MCP investments — that lets an external agent (e.g. Claude Code) join an MJ Conversation as a participant, post messages, invoke Actions/skills (permission-gated as its bound user), and stream results.

**Why it matters:** highest strategic leverage of the three; turns any ACP/coding agent into an MJ teammate and extends the A2A/MCP work we've already funded. Larger scope — likely its own design spec.

---

## Sequencing (suggested)

1. **Reaction-as-approval** — small, ship-alongside #3044.
2. **Presence + activity feed** — medium, rides #2953 Projects.
3. **External-agent participation** — larger, own design spec.

## Ask of @MattC-BC

Tagging you to review — this overlaps work you've been considering. Feedback wanted on: which of the three to sequence first, whether reaction-as-approval should fold directly into the #3044 Agent Trust spec vs. stand alone, and scope/appetite for the external-agent participation surface.

### Explicitly out of scope
Nostr/decentralization, cryptographic per-agent identity, and git-as-events code collaboration — these are `buzz`'s core bets but run counter to MJ's centralized, typed-metadata model. Noting them here only to bound the discussion.

Related: #2953 (Conversations Phase 1), #3044 (Agent Trust, By Default), #3043 (Business-user usability).