Writing archive

Product architecture

The Work Product Has to Outlive the Conversation

A chat stream is a useful place to gather intent and a weak unit of work. One protocol consolidation reduced more than fifty event variants to six and made a persistent artifact the handoff between conversation, review, and reuse.

June 20, 20266 min
artifactsstreamingagentsproduct design
A chat stream producing a structured artifact that moves onto a persistent canvas

Protocol growth had hidden product ambiguity

Separate Server-Sent Events and WebSocket paths had accumulated more than fifty event variants. Several described future capabilities with no producing tool and no rendering handler. Others represented the same state under different names. The protocol looked expressive while overstating what the product could reliably do.

The consolidation used a simple audit. For every event or payload type, identify the code that produces it, the code that renders it, and the user decision it enables. Types without all three were removed or folded into an existing contract. A transport event that nobody can emit is a claim the client still has to carry, not a roadmap item.

Six events were enough

The resulting union covered status, token, tool activity, artifact, error, and completion. New artifact capabilities became values inside the artifact contract rather than new transport event types. The transport stayed closed while the artifact registry remained extensible.

A closed event union reduces the multiplication between event types and client surfaces. Each new client handles the same lifecycle, and each new artifact renderer does not require another transport branch. The maintenance benefit comes from separating transport state from work-product variety.

Preview is not authority

An agent may emit an artifact preview during a conversation, but persistence or mutation requires an explicit promotion step. Read-only renderers can be eager. Actions that alter dashboards, files, or workflows wait for a user request or a pre-authorized process.

This two-stage design avoids treating every generated object as committed work. It also creates an audit point: the artifact that was proposed, the actor who promoted it, and the version that became durable can be recorded separately. Chat history cannot do that job once someone deletes the thread.

When a transcript is still enough

A short-lived assistant that answers disposable questions may not need an artifact layer. Persistence becomes worthwhile when an output must be reviewed, compared, edited, scheduled, shared, or consumed by another system: a chart a manager will reopen later, a workflow someone else has to approve, or a file another agent will take as input.

The practical migration path is incremental. Choose one high-value output, define its typed artifact contract, add a renderer, and create one explicit promotion action. The result should be able to survive deletion of the conversation that created it. If it cannot, the product is still a chatbot with extra JSON.