Extended Testing Window for New Rovo Agents Backend Model Until April 14

[#1]

We’re sharing an important update on the rollout of the new backend LLM model that powers Rovo agents.

In our original announcement, we said all remaining agents would move to the new model by March 31. However, based on your feedback, we’re adjusting that plan.

What’s changed

1. You asked for more time to test – we’re giving it.
   Many of you told us you need a bit more runway to validate critical agents, especially complex automations. We’ve heard you, and we’re extending the testing period for 2 more weeks.

2. Early results look good.
   So far, around 30% of existing agents traffic is using the new model. Across those agents, we’re seeing a large reduction in errors compared to the previous model, and better stability overall.

3. Extended testing window (all customers).
   We’re extending the testing window for the new model to April 14 (US date). Until then, you’ll keep the ability to choose which model your agents run on.

How this works

• Existing agents will continue to default to the old model for now.
  We won’t force‑flip your existing agents yet.

• You have an opt‑in option to move agents to the new model.
  In Studio, you can switch an individual agent to the new model, run your tests and evaluations, and switch back if needed during the testing window.

• On April 14 (US date), all remaining agents will be moved to the new model and the opt‑in/opt‑out toggle will be removed.

Recommended way to test

If you haven’t tested the new model yet, we strongly recommend you:

Duplicate (recommended for high‑value agents)

1. From Studio, select Agents

2. Using the more actions (…) menu, select Duplicate

3. The duplicated version of the agent will automatically use the updated model without affecting the original agent.

4. Run your key prompts and evaluations.

Use the model toggle

1. From Studio, select Agents

2. Select the agent you’d like to test or migrate

3. You should be taken to the agent’s Overview page

4. Look for Swap to new model

5. Toggle it ON

6. Run your key prompts and evaluations and decide whether to keep it on the new model, or swap it back while you iterate.

If something looks off – please contact our support team

If you notice regressions or unexpected behavior when running on the new model, it’s strongly preferred that you open a support ticket rather than only sharing feedback in this blog.

Support tickets let us:

• Access the relevant logs and telemetry for your agent

• Track issues systematically across customers

• Prioritize and fix problems faster.

When you open a ticket, please include:

• A link to the affected agent

• A short description of what changed (e.g. “automations failing”, “unexpected replies vs old model”)

• One or more example prompts where you see the problem

• Debug logs from your conversation (click the { } button under the agent’s response)

---

We’ll continue to monitor migration rates, opt‑in/opt‑out behavior, and support volume closely through April 14, and we’ll update this page again if anything changes.

[Amish Khatri]

What is the impact on all out-of-box agents? Are their LLMs also being changed? How can they be duplicated?

[Jensen Fleming]

@Amish Khatri  Great question! They're LLM will be changed, we are considering flipping theirs before the April 14th deadline, but for now, you can duplicate an OOTB agent in the same way you can any other agent. Navigate to it -> `...` and click Duplicate. 

[Raghavendran_Narayanan]

@Jensen Fleming  - Need help. Would you be publishing the known error reported so far with this new model and steps to remediate.  Additionally any best practices you can share to get the most out of the new models , like updating the design, instructions etc , that would be much appreciated! .

[Julian Hermes]

Hey Jensen, I'm not sure, but there might be an issue with using Rovo-Agents with the new model via automations. Even when I duplicated our Agent and switched it in our automation it is not working since today. We did not change the automation and it worked well till today.

[Prasath Venkatappan Badri]

Hi Jensen,

Our Jira Automation rules are failing with an "Aborted" status specifically when the Rovo Agent component is used.

Looking for any advice or confirmation if this is a widespread issue.

Thanks,
Badri Prasath V

[Nahed Hamdi]

Hi Jensen,

We’re currently facing the same issue with Jira Automation, where rules involving Rovo agents are getting aborted.

Could you please advise if there are any known limitations or recommended patterns to handle this?

Thanks,

[Barbara Szczesniak]

@Julian Hermes @Prasath Venkatappan Badri @Nahed Hamdi In case you are not aware, a new incident is reported on the Jira Status page in relation to this issue. 

[Fabrizio Magistrelli]

We are also getting aborted automations using ROVO

[Zita Bagi]

"If something looks off – please contact our our support team"

Using "our our" instead of "our" looks off.

[Jensen Fleming]

Apologies for the delay, I was OOO last week. For any issues/errors that you see, it's imperative that you create a support ticket for us. It is very difficult for us to investigate issues via this blog post. 

I will look into the automation issue, I haven't see any other reports on this, but support tickets will help us investigate, track and communicate directly with you. 

[Arman Nejad]

fyi gemini 1.5 pro is not a new model by any means. it was released 2 years ago.

[Jensen Fleming]

Hi @Arman Nejad -- we aren't using Gemini 1.5 Pro. We are using Gemini 3 Flash, which came out in December.

[Aleksander Wielgat]

Well, the new back-end for orchestration you use completely destroyed my agent, it's unusable now, no thanks, it was waaaaay more smart and better before, now i have to specifically tell it to read forms if there is any in the ticket, add skill to just read the ticket, it blabs it's reasoning when not asked inside a draft for answer, it's trash now :( 

[cbouchard]

When will we be able to choose our LLM being used by Rovo?

[Jensen Fleming]

@Aleksander Wielgat -- are you able to send me more information on your agent? It shouldn't have fundamentally changed it so drastically - especially on needing to add additional skills you didn't need before. Can you open a support ticket and add me to the ticket/tell support to send me the ticket in Slack? 

[Jensen Fleming]

@cbouchard -- I don't have an official date to share at the moment, but we are fast tracking it and we expect you to have access this quarter. You can follow the feature's progress here: https://jira.atlassian.com/browse/ROVO-275

[Frank Sherwood]

Since it's now April 28, it appears the window has been further extended.  Any word on what the new cutoff is? Not terribly soon I hope.

It seems to me the new Agents model in Studio is not fully ready for release yet.  There are serious doc and design gaps around the old "scenarios" model and the new "subagents" model.  The relationship between the parent agent and subagents is not at all clear.

Docs appear to claim there still is/must be exactly one "default" subagent - like is true for scenarios in the old model.  But there is no way to designate a subagent as default. When I test migrated my recently created scenarios agent, the new agent created my default scenario as a subagent with trigger "Fall back to this subagent when none of the other subagents are applicable"

If that is what should determine the default subagent, then it's never going to be dependable.  What prevents TWO subagents from having that kind of trigger?  Or what requires ANY subagent to have such a trigger?

I know, I need to open a support ticket.    ;-)

[Jensen Fleming]

@Frank Sherwood -- Good catch, and sincere apologies on the docs! We’ve corrected theme as of this morning; there was a misprint. In the new model there’s no such thing as a “default subagent” in the old, hard‑required “default scenario” sense.

Instead:

• The parent agent owns the core/default behavior (its own instructions, skills, and knowledge).

• Subagents are optional specialists you can route to when it’s helpful.

• If you want one of those subagents to behave like a fallback, you can give it routing copy like the migration template:

  “Fall back to this subagent when none of the other subagents are applicable.”

With this change, we intentionally removed the requirement that there must be a fallback/default. For most agents that requirement was doing more harm than good: it pushed people into creating a “magic catch‑all scenario” even when the main agent instructions were the right place for that logic, and it made the model harder to reason about.

-----

As for the model change. we are progressively rolling out the changes, which started on April 14th. We don't have a hard date, but likely complete the rollout in the next 2 weeks. 

[Frank Sherwood]

Thanks @Jensen Fleming that clarifies.

I think I need to restructure my agent slightly for the new parent/subagents model.  What I'm building is effectively a sequence of agent actions that need shared context. With human-in-the-loop between each step. Originally I had the first action as the default scenario, then specific trigger prompts for the subsequent scenarios, with readiness gating in the instructions for each.   It shouldn't be hard to make the parent agent's role be just to gather the initial requirements and wait for prompts to run each subagent.

But I'm concerned the context may get too big though, so I'm also considering collecting summary context as markdown at the end of each step.  Then I could start a clean new session with the necessary prior generated context supplied as attachments or as copy/paste. 

Then it will just be separate agents entirely.

It would really help if an agent could produce a downloadable file as output. Apparently that's not possible though. I'm not keen on the alternative of writing to a (temporary) Confluence page.