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

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.

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

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.

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.