Build a Rovo Agent for Jira Triage in Rovo Studio

We built a Rovo agent in Rovo Studio, Atlassian's no-code builder for AI agents, that reads a Jira work item and suggests how to triage it. Then we asked it the same question on three real service desk tickets twice. With one line of instructions it made up all six component names it suggested, plus eight labels that sit on no work item on our site. With a version that spells the rules out, it picked only real components, suggested no labels, and answered "cannot tell" when a ticket gave it nothing to go on.

Someone asked on the Atlassian Community how people use Rovo in Jira "to actually reduce manual triage time" (747 views when we last looked). The accepted answer describes the idea in a paragraph: trigger an agent from automation when a work item is created, and let it surface likely duplicates and infer the component and priority. Nobody in the thread shows a build with real tickets, so here's ours, done on our test site, wolfaenpak, in a Jira Service Management space called Harbourline Support Desk (key HSD).

I also made a mistake that's easy to make. Our capture script typed version 2 and clicked Publish straight away, before the editor had saved it. Studio's Test panel on the draft answered beautifully, while Jira kept running the old one-line agent for almost half an hour. Step 8 shows how to spot it, because it cost me more time than the build.

The steps below end with what you should see on screen. Both sets of instructions are printed word for word, so you can copy version 2 and swap in your own component names.

[[steps]]

1. Create the agent in Rovo Studio from a blank page.
2. Write the first instructions, and see why one line isn't enough.
3. Limit the agent's knowledge to one Jira space.
4. Pick a reasoning tier and leave tools empty.
5. Decide who can use it, then publish.
6. Run it on real work items from the Rovo panel.
7. Rewrite the instructions with explicit rules.
8. Check the published version, then test again in Jira.

What we found when we tested it on three Jira tickets

One line of instructions produced confident inventions. v1 suggested components called Authentication, SSO, Integrations, Export Service, Access/Authentication and Email Services, and the space has none of those. Listing the allowed values fixed it: v2, asked the same question in Jira, answered Active Directory, Analytics and Reporting Service and "none fits", all from the list we pasted in.

The agent is good at spotting the same customer. Both versions linked HSD-9 to HSD-1 because both mention the workspace kellerbrandt, and v2 quoted the matching words from each ticket. It also needs permission to say it doesn't know. v1 guessed that the vague HSD-7 duplicates a password-reset ticket. v2 was allowed to write "cannot tell", and it wrote exactly that instead of guessing.

Rules don't make it perfect, though. On HSD-5, v2 quoted its own priority rule as the evidence instead of a sentence from the ticket, both in Studio and in Jira. And Studio's Test panel runs whichever version page you have open, while Jira runs what you published. Test from the draft page after a publish that didn't save, and you're testing two different agents.

Before you start

Note

Prerequisites

• A Jira Cloud site with Rovo turned on. Atlassian says you need to be a site admin to enable "Rovo, AI features, or MCP agents", and Rovo can't be switched on for an organisation registered with a generic email domain such as gmail.com.
• A Jira or Jira Service Management space with a few real work items (ours has 12 tickets), and access to Rovo Studio from the app switcher, and permission to create agents. By default "All users" can; an admin can narrow it in Studio settings.
• Agents allowed on work items. Atlassian's tracker says agents are "enabled by default for the Work items (Beta) surface"; if yours doesn't appear in the @ list, open the agent in Studio, select Surfaces and switch Work items on.
• Tested on 31 October and 2 November 2026. By 2 November the agent's sidebar also showed Surfaces, Access and identity and Triggers, which we hadn't seen on 31 October, so expect small label changes.

One thing to know before step 1. When you give the agent Jira as knowledge, it reads through the Teamwork Graph. That's Atlassian's data layer connecting your work items, pages and people across apps. On a work item, Atlassian says the agent "will use the work item’s summary and description, and may use comments and attachments to build context", and it "may use details from other work items in your site". With User's account, one of the two identities Atlassian lets you choose (it's under Access and identity in the agent's sidebar), it acts with the permissions of the person who asked, so it can't show you a ticket you couldn't open yourself. An agent set up with its own Agent's account uses whatever access it has been granted instead.

Step 1: Create the agent in Rovo Studio

Open Studio from the app switcher, select Agents, then Create an agent. You can describe what you want to Rovo in a chat, or build it by hand. I picked Start from blank, because I wanted to see the fields.

Give it a name people will recognise in a picker. Ours is Jira Triage Assistant, with the description "Suggests type, priority, labels, likely duplicates and missing information for new Jira work items." Keep the name distinct from Atlassian's own agents, because they show up in the same @ list as yours.

You should now see your agent's name at the top of the editor with a Draft badge.

Step 2: Write instructions for your Rovo agent (and see why one line isn't enough)

The Instructions box is what the agent always follows. Atlassian's guide to writing instructions says to "Keep your instructions relatively short to start with", so I did, and went very short:

Help triage new Jira work items.

Most first agents I've seen look like this, so it's worth seeing what it produces before you fix it. The answers in step 6 come from this one sentence. You should see it sitting alone in the Instructions box.

Step 3: Limit the agent's knowledge to one Jira space

Expand Knowledge. By default an agent can use "all organizational knowledge", meaning everything your admins have connected to the Teamwork Graph. For triage that's too wide. You want the agent comparing a new ticket with other tickets in the same desk.

Choose Custom knowledge, then Add knowledge. Tick Jira, search for your space in the picker and select it.

Select Add. You should see "1 custom knowledge source" next to the Knowledge heading. Narrowing knowledge doesn't grant anything new, by the way. The agent still only sees what it's allowed to see.

Step 4: Pick a reasoning tier and leave tools empty

Under Reasoning there are two choices, Quick answers and Think deeper. Atlassian's reasoning tier page gives Quick answers a limit of 10 loops and Think deeper 50. Its own example is "a customer support team might setup a triage agent with a low reasoning to quickly categorize incoming work". We kept Quick answers.

Leave Tools at 0. Tools are actions such as "Create work item" or "Update status", and a triage agent that only suggests doesn't need any. Atlassian recommends no more than five tools per agent anyway. In chat, an agent asks for confirmation before it runs a tool Atlassian counts as consequential, one that may change data.

Step 5: Decide who can use it, then publish

At the top right, the padlock icon is Agent access. It starts on Open, "All users in this organisation can use this agent". Atlassian's permissions page confirms that "When you create an agent, it becomes available for everyone to see and use by default."

For a first version I'd switch it to Custom users. If you add nobody, the agent is "only accessible to you". When you're ready, add your triage team. You have to add them one by one: "Restricting agent access to specific groups or teams is currently not supported." Everyone you add gets a role, Editor or Manager (a manager can also add editors and delete the agent). There's no use-only role yet, so everyone on your triage team will be able to change the instructions too. We wrote up the wider question of who should build and run agents in Rovo agent permissions.

Select Publish. On the first publish Studio asked whether we wanted to add tools ("Your agent could do even more"); we said No thanks. You should see Published and a version number next to the agent's name.

Step 6: Run the agent on real Jira work items

Open a work item, select Ask Rovo at the top right, type @ and the start of your agent's name, and pick it. Then ask. We used the same prompt on three tickets (where it says "project", read "space"):

@Jira Triage Assistant Triage this work item: suggest the work type, priority, component or label, any likely duplicates in the project, and what information is missing.

The three tickets were picked to be different. HSD-9 is a clear incident: "our staff sign in to Okta fine, but when they open Harbourline they are sent back to the Harbourline login screen every time", with the workspace name kellerbrandt. HSD-5 is narrower, an export link that "already says 'This export has expired'" ten minutes after the email. HSD-7 is the ticket all of us get. Its summary is "it doesn't work" and its whole description is "tried again this morning, still nothing".

You should see the panel header switch to your agent's name, and an answer referencing the work item.

What version 1 got right

On HSD-9 the duplicate work was good. The agent found HSD-1 ("Can't sign in with SSO since this morning") and HSD-8 (a third escalation from Keller & Brandt Logistics), and gave the reason: the same workspace, kellerbrandt. It said HSD-8 was already Highest, which is true. Its questions for the reporter on HSD-9 (Safari version, other browsers, console errors) are what I'd ask too.

Where version 1 made things up

Then the component and label suggestions. For HSD-9 it offered "Authentication, SSO, Integrations" and four labels: okta, safari, login-loop, kellerbrandt. For HSD-5 it proposed a component called "Export Service" and helpfully added "(if not available, this should be created ...)". For HSD-7 it guessed "Access/Authentication or Email Services".

Afterwards I listed the space's components with the REST API. Set EMAIL and API_TOKEN to your Atlassian account email and an API token, and swap HSD for your space key:

curl -s -u "$EMAIL:$API_TOKEN" "https://<your-site>.atlassian.net/rest/api/3/project/HSD/components" \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(len(d)); print(', '.join(c['name'] for c in d))"

16
Active Directory, Analytics and Reporting Service, Billing Services, Cloud Storage Services, Data Center Services, Email and Collaboration Services, Financial Services, HR Services, Intranet, Jira, Office Network, Payroll Services, Printers, Public Website, VPN Server, Webstore Purchasing Services

All 16 carry the description "Created by Jira Service Management". None of the agent's six names is on the list. Then I counted the eight new labels with a JQL count each (labels = "okta" and so on). Every one returned 0 work items on the whole site, while our control label, harbourline-demo, returned 53.

HSD-7 showed the other habit. With nothing to go on, v1 decided it was probably a duplicate of HSD-2, "Password reset email never arrives", because both were raised the same day and "still nothing" sounded like a missing email. It was a guess. Would a triager in a hurry have linked the two? Probably, because it read like a finding.

Step 7: Rewrite the instructions with explicit rules

Back in Studio, select Edit on the agent and replace the instructions. This is version 2, exactly as we typed it:

You triage new work items in the Harbourline Support Desk (HSD) space. You only suggest. Never change a field.
Answer with exactly five headings: Work type, Priority, Component, Duplicates, Missing information.
Work type: Incident when something that used to work is broken. Service request when the customer asks for something or asks a question.
Priority: Highest only when a whole customer team is blocked or the customer is escalating a repeat ticket. High when one customer cannot use a core feature. Otherwise Medium. Quote the sentence from the work item that decided it.
Component: pick exactly one name from this list, spelled as written, or write none fits: Active Directory, Analytics and Reporting Service, Billing Services, Cloud Storage Services, Data Center Services, Email and Collaboration Services, Financial Services, HR Services, Intranet, Jira, Office Network, Payroll Services, Printers, Public Website, VPN Server, Webstore Purchasing Services. Never invent a component.
Do not suggest labels.
Duplicates: name another HSD work item only if it mentions the same workspace, the same customer or the same error text, and quote the matching words from both items. If this work item is too vague to compare, write cannot tell and do not guess.
Missing information: at most three questions for the reporter, the ones a support engineer needs first.

Each line answers something v1 did wrong. The component list is pasted in because the agent had no reliable way to know which components exist, and Atlassian's guide asks you to define "what you’d like the agent to do and not do". The "cannot tell" line gives it a way out that isn't a guess. Labels are banned because nobody in our desk uses them for triage. If yours does, paste your label list the same way. Keep the component list in the instructions only while it's short and stable, because the agent won't know about a new component until you edit it. You should see all eight lines in the box. Before you publish, make sure the editor has saved them (step 8 explains why).

Step 8: Check the published version, then test again in Jira

Select Test at the top of the agent page. A chat panel opens beside the editor and runs the version that page shows: the draft on the draft page, the published version on the published page. It's useful, and it's also where I tripped.

Our capture script typed version 2 and clicked Publish straight after. The header said Published V2, and the editor still showed the new text. In Test on the draft page, "Triage HSD-9." came back in the five headings with Active Directory and quoted evidence. In Jira, the same agent kept ignoring the new rules. Five runs between 04:12 and 04:27 (four on work items, one in Rovo Chat) had no five headings, and one offered "Authentication / SSO (or Okta Integration)" and four new labels again. I even started writing this up as a delay between Studio and Jira.

Then I opened the published V2 page fresh and read its Instructions box. It said "Help triage new Jira work items." Test on that page answered the old way too. The editor hadn't saved the new text before Publish, so V2 was the old agent with a new number. The Test I'd trusted showed Draft in its header the whole time, and I didn't read it. I published again from the saved draft at 04:37, reloaded the page, and V3 held the full version 2 text.

So after you publish, reload the published version, read the Instructions box and run Test from that page before you try it in Jira. The version number alone won't tell you.

With V3 published, I asked the same long prompt on the same three tickets in Jira, between 04:38 and 04:41. Every answer used the five headings, even though the prompt still asked for "component or label":

Check, same prompt in Jira	v1 (31 Oct)	v2 (2 Nov)
Component answer is a real HSD component or "none fits"	0 of 3 tickets (6 invented names)	3 of 3
New labels suggested	8, on 0 work items site-wide	none
HSD-9 linked to HSD-1 and HSD-8 (same customer)	yes	yes, with quotes from all three
Guessed a duplicate for vague HSD-7	yes (HSD-2)	no, "cannot tell"
Priority evidence quoted	not asked	HSD-9 and HSD-7 quoted tickets, HSD-5 quoted its own rule

v2 still has rough edges. On HSD-5 it quoted its own rule ("High when one customer cannot use a core feature") as the evidence, in Studio and again in Jira. It linked HSD-5 to HSD-4 partly because both had the same reporter. On our test site one account raised every ticket, so that reason proves nothing; the shared export feature is the better one. And it picked Cloud Storage Services for HSD-5 in Studio but Analytics and Reporting Service in Jira, so expect some run-to-run variation on judgement calls. For an Okta loop, Active Directory is a stretch too, I think. I'd still take these answers to a triage meeting. Each claim comes with the words it rests on, so you can check it in seconds.

You should see your new headings in the Jira answer. If you don't, go back to the published version and read its instructions.

Optional: run the agent from automation on new work items

We didn't build this part. Everything in this section comes from Atlassian's docs. In an automation rule, add the Use agent action, select your agent and write a prompt. Atlassian's automation page says that if the agent can't act in automations (ours has no tools), "you'll need to add additional actions that use the output of the agent with the {{agentResponse}} smart value", for example a comment on the work item. Agents in automations "can be configured without requiring user confirmation", which is a good reason to keep a suggest-only agent suggest-only there too. Each agent call costs Rovo credits; we measured what one costs in Rovo agent pricing in Jira automation.

Request Router (formerly the Service Triage agent), Jira Triage Agent or your own Rovo Studio agent?

You may not need to build anything. Atlassian ships a Jira Triage Agent that "reviews a work item’s context and similar work in your space to recommend next steps, including field updates, duplicate work items, and related work to link". You saw it in our picker right under ours. For JSM there's Request Router, which Atlassian renamed from the Service Triage agent, and which "automatically triages incoming requests". Atlassian also suggests you can "duplicate some of these agents to make more specific versions with knowledge sources that you choose."

My suggestion is to try the out-of-the-box agent on a week of tickets first. We didn't test it here. Build your own, or duplicate theirs, when you need your desk's rules in it, like your components or what counts as Highest for your customers. The out-of-the-box agent doesn't come with those.

If it didn't work

1. The agent isn't in the @ picker on a work item. Check that Work items is switched on under Surfaces for the agent, and that Agent access includes you. Atlassian says restricted agents don't appear "in browsing directories or as options for automation" for people who weren't added.
2. Your new instructions don't show up in Jira. Reload the published version in Studio, read its Instructions box and run Test from that page. If it shows the old text, the editor didn't save before you published: open the draft, check your text is there, and publish again.
3. It invents field values. Paste the allowed values into the instructions and tell it what to write when nothing fits. It was the biggest single fix in our test.
4. It ignores a rule you wrote. On the Community, one admin's agent kept asking for details "despite explicit instructions in the prompt to never ask for details", and another's routing rule only held after they explained the structure of their lookup table and added an example. Atlassian's guide also warns that with too many instructions "the agent will choose parts to prioritize".
5. People see the agent who shouldn't. Agents are open to the whole organisation until you switch Agent access to Custom users, so do that before publishing.

What you have now

[[takeaways]]

• A working triage agent. Its knowledge is one Jira space, and it suggests a work type, a priority with the sentence behind it, a real component or "none fits", and duplicates backed by quotes. It changes nothing on its own, because it has no tools.
• What fixed it. A pasted list of allowed values and a written way to say "cannot tell" stopped the inventions.
• What to check after publishing. Reload the published version and test from that page, because Test on the draft page shows you the draft.

Next, try it on ten tickets from last week whose triage you already know, and count how often you'd have kept its suggestion. Thanks to the Community poster whose question started this one.

---

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.