Turn Rovo into a Specialist Agent : A simple trick to keep your Rovo Agent 100% On-Task

[Raghavendran_Narayanan]

Many teams love Rovo’s default “helpful assistant” behavior — it’s great for broad questions.
But when you're trying to build a specialist agent (e.g., Feature‑Manager‑Only), something frustrating happens:

❗ Rovo drifts.

Even with tightly written Behavior instructions and restricted Skills/Knowledge, the agent still wanders into:

• estimation
• test‑case writing
• general Jira/Confluence support

This happens because Rovo, by default, acts like a general assistant, even when you try to narrow it down — a behavior confirmed in Atlassian’s documentation, where agents are designed to “collaborate and move work forward” in broad ways unless constrained.
Also, agents retain generic knowledge unless you override it with specific sources. 

So even highly constrained instructions can only do so much.

---

✅ Pattern: Scenario Kill‑Switch (Make Rovo Stay in Its Lane)

This method forces Rovo to perform one job exceptionally well — and nothing else.

---

1️⃣ Create a Custom Scenario for Your Specialist Agent

Inside this scenario:

✔ Add all required Skills

Only the ones relevant to the specialty.

✔ Add only the knowledge sources needed

No generic Confluence spaces, no Jira projects outside the domain.

✔ Add scenario instructions

Explain exactly what the agent should do and what the scenario covers.

✔ Add relevant triggers

This increases match reliability and ensures the agent switches into the specialist mode predictably.

💡 Tip:
Before testing, make sure the scenario is enabled and that your triggers realistically match the queries users will type.

---

2️⃣ Set the Default Scenario to Empty (the Kill‑Switch)

Your default scenario should contain:

• 0 skills
• 0 knowledge
• No instructions
  (Optional but recommended) Add a polite refusal message:

  “Sorry — I’m a specialist agent for <purpose>, and I can’t help with that request.”

This effectively neuters the agent outside your specialist scenario.

---

🧠 Why This Works

Atlassian’s scenario system activates a custom scenario only when its triggers and instructions match.
When no custom scenario matches, Rovo falls back to the Default Scenario. 

So:

• Your specialist scenario = fully powered, fully capable
• Your default scenario = powerless, empty sandbox

This means:

✔ Rovo cannot answer anything outside the specialist domain

✔ Rovo cannot fall back to general “assistant mode”

✔ Rovo becomes a true domain‑specific agent, not a helpful generalist

✔ No need for long behavioral refusal prompts

This is a structural constraint, not a prompt‑based one — and structural constraints always win.

[Andrew]

Great advice!!! Thanks Rag.

[Wallace Chen]

@Raghavendran_Narayanan Thanks for sharing this – the “empty default scenario” idea is interesting and feels a bit different from what we’ve been practiced. Personally I haven't put this as empty. 

I’m curious: have you run any structured testing to validate that leaving the Default Scenario empty consistently improves behavior vs. having a populated Default with clear “how to use this agent” instructions and scope/guardrails?

For example, did you:

• Compare two versions of the same agent (one with an empty Default Scenario, one with instructions in Default) using the same set of prompts?

• Look specifically at cases where the model might otherwise “fall into” Default (ambiguous requests, mixed intent prompts, out‑of‑scope questions)?

• Try this across different contexts/products (e.g. Jira vs Confluence vs other tools), and if so, did the impact differ?

If you have any concrete test setup, examples, or metrics you can share, that would be really helpful for reconciling this guidance that we have. Looking forward your reply. Thank you.

[Raghavendran_Narayanan]

i, thanks again for the deep dive and the thoughtful follow‑up questions — appreciate it. Its a long post, but i am sorry, i could not help :). Please let me know, if you have followup questions.

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

I wanted to share a more structured breakdown of where the “Empty Default Scenario” approach made a meaningful difference in my testing, especially in setups where I maintain multiple specialist agents (e.g., Create Feature & Story Agent vs Refine Story Agent).

Why the Empty Default Scenario Helped in My Multi‑Agent Setup

In my “Create Feature & Stories” agent, leaving the Default Scenario completely empty (0 skills, no organizational knowledge, and no instructions) produced a very clean constraint:

• The agent cannot refine stories
• The agent cannot prioritize features
• The agent cannot read or process Jira content
• The agent cannot derive ACs or do any deeper reasoning

Because skills + knowledge = 0, the Default state is essentially “blind and powerless.”
It cannot hallucinate actions because it lacks the structural capability to do anything beyond basic language synthesis.

This gave me a clean separation of concern:

• My Create‑only agent stays strictly in the creation lane
• My Refinement‑only agent handles only refinement

---

2️⃣ Clarification: Where Default Alone Was NOT Enough

There was one boundary where Default=Empty still allowed leakage:

General knowledge questions (e.g., “How do I conduct Sprint Planning?”)

Since this uses the model’s generic embedded knowledge, Default=Empty doesn’t stop it.
To block this, I added a single hard‑stop instruction in Default:

Respond to the user exactly with:
"I am not authorized to help on this request."

Once this was added, all general Agile/process/Confluence/Jira coaching questions were correctly suppressed.

---

3️⃣ POC You Can Reproduce Quickly

Below is a reduced POC you can recreate in under 5 minutes.

Step A — Create a new agent

• Default Scenario =
  • 0 skills
  • No organizational knowledge
  • Instruction: Respond to user exactly: "I am sorry, I can only help with refinement of existing user stories."

Step B — Add a Custom Scenario (Story Refinement)

And activate it with the trigger + examples below:

scenario:

  name: "Story Refinement"

  trigger_prompt: |

    Activate ONLY for refining or improving EXISTING user stories.

    KEY SIGNALS (all must be present):

    - Refinement verbs: refine, improve, groom, polish, clarify, rewrite, tidy, clean up

    - Existing stories: "these stories", "the stories", "user stories", "backlog items"

    MATCH:

    - "Help me refine these stories"

    - "Make these user stories clearer"

    - "Check if these stories meet DoR and improve them"

    DO NOT MATCH:

    - "write test cases", "test scenarios", "test cases for"

    - "create story", "draft new story", "generate stories"

    - "estimate", "story points", "sizing"

  trigger_examples:

    - "Refine these user stories for clarity and DoR"

    - "Improve the acceptance criteria for these stories"

    - "Check if these user stories are clear enough and refine them"

    - "Polish these existing backlog items"

    - "Rewrite these stories to be more precise"

  negative_trigger_examples:

    - "Write test cases for this story"

    - "Draft acceptance criteria from scratch"

    - "Generate test scenarios for the feature"

    - "Estimate these stories"

    - "Draft new stories for this epic"

Scenario Instruction :

You are a specialized agent focused solely on refining EXISTING user stories.
Always display: "You have reached the Refine Stories scenario."

- Apply INVEST
- Improve ACs
- Improve clarity
- Provide constructive, actionable refinement feedback

4️⃣ Test Prompts & Observed Behavior

🟥 Prompts Correctly Routed to DEFAULT (Blocked)

• Write a feature for login functionality
• How should we run Sprint Planning?
• Rewrite a Confluence page
• Clone or duplicate a story
• Create AC from scratch
• Write test cases
• Estimate or story‑point a story
• Create new stories
• Split a story
• Generate a sprint report
• Restructure a Confluence space
• “That refinement looks great — now write test cases for it.”
• “I need to create a story and maybe refine it later.”

🟩 Prompts Correctly Routed to REFINEMENT Scenario

• “Can you check if this user story is clear enough?”
• “Here are 5 user stories — identify the weak ones and fix them.”
• “This story feels vague; make it better.”
• “refin teh user stroy plz”
• “can u help make this story better?”

🟨 Edge Cases (should trigger but didn’t)

• “Is this story good for development to review?”
• “Given a story, can you check if these AC are valid?”