RFC: learn from Claude's always-on / shared-artifact / team-channel ideas (secondary source) #373

Source and caveat

Notes from a Chinese-language write-up (shared by the team, Xiaohongshu) summarizing a Latent Space podcast with an Anthropic Claude Code engineer. This is second-hand secondary material; we have not verified the original podcast or any claim. Use it as design inspiration only, not as fact about Anthropic's products. Parent gap tracking: #361.

Ideas worth learning (as described in the write-up)

1. Artifacts as a shared whiteboard, not a preview
   Each Artifact has persistent storage; multiple agents read/write the same state via an MCP-style interface. A stuck task can notify an agent to act. → Maps to Agent inbox ([Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349) and task layer (Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149): a durable shared task board that agents and humans both read/write, with push when something needs handling (Proactive reminders 1/3: event reminders (approval waiting, failed, finished) in app and desktop #353–Proactive reminders 3/3: 24/7 runtime and Slack/email delivery #355).

2. Always-on, not "act when called"
   Brain in the cloud keeps reasoning when the laptop is closed; "hands" run in a cloud env or on the user's machine when needed; UI syncs progress. → Deployment step 1: official image and one isolated instance per person #352 (instance), Proactive reminders 1/3: event reminders (approval waiting, failed, finished) in app and desktop #353–Proactive reminders 3/3: 24/7 runtime and Slack/email delivery #355 (proactive), Mobile: PWA first, then native — approvals and reminders on the phone #362/Mobile entry suite: iOS, HarmonyOS, and Android #363 (phone as client). Three-layer split to adopt as vocabulary: brain / hands / surface.

3. Many roles talk to the same AI in a shared channel
   Team uses a Slack channel per feature; people @ legal etc.; the AI already has the code context so legal asks the AI directly instead of someone relaying. → Team mode: shared room per task with Bots that carry context; Bot Social rooms + task cards (Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149, [Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349); external channel (Proactive reminders 3/3: 24/7 runtime and Slack/email delivery #355).

4. AI as an organizational layer, not only a personal assistant
   Context alignment between roles without humans copy-pasting. → Assigner / owner / executing Bot model in [Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349.

5. Agents may coordinate in unplanned ways
   The write-up mentions (secondhand) agents creating a message board during a security benchmark. → Argue for explicit, auditable coordination surfaces (task board, Timeline, audit [Team] Add a human-readable authorization and task audit trail #57), caps ([Team] Bound agent loops and resource consumption #56), and no hidden side channels between Bots.

Proposed actions for FlyBot (discussion)

• Treat the Agent inbox board as a persistent shared state (versioned, audited), not only a view; allow Bots to read/write via a defined tool contract (cf. Plugin and App connect: catalog, guided auth, and a fast developer scaffold (cf. Grok Bot connectors) #359 plugin contract).
• Define brain / hands / surface in Deployment step 1: official image and one isolated instance per person #352 and [RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198: where reasoning runs, where tools execute (cloud vs user machine), what the UI shows.
• Add "notify the owner / Bot when stuck" as a first-class trigger in Proactive reminders 1/3: event reminders (approval waiting, failed, finished) in app and desktop #353.
• Per-task shared room with context (Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149) so humans can @ a Bot instead of relaying messages.
• Safety rule: coordination between Bots must go through logged surfaces; unexpected channels are bugs to detect (Timeline + audit).

Open questions

1. Do we want a generic "Artifact" concept (durable doc/state per task) or keep task cards only?
2. Which "hands" run where by default: cloud instance vs user's machine?
3. How do we detect and alert on unplanned Bot-to-Bot coordination ([Team] Add a human-readable authorization and task audit trail #57 / Timeline)?
4. Which of these belongs in Phase 1 vs later on the daily-tag train (Release cadence: at least one tag per day, small and stable #351)?

Process

RFC only; implementation via OpenCode + Codex review.