Should IM channels expose an optional outbox capability?

[jazzenchen]

Question

Should VibeAround provide an outbox capability specifically for IM channels, instead of keeping a generic core-level channel outbox?

Current direction

WorkspaceThread core should route agent replies as workspace/thread-scoped messages to currently attached surfaces. Core should not own a universal queue that persists every ChannelOutput across all surfaces.

Web can stay live-only. IM is different: a disconnected IM adapter, platform retry behavior, and proactive-send permissions vary by channel. If we need durable delivery there, it should probably be an explicit IM/channel capability rather than a global core outbox.

Why this needs design

• Some IM platforms allow proactive bot messages only in specific contexts.
• Some platforms can retry or redeliver through their own APIs, while others cannot.
• A generic core queue may keep messages that a channel can never legally send.
• Dropping every message while an IM process is temporarily offline may also be a bad user experience.
• The routing layer needs a clear boundary: workspace/thread emits replies; channel adapters decide whether and how those replies can be delivered.

Capability shape to evaluate

If we add this, it should be modeled as an optional IM capability, not a core default. Things to define:

• Capability declaration: whether the channel supports queued outbound delivery, proactive send, ack/nack, retry, and expiration.
• Envelope fields: workspace id, thread id, agent id, profile id, channel id, chat id, reply payload, creation time, and idempotency key.
• Eligibility: which reply types can be queued, such as agent text, permission prompts, system errors, or status messages.
• Persistence owner: whether the queue lives in the IM adapter/plugin, in core storage under an IM capability boundary, or somewhere else.
• Retry policy: backoff, max retry duration, TTL, and what happens after permanent failure.
• Replay policy: ordering, dedupe, and whether stale replies should still be sent after the user has switched workspace/thread.
• Observability: how users/debug logs see queued, sent, failed, expired, or dropped messages.

Open questions

• Which current IMs actually support reliable proactive delivery: Feishu, Slack, Discord?
• Should reconnect deliver old replies automatically, or only when the channel confirms the chat target is still valid?
• Should permission prompts ever be queued, or should they expire quickly?
• Is per-channel plugin storage enough, or does core need a narrow storage primitive for IM outbox state?
• How do /switch, /new, and workspace-thread attachment affect stale queued replies?

Non-goals

• Do not reintroduce a generic ChannelOutbox that persists all outputs for every surface.
• Do not make web websocket replay depend on IM delivery durability.
• Do not assume every IM channel can legally send proactive messages.