AI agents now enter Jira through three doors. Where are you putting the gate?

[Sami Shaik]

In the space of a month, agents have picked up three separate doors into Jira, and I am genuinely unsure where the gate belongs. Curious how others are handling this, because I do not have it figured out.

The three doors, all checked in my own instance this week:

1. Workflow rules. The new editor's Perform actions includes Trigger agent action: a transition can invoke a Rovo agent.
2. Automation rules. My rule builder already shows a Use Agent action today, and this week's Atlassian Cloud changes post lists a Claude agent action rolling out too.
3. Direct assignment. Claude Agent for Jira (the Marketplace beta, announced by Atlassian in June) makes the agent an assignee. The admin thread here from a few weeks back covers its gaps well, including that nothing restricts who can trigger it. 

Here is what makes this tricky: each door has a different lock, and none of the locks is about the agent. Workflows are gated by who edits workflows. Automation is gated by who edits rules, but a rule fires for anyone who triggers it. Assignment is gated by whether the app is installed, full stop. The org-level agent policies mentioned in this week's changes post are not visible on my site yet, so for now that layer is a promise, not a control.

So, two honest questions:

1. Where are you putting the gate today: workflow design, automation governance, app installation, or nowhere yet?
2. What did you allow an agent to do first, and what is still off the table?

Even a one-line "we have not touched any of it yet" is a useful answer. That is data too.

[Brita Moorus]

...I'd rather start with AI as a co-pilot than an autopilot 👀 Once the governance model is mature and there's confidence in the outputs, it's much easier to gradually expand what agents are allowed to do.

[Sami Shaik]

@Brita Moorus 

"Co-pilot before autopilot" might be the best one-line summary of this whole thread 👏

And it maps neatly onto the three doors: the assignment door is co-pilot by nature, a human reviews every output. The workflow and automation doors are autopilot by construction, nobody reviews an agent step firing inside a rule at 2 AM 😄

So your sequencing basically writes itself: earn the confidence at the door with a human in the loop, then gradually open the other two.

One thing I am curious about 👀 would you treat read-only agent steps (summarise, draft) as co-pilot territory even inside automation? Or is "inside a rule" autopilot by definition for you, no matter how harmless the step looks?

[Richard Scholtes]

You can always define what the step is that the agent takes here. Even in an automation, the output could just be an evaluation that is documented as an internal comment, on which then a human is reviewing and acting. So yes, having this there has some risks, but if you chose the people in your organisation carefully that were allowed to be admin, automations will be the smaller problem I think. If you were able to establish a culture around your AI usage that ensures, that common sense is never turned off, the risk is manageable.

[Richard Scholtes]

Governance is needed on all levels. We as a heavily regulated company, that still wants to implement AI for process efficiency tasks are aware of that. Our plan going ahead will probably be to use our own build AI App Store internally, that is using self-hosted models and 3rd party via MCP. So all the logging, barriers, rights management, monitoring etc. lies in our own application. That's why I am really glad that Atlassian is not using their MCP as a one-way street, as some other software vendors do.

[Sami Shaik]

@Richard Scholtes 

I asked about three doors and you casually walked in with a fourth one you built yourself 😄 Respect.

An internal AI App Store fronting everything means the logging, rights management and monitoring live in one place you control, instead of scattered across workflow config, automation governance and app installs. For a regulated company that consolidation is the whole game: audit wants one throat to choke, not three 🎯

And +1 on the MCP point, that openness is exactly what makes a self-hosted gateway pattern like yours possible.

Genuinely curious though: when your store fronts the access, do the native doors (the workflow and automation agent actions) get blocked on the Atlassian side too, or do they stay technically open with policy saying hands off? That gap between blocked and policied feels like where regulated setups live or die 🤔

[Richard Scholtes]

I agree and we are not fully into the setup, yet. But if I will be the one to decide this - which I hope - than we will not close the general usage down, but what appears to be the "normal Rovo" is really an agent that is created by our AI app store on the base of the MCP data and Rovo engine and re-distributed to be available on Atlassian.

This way it still feels natural to the user and there is no extra effort felt to get the functionality while we keep the governance air-tight.

So yes, technically speaking, general use for everyone will be closed off, but they don't know and won't miss it

[Sami Shaik]

@Richard Scholtes 

This answers my blocked-vs-policied question better than I hoped 🎯 Fronting normal Rovo through your own store via MCP means the gate is architectural, not just a policy document: the path everyone actually uses runs through the layer you log and control. And your split on read-only vs write steps is the pragmatic middle I suspected existed: let agents read and summarise early, make them earn writes.

Between your fourth door and the co-pilot-first sequencing above, this thread has become a better governance playbook than anything I could have written alone. Thank you for bringing the regulated-company view 🙌

[Becker_ Rene]

The way I see Rovo:

--- Positive ---

- Nice addition to find stuff in Confluence and Jira

- Good for gathering info throughout the systems

- Delivers technical knowledge (like API), not only content

- semantic understanding could be worse

--- Negative ---

- Atlassian is too overconfident in Rovo's usefulness

- token usage is very limited (I understand why, but it makes it hard to use)

- a very hard cutoff in functionality (due to strict token limits)

- not good with keeping context (but it's getting better)

- because of bad UI placement (for example JSM) it's frustrating users, making them not want to use Rovo

- semantics could be better

- slooooooooow

- User UI: unless you use agents, it seems(!) to not keep my contextual commands like "be my buddy", "give short answers", "do not use contractions" etc. ->

there needs to be more of a Knight Rider-style relationship for it to become a real co-pilot for users. I took that approach with Microsoft's Copilot and (unless they again update their models), it's become really useful because I modeled it to what I deem to be a helpful Copilot, not what others think.

Whenever I tried to work with Rovo in Automation or via the regular User-GUI I felt very limited in what was actually possible or what info I might get. Sometimes I am surprised, what Info I actually get (positively) and sometimes I wonder how poor it is to semantically abstract thoughts.

---

As for the three(/four) gates specifically

:

Workflows: I actually never used Rovo in it. But I am keen to try - I just haven't had a use case yet (do you have examples I could use?)

Direct Assignment: Might be an idea for JSM but I haven't got a use case for JWM yet (at least not without MCP)

Automations: That one is tricky. I tried to use it in Confluence (had no use case yet for JWM) and I ran into hard limits that made it hard to use for me.

I had two cases in Confluence:

1) Convert user-created knowledge pages to standardized Knowledge-Base pages with cleaned up text (uniform knowledge).

In Automation I was able to tell the Agent to pull a page -> good

I then asked it (without change yet) to create a new page with the same content -> cannot

I then asked it to pull the page, get the text, convert it and give it back to me directly -> did but text was completely unformatted

I then asked it, to pull the page as ADF or storage and keep the formatting -> that did not work, and I also ran into

the 10.000 character's limit (not tokens - characters!)

And so I went back and forth until I gave up.

In the end -> I used API and AzureAI to do the job.

---

As for translation: Same problem.

---

So my question is (specifically for Confluence): What good is it, besides asking about content?

I know, I can make it create work items in Jira. But is that all?

Granted: I did not use MCP yet - maybe this resolves all my problems. But thinking about the larger picture, it might be, that I will simply use a different AI, that will attach to all systems and contexts in the company and just keep Jira and Confluence as a data source. -> Btw.: tried it and had better results than with Rovo

---

---------------------------------------------------

The next part is only guesswork / interpretation / speculation - None of it should be considered established fact!

---------------------------------------------------

Another thing that I noticed is, that, although Automations already have a hefty price tag, Atlassian seems to be preparing to make us pay for Tokens (I guess it will be packages) and will give us no option for cheap and expensive tokens (like ChatGPT or AzureAI does). Giving us options wouldn't fit the company strategy that I observed so far.

This would mean, that Rovo will become expensive pretty soon (based on what Atlassian has done in the past about pricing). And at that point, I guess Automation via Rovo (be it Workflow, Flows or MCP) will become something you will think about very critically (do I really need to ...).

My thought is, that we will have to try to keep user inputs (regular questions to Rovo) in check and the amount of tokens they will use, before we will even think about automations (or even roll them back). I feel like, that we are pushed towards a supplier lock in.

I know, I am very pessimistic here - but hey, it's not like they have done it before with the move to Cloud and it's the same with other large tech companies. It's the way to go to create a steady cashflow.

----------------------------------------------------

I know, I opened a whole other can of worms. Sorry for digressing so much.

But to get to the original question:

I experienced Rovo and decided to not use it for complex tasks and keep it only

for users who want to search semantically or need a few suggestions or summaries.

---

[Kirstin Seidel-Gebert]

We have AI features currently enabled for search and chat only.

[Sami Shaik]

@Kirstin Seidel-Gebert 

Search and chat only" is a completely legitimate answer to where the gate is, and honestly one of the most common ones right now 😄 That is the zero-doors-open position: agents can read and tell you things, but nothing fires inside a rule and nothing gets assigned. The nice property is that every step beyond it is a deliberate decision rather than a default. Thanks for adding the data point 🙏

[Sami Shaik]

@Becker_ Rene 
Fair challenge, and I will stay honest about what is idea versus experience: I have not put an agent step into a production workflow yet, these are the patterns I would trial first, in this order:

1. Narrate, not decide. Transition to Done triggers an agent that drafts a release-note style comment from the work item's fields and history. Read-only input, prose output, human deletes it if it is wrong. Lowest possible blast radius.
2. Summarise on close. Incident or request closes, agent drafts the timeline summary the postmortem or handover always needs and nobody enjoys writing.
3. Triage narration. On creation, agent adds a comment suggesting component, likely duplicate, and which team historically handled similar items. Suggestion only, a human still routes.

The common thread: early agent steps should produce text a human reviews, never state changes. State changes stay with the deterministic rules that already do them well.

On Confluence beyond "asking about content": the honest answer is that the value shows up when content becomes an input to work rather than a thing you query. Meeting notes rolled into a weekly digest, decision records summarised into onboarding pages, stale-page candidates surfaced for review. Whether that is worth the licence is a fair question and I suspect the answer differs a lot by team size.

[Becker_ Rene]

> the honest answer is that the value shows up when content becomes an input to work rather than a thing you query

Yes. That's what I meant by my Knight Rider analogy. If it feels forced, does things you did not ask for or do not work correctly, you spend more time being annoyed than being productive. And that's where Rovo still lacks or rather is being placed wrong by Atlassian. When I see JSM summaries I often think "How the h. did it figure that? It completely ignored the social factors and only took parts of the work item into consideration".

As for your approaches: I will try step 2. For reasons, 1 and 3 do not really work for us :-D

---

[Suresh]

1. I'm worked with Atlassian to have Rovo itself (not the individual agent) assigned a dedicated identity. The goal is that when a user asks Rovo to make an update on their behalf, the audit trail would ideally show "Rovo updated this on behalf of ". At a minimum, it should show that the action was performed by Rovo's own identity rather than by the requesting user. Please vote on this https://jira.atlassian.com/browse/AUTO-2432 if you like.

2.Agent Account Access is currently in Beta (EAP): https://earlyaccessprogram.atlassian.net/servicedesk/customer/portal/1651/group/1719/create/11847

where Agent can have its own Agent Access instead of Requesting User's. 

With this capability, agents can operate using their own Agent Access instead of the requesting user's permissions. 

However, this introduces an additional administrative burden, as agent permissions must be managed across projects within the instance. Actions will appear in history under the agent's name (for example, SB-Issue Closure Assessor).

Hopefully, we can also leverage the agent name in comments to improve auditability. As a best practice, whenever an action is performed automatically, I like to leave a breadcrumb indicating what executed it. Whether it's an Automation rule, a Workflow post-function, or a ScriptRunner script, having a clear audit trail makes troubleshooting and governance much easier.

.

[Sami Shaik]

@Suresh 

This is a genuinely valuable addition, thank you 🙏 Dedicated agent identity is exactly the missing piece the thread keeps circling: if agents act under their own accounts rather than borrowing a human's, then permission schemes, audit logs and access reviews all start telling the truth about what agents did. That is the org-level lock actually maturing, not just being promised. Signing up to look at the EAP, and the screenshots help, appreciated.

[Suresh]

If you prefer, please vote on this https://jira.atlassian.com/browse/AUTO-2337 and https://jira.atlassian.com/browse/AUTO-2432

[Mykenna Cepek]

When HIPPA is enable for a site, then Rovo is unavailable. There are some number (likely a small fraction) of sites for which this discussion is moot in practice. I still find it interesting in theory.

[Troy Anderson]

Sounds like enabling HIPAA is the answer, @Sami Shaik :-)

[Sami Shaik]

@Mykenna Cepek @Troy Anderson 

This is an important boundary for the thread and I am glad you raised it: on HIPAA sites the whole question is moot because none of the doors exist, no Rovo, no agent actions, nothing to gate. Which is itself a governance position, arguably the strictest one available, chosen by the compliance regime rather than the admin 😄 Worth everyone remembering that the entire discussion above assumes a site where these features ship at all. Thanks both.