Agent conversations: build the sender's side from delivered messages so both threads always match

[brsbl]

Summary

PR #4772 shows agent-to-agent conversations on both threads. The receiving thread renders each delivered message as "Message from " with its answer as "Reply to ". The sending thread renders "Message to " / "Reply from ", but it builds those chips by parsing bb thread tell commands in its own timeline. Any message delivered with that thread as sender that its agent did not send with a bb thread tell shell command appears on the receiver's side only, so the two timelines can disagree.

Proposal: build the sender's view from the receiver's records (every delivered message whose senderThreadId is this thread) instead of from command text. The two sides then match by construction.

Versions and environment

• bb from source at 64469e0942 (PR Tell agents to answer other agents with bb thread tell #4772 head), base main at 4ee89642c8.
• macOS (Darwin 25.5), Node 22.23.1, pnpm dev branch web app.
• Provider: Claude Code, claude-haiku-4-5-20251001.

Steps to reproduce

With PR #4772 checked out and pnpm dev running, in a shell with the dev CLI (pnpm bb:dev):

1. Create two threads, A ("Release manager") and B ("Calendar worker"), in the same project.
2. Send B a message attributed to A without A's agent running a command:

   BB_THREAD_ID=<A> pnpm -s bb:dev thread tell <B> "Is the cache TTL the cause? One short sentence."

3. Wait for B to answer, then open both threads in the app.

Also reproduces when A's agent sends with a form the parser doesn't recognize. Examples: an unusual shell wrapper, --message-file pointing at a file (the chip renders without text), or any SDK/API send that sets senderThreadId.

Expected vs actual

• Expected: B shows "Message from A" + "Reply to A", and A shows the matching "Message to B" + "Reply from B".
• Actual: B shows "Message from A" + "Reply to A". A shows nothing for that exchange. During QA for Tell agents to answer other agents with bb thread tell #4772, B showed 5 messages from A while A's timeline showed 1, the only one its agent had sent itself.

When A's agent does send with bb thread tell, both sides match. Verified with four agent-driven rounds: 4 sent, 4 received.

Evidence

• Sender-side chips come from parsing command text:
  • agent-thread-tell-command.ts
  • AgentSentMessageRow.tsx
  • The reply is then matched heuristically by text and time in agent-sent-message-reply.ts.
• The authoritative sender is already stored on the receiver's records:
  • the turn-request event payload's senderThreadId (stored-thread-event.ts);
  • queued_thread_messages.sender_thread_id while queued (schema.ts).
• There is no query or route that lists messages by sender thread.

Proposed approach

1. Server: add a read route, with SDK and CLI parity per AGENTS.md, that returns messages delivered with senderThreadId = <thread>. Each entry carries the recipient thread, message text, request status, delivered-at time, the recipient turn id, and that turn's final assistant text once the turn settles. This likely needs an indexed sender column, or a small table written at send time, rather than JSON scans over thread_events.
2. App: render the sender's "Message to" / "Reply from" chips from that route, placed in the sender's timeline by delivery time. Drop the command parsing and the text/time reply heuristic. The receiver side stays as in Tell agents to answer other agents with bb thread tell #4772.
3. Decide: whether bb thread tell command rows stay visible in the sender's work summary once the chips no longer depend on them.

What I ruled out

• Not a duplicate of Plugin-originated thread messages are indistinguishable from user input (initiator=user, senderThreadId=null) #3621, which is about plugin-originated messages lacking a sender, not about the sender's own view.
• Not fixable in the client alone. The sender's timeline has no record of a send that did not happen through its own shell, and scanning every other thread's timeline client-side doesn't scale.

Suggested priority and effort

Medium priority, medium effort. Agent-driven sends, the common case, already match after #4772. The mismatch hits manual or SDK sends and unusual command forms, and nothing is lost: the receiver still has the full record.

Related: #4772
BB-Thread-ID: thr_4u5mgu9qe7

AGENT GENERATED

[bb-slop-cop]

🚨 SLOP COP 🚨 · new-issue-autopilot

• Applied Type: Feature, Priority: Medium, Effort: High; preserved existing labels threads, ui.
• Trusted main at 4ee89642c8dd59f180508b35fa0242405b2bdc40 does not contain the two-sided conversation implementation; PR Tell agents to answer other agents with bb thread tell #4772 remains open. This requests additional delivery-backed outbound history for that pending feature, rather than a verified regression on main.
• Medium priority reflects limited impact without message loss. High effort reflects persistent sender lookup plus server, SDK/CLI, and timeline integration.
• No reproduction report or fix PR: the final Type is Feature, so this rule skips those steps.

[brsbl]

Closing: this proposal targeted a prototype that was discarded. #4772 now has agents message each other with an explicit bb_thread_message tool, and the sending thread renders that tool call as "Message to ", so there is no command parsing or reply matching to replace.

AGENT GENERATED