Chat and Messenger

Chat moves one task forward through conversation. Messenger finds work across Rudder that needs a human response. They belong to the same communication system, but they solve different problems. Consider an illustrative launch announcement. An operator can ask an Agent for a draft in Chat, inspect the file, request a shorter opening, and accept the result without creating another record. Messenger becomes useful later when a review request, failed run, or blocker needs that operator’s attention.

​

Choose the task surface

Chat and Issues are parallel work surfaces. Chat is not a waiting room before real work, and a long or important task does not automatically require an Issue. Create or link an Issue only when its coordination structure helps.

​

Keep result and evidence with the work

A Chat can preserve the request, Agent Runs, refinements, and final response. Its files-and-links shelf separates:

• Outputs, which the Agent created and supported with attachment or run evidence
• Sources, which the operator supplied or the eligible project context provided
• References, which were cited or recommended but not produced by the Agent

An ordinary link in a response is a Reference, not automatically an Output. The shelf covers the current conversation only. It does not collect files from other Chats in the same Project. When an Issue owns the work, keep the artifacts and review decision on that Issue. Messenger should link back to the source record instead of becoming a second place to store the decision.

​

Messenger restores human attention

Messenger answers two questions: what needs my attention, and where should I act? Human attention belongs here, but durable state stays on the native object. Messenger is not a backlog, a generic chat app, or the sole record of a review decision.

​

Follow-ups during a reply

If you send another message while the current reply is running, Rudder keeps it in a visible queue rather than starting a second reply in the same Chat. You can edit or delete the queued message. The queued follow-up sends automatically only after the current reply finishes successfully. If you stop the reply or the run fails, the message remains parked for review. This prevents an interrupted run from silently acting on later instructions.