Robs RovoCon Roundup
Things got so exciting for Rovo that it go it’s own convention called RovoCon. This was a series of 1-day events all over the world where local Atlassian Community Chapters hosted Atlassian employees and shared information about Rovo (get a complete list here). Each event gathered 50-100 attendees who participated in hands-on workshops for several hours to learn the basics of Rovo, but also to build out more advanced agents. Attendees got access to an Atlassian instance that included Rovo so they could follow along.
I decided this sounded pretty fun, so I went to some! I started out with the San Francisco RovoCon, then headed up to Vancouver Canada and finished with Austin, Texas. The basic structure of all three was the same (more on that below), but each one offered different perspectives on how folks use Rovo and what we can get out of it.
My big takeaways
I’m still working through everything I learned, but some of the biggest lessons for me are relate to prompting (these events showed me that I ned to learn a LOT MORE about this topic!) but also understanding how Rovo interacts with systems (and people).
Markdown
In San Francisco I picked up the tip of using markdown in the prompt. Markdown is a standardized language that is used to render formatting in wikis and other systems. Typically it’s used to visually format content, however, in Rovo is serves two purposes. First it helps break up your prompt. As you’ll see in my next topic, prompts can get LONG. This means having some way to break them up so you, as a human, can navigate them is critical to maintaining and using them. For instance, having ###Formatting following by rules for formatting is MUCH easier to see that Formatting.
Markdown is also something Rovo can reference - this means you can easily reference different parts of the prompt. For example, you could have one section called ###Formatting, and then further in your prompt refer to the ###Formatting section and Rovo will know what you’re talking about since it understands markdown. This helped me solve one challenge I have which is ensuring Rovo follows instructions (particularly bits about not assuming and/or following specific formatting).
Using markdown helped the next tip come into focus…
Longer prompts
My interactions with Rovo are typically short - a quick search or chat to figure something out. This habit spread into writing agents, resulting in agents with smaller prompts. This unintentionally limited by ability to create effective agents as I was hamstringing its inputs by using short prompts.
Like any system agents are heavily reliant on prompts to provide good outputs. Rovo does have some built-in guardrails (try asking it something like “get me my work” and you’ll see it provide a breakdown with some analysis vs just a list), however, the more precise you can make your prompts, the better the output you’ll get.
This means that prompts, especially for agents, should be longer than we think. In my interview with Aya she shared that instead of just asking for “a blog post about a project”, ask for “a 300 word blog post about the scope of the project”. This is a longer prompt, but provides a lot more accuracy in terms of the outputs since you’re giving Rovo important information.
The agent examples provided by Atlassian are LONG - I’m talking multiple paragraphs in some cases. At first this was a bit intimidating - after all a LOT of thought and energy went into that! Once I dug in though, I realized that each paragraph had a targeted, specific purpose for the agent. While the exact ones used can differ, Atlassian typically includes the following sections in every agent they create:
- What the agent’s purpose is
- Specific outputs it will provide
- Outputs or actions it will NOT provide
- Guidance on assumptions
These bulk out the prompting, but also help ensure that you get what you want. Each one also serves a specific purpose in the agent. Some of them feel like “obvious” things that agent should figure out, however, by explicitly including it you help reduce the chance of the agent going “off track” and giving you a non-optimal response.
My personal goal now is to review agents I’m creating and ensuring it has more specific sections written in markdown. I’m also working on a template to use for all agents (be on the lookout for a followup blog post on what I come up with!).
Scenarios
Scenarios are a relatively new (4ish months old) feature that allows agents to act differently in different situations. This is another feature that at first I struggled with, but the more I hear about it (even the same information from different folks) the more it’s starting to click. Scenarios allow your agent to handle a wider range of tasks, or to behave slightly differently under specific conditions. For example, you may have an agent that specializes in breaking down lira work items. You might, however, want it to handle initiatives differently than epics differently than stories.
Before this feature existed you’d have to build a separate agent for each work type. Instead you can build out a solid “core” agent that handles breaking down tickets (or whatever), then add scenarios to help handle those specific “variations” of your theme. Scenarios can also have specific knowledge and skills - for example, you might have a “triage” agent that has a scenario for specific customer types (executives vs. line employees), which draws on different knowledge to support them.
There is always a “Default” scenario that is what is triggered when the agent is first called (and for some agents this might be all you need!). The default is also what the agent will fall back to if it cannot determine which scenario to use. In the past I’ve only filled out the default since I didn’t understand Scenarios, however, now I’m starting to think through some other options.
An important note is that agents will use their Identity for ALL scenarios - this means that the behavior your setup will always be used. This gives you a great way to control the general direction/behavior of the agent, while using scenarios to tailor how the agent responds in specific cases. This means you’ll likely want to include general guidance for the agent in Behavior (how to respond, assumptions, formatting, etc) while leaving specific tweaks for your scenarios.
Scenarios are also incredibly useful when you combine agents with automations. Adding a scenario called “automation” and settin the “trigger” to the input from the automation allows you to pass text from the automation to the agent (this includes smart values!). This use case is something I’m still thinking through as it allows you to combine the step-by-step mastery of an automation with the synthesis and investigation of the agent. This clearly tells Rovo what to do with the input, and then runs the prompts you’ve setup…. This leads us to
Rovo + Automations
Automations excel in scenarios where steps are repeatable 100% of the time, all the time. Automations cannot, however, analyze or synthesize information. Rovo agents excel in scenarios where some type of analysis or synthesis is needed, but can’t really do repeatable actions. You can, however, combine them!
There is an automation action to call Rovo (it’s even listed RIGHT at the top of the actions list! It’s like they’re suggesting something…) that allows you to use an agent. Basically you’re passing it some information from the automation and getting back a response from the agent. At the time of writing this is limited to text, however, it can be structured (e.g. JSON), so depending on your needs you can move around a lot of info.
For example you might schedule an automation to run right before a sprint. That automation calls an agent that analyzes outstanding work and suggests areas that can be improved, things that might be missing and other relevant topics. It could even pass back some JSO that contains a list of work items that need to be looked at and have the automation perform a branch against that list (a bit more advanced, but a great way to get a lot of things done!).
Or you might have a manually triggered automation that helps route work items, and also calls an agent to triage it. This triage could include an analysis of the ticket, but also a look around to see what incidents or other things might going to suggest further action. This could then be added to a “Triage” field or added as a comment. This results in a work item that is more fleshed out and ready for work once a human agent gets to it.
My challenge with Rovo+Automations is just figuring out what I want to automate. I’m on the lookout for anything the requires both “rote repetition” and “synthesize information”.
RovoCon!
Each RovoCon was structured around bringing attendees up to speed on what Rovo can do. The three I went to all followed a similar pattern, but exactly how they did this differed based on the audience and presenters. I also need to point out that RovoCons were hosted by local Community Champions. These are volunteers that help organize local events and go way out of their way to make things happen (massive shoutout to them!).
The day began with a discussion of what Rovo is (an AI teammate) and some of its use cases. Participants were provided with an Atlassian instance that included Rovo and had a bunch of placeholder data in it. This helped make sure everyone had access and could test things out without breaking anything! This opening also included some of the more basic use cases - things like search, chat and definitions. This helped ensure everyone had a good starting point to build on.
Next up were agents (which dominated the rest of the day). Atlassian had some amazing resources folks could use to follow along (basically confluence pages with text you could copy/paste into the instructions). These covered several different use cases and helped showcase what is possible with solid prompts (something I struggle with!). We tinkered with those for a bit, then broke for lunch.
After lunch we got a choice of more work with agents, or digging into RovoDev…. Because programming scares me I stuck with the agents group, although honestly I spent most of my time chatting with other attendees (be on the lookout for interviews and my thoughts.. some links below as well!).
Each section was guided either by a Community Champion from the local ACE (Atlassian Community Events) chapter, or by an Atlassian who works with Rovo on a regular basis (typically someone in customer support or prompt engineering). I spent a lot of time chatting with this group as they have the most hands-on experience with Rovo across different areas. I’m still going through all my notes and recordings, but be on the lookout for more!
Wrap Up
I really enjoyed RovoCon. It was a great change to get in-person and meet people, but also to share knowledge (and frustrations!) with Rovo. I appreciated how it was spread all over the place and was free to attend… I’d love to see more like this in the future!
The next event I’m planning on going to is Team ’26 - check out the links below for info on that, and to signup for my daily updates from it!
3 comments
Recommended Learning For You
Level up your skills with Atlassian learning
Make AI a part of the team
Avoid common AI pitfalls and follow best practices to make AI work for your team.
Learning Path
Get the most out of Rovo
Learn how to use Rovo, Atlassian's AI-powered product, to find, learn, and act on information faster.
Use Rovo across your organization
As an Atlassian organization admin, learn the capabilities of Rovo and how to enable it across products.