Artifacts as shared objects: canvas CAS, anchored comments, generic AG-UI cards, and a projection agents can read

**TL;DR** — four asks, smallest first: a compare-and-swap on `canvas set`; comments that anchor *inside* an artifact; a generic agent-renderable card kind (AG-UI) generalising `send-diff`; and a machine-readable projection so agents can read artifacts, not just post them.

We're a 4-person team running Buzz as our development control plane, not just chat. Agents hold their own keypairs and are channel members; a gate router we wrote posts approvals into `#general` and reads decisions back. Specs, design review and merge approvals go through it daily. These four came out of building that.

---

## 1. `canvas set` needs a base revision

Kind 40100 is described as long-form collaborative editing and the README lists canvases under "works today", but `canvas set` takes only `--channel` and `--content`. No compare-and-swap, so two writers a minute apart silently destroy each other's work.

Our workaround is a single designated writer that posts the revision it's about to replace into the channel first, so a clobbered version is recoverable from chat history. That's a manual undo log implemented in a chat channel.

**`buzz mem patch` already solves this in the same CLI** — it *"refuses to apply if the slug has changed since `--base-hash` was captured."* Extending that to `canvas set --base-revision `, rejected with the current revision on mismatch, turns silent data loss into a retryable error. **We'd write this one if the approach sounds right.**

## 2. Comments that anchor inside an artifact

Threads (NIP-10) and forum comments (45001/45003) put a conversation *next to* an artifact. There's no way to say "this paragraph", "this element", "this moment in the run".

That distinction is the whole game, because feedback attached to a *location* is actionable — including by an agent, which can resolve an anchor to the thing it must change. Attached to the artifact as a whole, it degrades into prose a human has to re-read and re-attach by hand.

We felt it hardest reviewing UI. With no anchor, we ended up numbering elements on a screenshot and asking reviewers to type `pricing 12 — this button should say Start free`. It works, and nobody would choose it. We were making people speak a machine's addressing scheme because the artifact had no addresses of its own.

**Ask:** a comment kind carrying an anchor — range, selector, timestamp, element id — interpreted by whatever renders that artifact type. The relay needn't understand the anchor, only carry it.

## 3. Generic agent-renderable cards (AG-UI)

`messages send-diff` is a purpose-built card: it takes `--repo`, `--commit`, `--lang`, `--pr`, `--source-branch` and renders a diff viewer. It's good, and it's *one* artifact type with a hardcoded renderer.

Everything we produce wants the same treatment — an acceptance rubric with checkable rows, a test report, a plan, a screenshot set, a run timeline. Today each one is either markdown that renders flat or an attachment nobody can interact with. The alternative to a bespoke card per type is a **generic one**.

[AG-UI](https://github.com/ag-ui-protocol/ag-ui) (MIT, ~15k stars) is the emerging standard for exactly this: ~16 event types over SSE by which an agent emits UI and receives interaction back, with SDKs across TS/Python/Kotlin/Go. A Buzz card kind carrying an AG-UI payload would let an agent publish an interactive artifact that every member sees and can act on, without Buzz needing a renderer per artifact type.

This also generalises #2: an AG-UI component has addressable parts, so anchoring a comment to one is a property of the card rather than a special case per type.

## 4. Artifacts agents can read

Agents are first-class for *messages* today, not for *artifacts*. An agent can post an image; it can't meaningfully read one back, nor a canvas revision, nor a comment anchored to a region. So every artifact gets built twice — once for people, once for the agent — and the two drift.

One identity with two projections (rendered for humans, structured for agents) means a comment a person anchors visually resolves to something an agent can act on with no translation layer between.

For contrast: GitHub Next's [Ace](https://githubnext.com/talks/one-developer-two-dozen-agents-zero-alignment/) offers "live preview viewable by the entire team" — human-only. A preview agents can read too is a strictly better primitive, and Buzz's identity model is already the right foundation for it.

---

## Why we think Buzz is well placed for this

Ace exists because agent reasoning stays *"hidden in one developer's local terminal"*. In Buzz it was never there — the agent is a channel member with its own keypair and its work is in the room by default. GitHub is building cloud microVMs to reach where your identity model already is.

Two of Ace's pillars are arguably shipped here already: **multiplayer agent prompting** (`buzz-acp --multiple-event-handling steer` weaves mid-turn mentions into an in-progress task, by default) and **shared decision context** (a signed channel history). Ace is a research prototype whose authors note *"most benefits are theoretical rather than empirically demonstrated"*; ours runs in production.

What's missing is the shared *workspace* half — artifacts as objects the whole team, and the agents, can inspect and act on at once.

## Smaller note: WF-08

Already in ARCHITECTURE.md, so just a vote for priority. Because runs hitting an approval gate are marked failed rather than suspended, we couldn't use Buzz workflows for the thing they look purpose-built for, and run a separate DAG engine with Buzz as the gate surface instead. Gates are exactly the early checkpoint Ace argues teams lack.

---

Following CONTRIBUTING and asking before building. Happy to take any of these — #1 looks self-contained.

And genuinely: thank you for making agents real members rather than bot tokens. It's the part that's hard to retrofit, and you got it right first.

Read CONTRIBUTING.md and ARCHITECTURE.md first, then inspect the existing `buzz mem patch`, `canvas set`, and `messages send-diff` entry points. The issue contains four separate proposals, so confirm the intended scope and acceptance criteria with maintainers before implementing; done is not defined for the broader artifact and projection work.

Written by the indexing model from the issue text.