Currently, the messaging support, at least with Discord, has some limitations.
For example, asking cptr to create a timer from within Discord creates a timer; however, the response is not sent in Discord after the timer is up.
One way to work around this is to explicitly enable chat alerts in Notifications for "Chat finished" and "Chat failed" alerts.
However, that has several issues:
- It may result in duplicate messages.
- It always comes with explicit "Chat finished" and "Chat failed" tags.
Similar behavior occurs with scheduled jobs/cron: each run creates a new chat, but the resulting response is not returned to the Discord conversation that created the job.
This plays into a separate issue: with the current design, messaging integrations appear to be scoped to the conversation that originated on that platform, rather than being associated with the Computer workspace as a whole.
For example, if Discord is intended to be the primary interface for a given workspace, activity originating from the Computer web UI, timers, or scheduled tasks does not appear to be automatically delivered to the associated Discord conversation. The notify tool can be used as a workaround, but this requires explicitly instructing the agent to invoke it rather than the messaging integration acting as a general output channel for the workspace.
Desired behavior
I think there should be a way to associate a messaging target, such as a Discord conversation, with a Computer workspace and optionally designate it as the workspace's primary messaging interface.
For example:
- Messages sent from Discord should continue to receive normal responses in Discord.
- Timers and scheduled tasks created from Discord should be able to return their resulting response to that same Discord conversation.
- Conversations started from the Computer web UI could optionally be mirrored to the associated Discord conversation.
- Background/scheduled runs should have a way to send their normal assistant response to the associated Discord conversation without requiring to tell the model to explicitly call
notify via a system prompt or similar workaround.
- The existing
notify tool could remain available for messages that are intentionally separate from the normal conversation flow.
In other words, I would like the messaging integration to behave more like a transport/interface for a Computer workspace, rather than only responding to messages that originate from that messaging platform.
I am not sure whether this is intended behavior, a configuration issue, or a missing feature, so clarification on the intended model would also be helpful.
Currently, the messaging support, at least with Discord, has some limitations.
For example, asking cptr to create a timer from within Discord creates a timer; however, the response is not sent in Discord after the timer is up.
One way to work around this is to explicitly enable chat alerts in Notifications for "Chat finished" and "Chat failed" alerts.
However, that has several issues:
Similar behavior occurs with scheduled jobs/cron: each run creates a new chat, but the resulting response is not returned to the Discord conversation that created the job.
This plays into a separate issue: with the current design, messaging integrations appear to be scoped to the conversation that originated on that platform, rather than being associated with the Computer workspace as a whole.
For example, if Discord is intended to be the primary interface for a given workspace, activity originating from the Computer web UI, timers, or scheduled tasks does not appear to be automatically delivered to the associated Discord conversation. The
notifytool can be used as a workaround, but this requires explicitly instructing the agent to invoke it rather than the messaging integration acting as a general output channel for the workspace.Desired behavior
I think there should be a way to associate a messaging target, such as a Discord conversation, with a Computer workspace and optionally designate it as the workspace's primary messaging interface.
For example:
notifyvia a system prompt or similar workaround.notifytool could remain available for messages that are intentionally separate from the normal conversation flow.In other words, I would like the messaging integration to behave more like a transport/interface for a Computer workspace, rather than only responding to messages that originate from that messaging platform.
I am not sure whether this is intended behavior, a configuration issue, or a missing feature, so clarification on the intended model would also be helpful.