I’m building a Rovo agent to help triage support requests that are posted in a Slack channel.
The agent reviews the request, gathers the necessary details, and creates a Jira ticket as part of the triage process. Once the Jira ticket has been created, I would like the Rovo agent to stop participating in that Slack thread.
The challenge is that my team often continues discussing the issue in the same thread after the ticket is opened to provide additional context or troubleshooting details. However, the Rovo agent continues responding to every new message in the thread.
Is there a way to configure the agent so that it stops responding after the triage workflow is complete, or otherwise ignores follow-up messages once a Jira ticket has been created?
in the Rovo Slack integration each thread should have an option to "Remove From Thread" which will stop Rovo's continuous thread responses for that conversation
If you want to turn off continuous threads completely so it just provides 1 reply there is an option for that if you enter /rovo manage you can turn Continuous threads off
Hello @Andrew Grube ,
@Christopher Yen has given you the two controls that exist, so let me add the part underneath them, because it decides which design you should pick: there is no conditional stop. The behaviour you are seeing is the continuous replies setting in /rovo manage doing exactly what the doc says it does: once an agent is triggered in a thread, it answers every subsequent message in that thread, and triggers and keywords no longer apply inside it (https://support.atlassian.com/rovo/docs/using-the-atlassian-rovo-slack-app/). It is per channel and binary. Nothing in the product says "reply until a ticket exists, then go quiet," and no agent instruction can switch the setting off from inside a conversation.
So the question becomes which of three designs fits your triage flow:
1. Continuous replies off, explicit triggers on. Turn continuous replies off for the intake channel and keep the agent on a keyword, emoji or mention trigger. The agent triages when someone invokes it, creates the ticket, and then the thread is human-only until someone triggers it again. This is the closest thing to what you asked for, and the cost is that follow-up questions to the agent need an explicit trigger instead of just typing. For most intake channels that cost is small.
2. Continuous replies on, agent instructed to go minimal after creation. If you want the conversational back-and-forth before the ticket exists, keep continuous on and write the agent's instructions so that, once it has created the ticket, it responds only with the ticket key and a one-line "further updates on the ticket" and nothing else. Be honest with yourself about this one: it does not stop the agent, it makes the noise short. People will still see a bot reply on every message.
3. Split the conversation. Let the agent own the triage thread, and move the human conversation to the ticket, which Jira Cloud for Slack will sync back as comments and notifications. The thread in Slack ends when the ticket is created; the thread on the ticket continues. This is the cleanest shape if the humans replying are the ones who will work the ticket anyway.
Christopher's Remove From Thread stays useful as the per-thread escape hatch in any of the three, and it is the only way to stop an already-running continuous thread without changing the channel setting.
If it helps, I would file the "stop after action X" behaviour as a suggestion, since the intake-then-hand-off pattern is common and the current controls are all-or-nothing; post the link here and I will vote for it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.