nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Rovo Agent remembers too much — how do you control context between Automation runs?

Aditya Srivastav

Hi everyone,

I’m experimenting with Rovo Agents in Jira Automation and ran into something I’m not completely sure how to handle.

I have an automation that calls the same Rovo Agent whenever an issue moves to a particular status. The prompt is fairly simple and includes the issue details, but I noticed that the agent’s response sometimes seems to be influenced by what happened in previous executions.

For example, if the agent processed Issue A first and then Issue B, the response for Issue B can occasionally feel as though some context from the earlier execution is being carried over.

I was expecting each automation execution to be completely independent unless I explicitly provide previous context in the prompt.

So I’m trying to understand:

Does a Rovo Agent invoked through Jira Automation maintain any conversation/session context between executions?
If it does, how is that context scoped — per rule, agent, user, or issue?
Is there a recommended way to force every automation execution to start with a completely fresh context?
Are there any differences in context handling between Use Rovo and Use Rovo Agent?

I couldn’t find a clear explanation of this behavior in the documentation, so I’d be interested to hear how others are handling it.

Accepted answers

Arkadiusz Wroblewski

Hello @Aditya Srivastav

Run a small isolation test:

-Call the same automation using Use Rovo and explicitly pass only the current issue fields.
-Compare that with Use Rovo agent using the same prompt.
-For the agent version, check the agent debug log to see which read operations/skills it used during Issue B.

For me it looks like The automation prompt itself accidentally passes historical/current-issue data that overlaps previous runs or Agent retrieval makes previous information available again

Best,

Arek🤠

All comments

Robin Surland_qx626i

You have to add strict constraints to your agent’s prompt to explicitly forbid referencing prior chats like this:

"Treat every new session as a completely independent interaction."
"Do not assume, infer, or pull context from any past conversations, user history, or prior sessions."
"If information is missing from the current message payload, ask the user for it instead of guessing based on previous interactions."

Arkadiusz Wroblewski

Hello @Aditya Srivastav

Run a small isolation test:

For me it looks like The automation prompt itself accidentally passes historical/current-issue data that overlaps previous runs or Agent retrieval makes previous information available again

Best,

Arek🤠

Aditya Srivastav

Thanks Robin, that’s a useful suggestion. I’ll definitely try adding those constraints to the prompt.

However, I’m also trying to understand the underlying behavior here. If Rovo is actually maintaining any session/conversation context between Automation executions, I’d like to know how that context is scoped.

For example, if the same Rovo Agent is invoked by the same Automation rule for Issue A and then Issue B, are those considered completely separate sessions by design, or can the agent retain context from the previous execution?

I’m mainly asking because I’d prefer to solve this at the session/context level rather than relying only on prompt instructions to prevent the agent from using previous context.

If anyone can clarify how context is handled for “Use Rovo Agent” in Automation, that would be really helpful.

Aditya Srivastav

Hi Arka,

Thanks for the suggestion. I think the additional isolation test would make sense for a context/retrieval issue, but in this case the original poster has already taken it down to a very minimal reproduction.

The failure also occurs with a brand-new agent containing only a static instruction, with no smart values, skills, knowledge sources, or issue data involved. The same automation execution succeeds with Use Rovo but returns HTTP 400 with Use Rovo agent.

Because the agent also works when invoked directly from Rovo Chat, it seems less likely that historical context or agent retrieval is involved here.

That said, checking the agent debug log for the failed automation run would still be useful to confirm whether any unexpected read/skill operation is being triggered before the 400 response.

Gabriela - LeanZero

They're two different actions, and that answers most of it. Ben Costello's launch post for Use Rovo calls it "deliberately self-contained and secure, the only data it has access to is the data you pass to it in smart values", and says it "cannot access any projects, spaces, pages". Use agent is the opposite by design, the one you reach for when "you need to access other data outside the automation rule". So the isolation people quote at you belongs to the first action and doesn't carry over to the second.

For the carryover itself there's a candidate that has a documented scope. Rovo memory: "Each memory is scoped to you and to the specific Atlassian site you're using." Per user and per site, not per rule, per issue or per execution. The same actor account handling issue A and then issue B sits inside one scope, which is the shape you're describing.

Your gap is real though. Neither the automation page nor the agents page says whether memory reaches an agent invoked from a rule, and the memory page is written about Chat. So test it rather than take my word. Memory can be switched off, and the doc puts it as "Rovo will not store new explicit memories or use existing memories to personalize your answers". Turn it off for whichever account your rule runs as, then run A and B again.

Arkadiusz Wroblewski

Yes, Debug log is must have to understand that clean how Agent behave. How to configure the Use Rovo agent action | Cloud automation Cloud | Atlassian Support

As Rovo Memory Starting to be default i think that will be related. What is Rovo memory management? | Rovo | Atlassian Support