Build Rovo Agents: Q&A and Instruction-Writing Tips from the Rovo Studio Class

[#1]

Thank you to everyone who joined the Public class, "Build Custom AI Agents and Automations in Rovo Studio," on 18 June. There were some excellent questions during the class. This page collects them along with answers and a practical guide to writing useful agent instructions.

How to write useful agent instructions

One of the most common questions when building an agent is "Where do I start with the instructions?" Here are three quick tips, followed by a reusable template.

Three quick tips

• Ask Rovo for a starting point. Sometimes simply asking Rovo for an initial set of instructions based on your agent description gives you a great first draft to refine.

• Use meta-prompting. Asking an AI to help you write the prompt (prompting about prompting) works remarkably well for shaping clear instructions.

• Ask an existing agent what it does. If you want a usage summary or to understand how an agent is set up, just ask the agent to describe what it does.

A reusable template for writing instructions

Here's a worked example of a different agent — an "Onboarding Buddy" that helps new starters find their feet — built using a simple six-part template. (We use a different example in the live class, so think of this as an extra one to learn from.) You can reuse this template for almost any agent.

Section	What to include	Example (Onboarding Buddy)
1. Name & Role	What the agent is called and the job it does in one line. Provide the name of the agent along with a concise description of the specific task or function it performs, all summarized clearly in a single line.	"Onboarding Buddy" helps new team members get up to speed by answering their setup and process questions from the team's Confluence space.
2. Target users	Who the agent is for. This section is intended to clearly define the target audience or the specific group of users for whom the agent has been designed. It explains the characteristics, needs, or roles of the individuals who would benefit most from using the agent.	New starters in their first few weeks, and the managers and buddies supporting them.
3. Job-to-be-Done	The core task, phrased from the user's perspective, is the fundamental objective that the user aims to accomplish. It represents the primary goal or action the user wants to achieve, expressed in a way that clearly reflects their viewpoint and intentions. Understanding this core task is essential for designing solutions or responses that effectively address the user's needs and expectations.	"Answer my onboarding questions clearly, and point me to the right Confluence page or person when I need more detail."
4. Inputs	What the user needs to provide for the agent to do its job effectively. For the agent to perform its tasks accurately and efficiently, the user must provide all necessary information and inputs required by the system. Providing clear and complete data enables the agent to understand the context and execute its functions properly, ensuring optimal results.	The new starter's question in plain language; their team or department (so answers are relevant); optionally, their role, to tailor the guidance.
5. Outputs	This specifies exactly what the agent is expected to produce as output, including the precise format it should adhere to.	A clear, friendly answer to the question, with a link to the relevant Confluence page for more detail, and the name of who to contact if the answer isn't covered.
6. Guardrails	The limits of what the agent must avoid and how to manage uncertainty.	Only answer from the team's approved Confluence space; never guess. If the answer isn't available, say so and point the person to the right contact rather than inventing a response.

Questions from the session

Access & visibility

Q: If I turn off "Open to all users", will that disable the agent on the Help Center landing page?

Yes. Agents are open to your whole organization by default, but you can restrict them. Once an agent has restricted access, it's only visible to the people you explicitly add; others won't see it in browsing directories or as an option for automation. So turning off open access will remove it from where all end users would otherwise see it (including the Help Center landing page). If you want it available to everyone there, keep it open to all users.

See: Rovo agent permissions and governance

Knowledge & data sources

Q: Where is the Rovo agent pulling its information from?

By default, every agent has access to all organizational knowledge, that is, all the organization-wide resources your admins have connected via the Teamwork Graph and Rovo, unless you configure it differently. You can narrow this by setting Custom knowledge (specifying exactly which resources it should look at), and you can also toggle on Web search so it can draw from public websites. Whatever the source, an agent never returns answers containing information the user doesn't have clearance to view, because it acts on that user's behalf.

See: Knowledge sources for Rovo subagents

Q: Can it access collaboration tools like Slack?

Yes, where the relevant connectors are enabled for your organization. Rovo connects with 50+ external tools, including Slack, Google Drive, GitHub, Salesforce, Microsoft Teams, Figma, and SharePoint. Once a connector is configured by your admin, Rovo Search and agents can discover and act across those sources, always observing the permissions of the person invoking the agent. So an agent can search Slack content that the user already has access to once the Slack connector is in place.

See: Knowledge sources for Rovo subagents

Q: Are there any downsides to enabling "All organizational knowledge" as the knowledge source?

It is convenient, but there are trade-offs worth knowing:

• Precision. A narrower, curated set of sources usually yields more accurate, on-topic answers. Pointing at everything can introduce noise and pull in less relevant material.

• Predictability. With a defined source set, you know where answers come from. "All knowledge" makes it harder to anticipate or troubleshoot a response.

• Currency. Broad access can surface old or superseded content alongside current material.

It never overrides permissions. Users still only ever see what they are entitled to. As a rule of thumb: scope the knowledge to what the agent actually needs for its job. Use "all organizational knowledge" for broad general-assistant use cases, and Custom knowledge (curated sources) for focused, reliable agents.

See: Knowledge sources for Rovo subagents

Permissions

Q: Does the agent inherit the permissions of the user interacting with it in Jira, in the Help Center, and in a Flow automation?

The core principle is that when someone interacts with an agent, the agent acts on that person's behalf and is bound by their permissions: if the user can't view a page, the agent can't tell them about it; if the user can't comment or delete, the agent can't either. This holds for both first-party (Atlassian) and third-party data.

• In Jira (used by a person), the agent operates within that person's permissions.

• In the Help Center (end user), the agent operates within that end user's permissions.

• In a Flow/automation, this is the important exception to understand. When an agent is triggered inside an automation flow, it cannot use its own tools. It can only return a text response, which you then feed into subsequent automation steps via the {{agentResponse}} smart value. For agents to act autonomously, they must be set up by a space or project admin through an automation rule; without that admin-configured automation, agents can't work autonomously. So in the automation context, the actions are performed by the automation rule itself (and its configuration), not by the agent reaching for its own tools as it would in a live chat.

Sources: Rovo agent permissions and governance; Rovo agent tools; Automating Rovo agents

Roadmap & future capability

Q: Where can we read about and follow the latest announced Rovo features?

The best places to follow Rovo's roadmap and releases are:

• Atlassian Cloud Roadmap: upcoming and recently shipped features: atlassian.com/roadmap/cloud

• "What's New in Rovo Agents" bi-monthly updates on the Atlassian Community, which highlight the latest features and a preview of what's coming next: Rovo articles on Atlassian Community

• Rovo product documentation: support.atlassian.com/rovo

• Feature requests & EAP sign-ups: you can follow specific features on the public Atlassian issue tracker (jira.atlassian.com) and join Early Access Programs when they're offered.

Specific Questions

Q: Will Rovo ever be "agentic" enough to use our customized Help Center as a real user would? Right now, the "Create a ticket" skill creates a work item in a void and doesn't use our custom assets that trigger routing to agent queues and automations.

This is great feedback and a limitation. Today, the create-ticket behavior creates a work item without necessarily firing the downstream custom routing and automations you've built. Deeper, fully "agentic" interaction with a heavily customized Help Center is the direction the technology is moving in, but I don't want to overpromise on timing or specifics. The most useful next step is to capture this as a concrete product request so it can be tracked. I'd recommend raising it on the public Atlassian issue tracker (jira.atlassian.com) with the details you've described (custom assets, queue routing, underlying automations), and voting on or following any existing requests for the same capability.

Capturing knowledge gaps (unanswered questions)

Q: I have a Confluence-based first-level support agent. When it can't answer because the information is missing, I want to capture that question as a knowledge-gap signal, ideally emailing the exact question to a shared Outlook mailbox if the asker approves. Is that possible, and if not, what would you recommend?

This is a strong use case; closing the loop between "what people ask" and "what's missing in Confluence." A few approaches, roughly in order of how well they fit Rovo today:

• Create a Jira issue for the gap (recommended). Instead of (or as well as) email, have the agent log unanswered questions as issues in a dedicated "Knowledge Gaps" Jira project. This gives you a structured, analyzable backlog you can prioritize and turn into Confluence content. It fits naturally with the agent's available actions and your content-improvement goal.

• Confirmation step before logging. Build the "if the asker approves" behavior directly into the agent's instructions: when it can't answer, it asks, "Shall I log this so the team can add it to our knowledge base?" and records it only if the answer is yes.

• Email to a shared mailbox. Email/notify steps are available in Atlassian Automation, so emailing a shared Outlook mailbox is achievable, but note the key constraint below about how agents behave inside automations.

Important constraint: when an agent is triggered inside an automation, it can't use its own tools; it only returns a text response (available as the {{agentResponse}} smart value). So the pattern is: the agent detects/answers, returns the unanswered question as text, and then the surrounding automation flow does the "doing" (creating the Jira issue and/or sending the email).

Net recommendation: have the agent return the unanswered question as text, then use an admin-configured automation flow to (a) log it as an issue in a dedicated "Knowledge Gaps" Jira project and optionally (b) email your shared mailbox. Add a confirmation step so it's only captured when the asker approves. You get the same outcome (answer the person, capture the gap) plus a structured, analyzable backlog to drive Confluence improvements over time.

See: Rovo agent tools; Automating Rovo agents

Working with sub-agents

Q: When would you use a sub-agent, and can you give some examples?

You use a sub-agent when a main agent needs to delegate a specific, specialized task to a focused helper, like a coordinator handing part of a job to a specialist. It keeps each agent's instructions clean and lets you reuse the specialist across multiple agents.

A note on terminology: at Team '26, Atlassian renamed what used to be called "Scenarios" to Subagents in the new unified Studio. If you've seen older material referring to scenarios, subagents are the current equivalent. In current Rovo, knowledge sources, deep research, and web search are configured at the subagent level.

When to reach for a sub-agent:

• The task is complex enough to need its own focus. Breaking it out keeps each agent reliable, rather than one bloated agent trying to do everything.

• The sub-task is reusable. The same specialist can be called by several different agents.

• You want different knowledge or capabilities for one part of the job: for example, a research-heavy step that needs deep research or web search turned on, while the rest of the agent stays lightweight.

• You want to control when a specific behavior triggers. A subagent runs when a user's prompt matches what it's built for.

Examples:

Main agent	Sub-agent it delegates to	Why
Customer Feedback Triage	Duplicate Issue Checker	Searching Jira for existing matches is a discrete, reusable skill.
Support Assistant	Deep Research Reporter	One step needs deep research mode (long-running, web, and knowledge-heavy), while the rest stays fast.
Incident Response Assistant	Runbook Lookup Specialist	Pulling the right steps from a tightly scoped runbook knowledge source is a focused, reusable task.
Release Notes Writer	Jira Changelog Summarizer	Pulling and condensing issue history is a clean, repeatable job.
Sprint Demo Prep Coach	Talking-Point Generator	Turning each issue into plain-language talking points is a focused, reusable task.

In short, think of a sub-agent like calling in a specialist. The main agent is the coordinator who knows the overall goal; when it encounters a task requiring focused expertise (or specialized knowledge, or deep research), it hands that piece to a subagent built specifically for it. That keeps each agent simple, reliable, and reusable, instead of one giant agent that tries to do everything and does none of it well.

See: Agents (overview, including delegating tasks to subagents); Knowledge sources for Rovo subagents (configuring custom knowledge, deep research, and web search per subagent).

Building & testing agents

Q: What's the difference between the manual option you chose versus doing it "the chat way"?

Good question, and it does make sense. There are two ways to set an agent up:

• Guided / chat setup: you describe what you want, and Rovo helps build the agent conversationally, filling in the structure for you. It's the fastest path and ideal for most agents.

• Manual setup: you fill in the configuration fields yourself, giving you more direct control over each part of the definition.

In the session, I switched to manual because of an error in the live flow, but the end result is the same agent either way. The guided route is quicker and great for getting started; the manual route gives more control and is handy when you want precise wording, are building something more complex, or want a configuration you can reuse. Choose guided by default, and reach for manual when you need finer control.

Q: I always struggle with the "Evaluation" of my agents and end up training them manually and inefficiently. Could you show how to do it correctly?

You're not alone! Evaluation is the part most people find fiddly. I didn't cover it in depth in this session, so rather than give a half-answer, I'll put together a short, focused walkthrough on agent evaluation (setting up test cases, reviewing results, and iterating sans manual grind) and share it. If you'd like, I can run a short follow-up specifically on this. Watch this page for the guide.

Thanks again for joining the class and your participation!

Please join us in one of the upcoming sessions here! https://community.atlassian.com/learning/calendar

[Jason Krewson]

Thank you so much for the class and this post!

[nmouradian]

Thank you for actually spending the time to write all of this, very useful and much appreciated!

[Cristian Zuccalá]

Thank you so much for the class!!

[Jordi Romera]

Hello! I didn’t realize this class existed. Would it be possible to view it?

[Grazia P]

Thank you for sharing this post!

[Jason Krewson]

@Jordi Romera you can join upcoming sessions at the below link, this also has other classes as well. 

https://community.atlassian.com/learning/calendar