Skip to content

SYSTEM Cited by 1 source

Rovo Dev Research Mode

Research Mode is a structured multi-agent investigation workflow inside Atlassian's Rovo Dev CLI, designed for "questions that are bigger than 'edit this file'" — cross-source investigations that span Jira work history, code in Bitbucket, product/architectural context in Confluence, and decision history in pull requests. It is the first-party Atlassian disclosure of how Rovo Dev handles discovery-before-implementation as a first-class workflow, distinct from the build/edit-the-file shape that the rest of Rovo Dev's surface (skills, sub-agents, prompt shortcuts, PR-bot) addresses.

(Source: sources/2026-05-22-atlassian-from-ambiguous-questions-to-action-research-mode-in-rovo-dev-cli)

What problem it solves

The pain points Atlassian enumerates are all investigation tasks that precede any code change:

  • "Which work items are ready for automation?"
  • "Why does this problem happen, and what mitigations exist?"
  • "Which bugs or security issues keep resurfacing across work items?"
  • "What decision led to this architecture?"
  • "What evidence do we have for a launch or roadmap decision?"

These are not "edit this file" tasks. The hard part is "figuring out where to look: Jira for work history, code for implementation truth, Confluence for product context, or pull requests for how decisions landed." Atlassian's framing is direct: "Prompt tuning helped the agent ask better questions, search more sources, and write cleaner summaries. But the core problem was not just prompt quality. It was research strategy." Research Mode is the workflow-architecture answer to that gap.

Architectural shape

The system composes a supervisor agent + 2-4 per-domain investigator subagents + a synthesis step + an action-handoff layer. The mermaid flow from the source post:

              Ambiguous question
                    │
                    ▼
        ┌───────────────────────────┐
        │   Supervisor agent        │  decompose into 2-4
        │   (decomposition,         │  research domains;
        │    dispatch, synthesis)   │  pick top-down or
        └───────────────────────────┘  bottom-up per domain
                    │
            ┌───────┼───────┐
            ▼       ▼       ▼
        ┌──────┐ ┌──────┐ ┌──────┐
        │Domain│ │Domain│ │Domain│   each subagent has a
        │  A   │ │  B   │ │  C   │   focused objective +
        │top-  │ │bottom│ │top-  │   bounded source set;
        │down  │ │ -up  │ │down  │   read-only;
        └──────┘ └──────┘ └──────┘   reports findings up
            │       │       │
            └───────┼───────┘
                    ▼
            ┌────────────────┐
            │ Round 1        │
            │ findings       │
            └────────────────┘
                    │
                    ▼
        ┌───────────────────────────┐
        │ Need dependency           │
        │ follow-up?                │ ── No ─→ Final report
        └───────────────────────────┘
                    │ Yes
                    ▼
            ┌────────────────────────┐
            │ Round 2                │
            │ (e.g. mitigation       │
            │  after cause)          │
            └────────────────────────┘
                    │
                    ▼
            ┌────────────────────────┐
            │ Final report           │
            │ + references           │
            └────────────────────────┘
                    │
                    ▼
        ┌───────────────────────────────────┐
        │ Next-step options                 │
        │ • Create Jira epics/tasks         │
        │ • Export deeper reports           │
        │ • Share Confluence summary        │
        │ • Create Confluence sub-pages     │
        └───────────────────────────────────┘

Seven-step workflow (verbatim from source)

  1. Analyze the query. "Identify the global objective and what decision the research should support."
  2. Break it into domains. "Split the work into 2-4 focused areas." See concepts/research-domain-decomposition.
  3. Pick direction per domain. "Choose top-down or bottom-up based on what that domain needs." See concepts/top-down-vs-bottom-up-research-direction.
  4. Delegate to domain subagents. "For each domain, Research Mode launches a focused investigator with a clearly scoped objective and a bounded set of sources to consult. Subagents report back to the main workflow, they don't take actions or make changes on their own. Developers review the synthesised report before any follow-up steps (creating a Jira ticket, publishing a Confluence page, etc.) are taken."
  5. Run another round if needed. "Some questions are sequential: first find causes, then research mitigations." See concepts/dependency-sequenced-multi-round-research.
  6. Synthesize a final report. "Merge findings by theme, resolve overlaps, cite sources, and recommend next steps." See patterns/synthesis-over-raw-search-results.
  7. Turn research into action. "After the report, Research Mode presents next-step options: create Jira epics and tasks for each workstream, export deeper reports for specific topics, share a summary on Confluence, or create follow-up Confluence sub-pages when a topic needs more detail."

Top-down vs bottom-up search direction (the novel lever)

The architectural lever that makes Research Mode distinct from a generic multi-agent search system is that search direction is a per-domain decision, not a global one:

  • Top-down: start with broad context (typically Confluence) and narrow toward specifics (Jira → code/PRs). Useful when the domain has clear architectural framing or when product/design intent is the load-bearing input.
  • Bottom-up: start at ground truth (code or PRs in Bitbucket) and trace outward to context. "Start in code or pull requests to understand what the system actually does, move into Jira to understand the work history, then trace back to Confluence to find the broader product or architectural context." Useful when "what the system actually does" may diverge from documented intent — i.e. when the implementation is the authoritative source.

"The direction is not a hard boundary. A domain can use both top-down and bottom-up research when needed. The important part is that the agent has a deliberate search sequence instead of searching every source the same way."

The architectural payoff: avoiding redundant searches by matching the search shape to the domain's evidence locality. See concepts/top-down-vs-bottom-up-research-direction for the load-bearing concept.

Permission-scoped read-only investigation

Three orthogonal design properties compose into a single safety envelope:

  • Read-only. "Subagents report back to the main workflow, they don't take actions or make changes on their own." No state mutation in the investigation phase.
  • On-demand. "It runs on demand when a developer invokes it for a specific question, not in the background, and not across teammates' private work." No background polling; no continuous monitoring.
  • Permission-scoped. "Built on the permissions you already have, Research Mode only reads from the sources a developer already has access to. The agent's scope is bounded by the same access controls that govern Jira, Confluence, and Bitbucket today."

The composition is what lets the agent operate over a sensitive cross-source corpus (work history, product context, code) without amplifying permissions or running continuously. The action-handoff layer (next-step options after the synthesis report) is the deliberate break between the read-only investigation phase and any state-mutating follow-up — the human reviews the synthesis before any Jira ticket is created or Confluence page is published. See patterns/read-only-on-demand-investigation-agent.

Outcome

"In sessions where users invoked Research Mode, more than 84% rated the experience as helpful. We do not treat this as causal proof, since Research Mode is often used for different kinds of tasks than standard Rovo Dev sessions. Still, it is an encouraging signal that structured research makes Rovo Dev more effective when users need serious context investigation before acting."

The disclosure pattern is the architectural signal: a measured retrospective with explicit selection-bias caveat, not a marketing-claim post.

What's not disclosed

The source post is at the workflow-shape altitude — what the components are and how they compose. It does not disclose:

  • The LLM(s) used per supervisor / per subagent / per synthesis step.
  • The per-domain context budget or token allocation.
  • The supervisor's decision logic for "need round 2?".
  • The synthesis-step prompt structure.
  • Per-domain or per-session latency envelope.
  • Per-session cost envelope.
  • Round-count limits beyond the named two.
  • Synthesis-quality evaluation methodology.

A future post disclosing any of these would be a high-value canonical follow-up.

Relation to other Rovo Dev features

Research Mode is a complement to the implementation-loop features documented in the 2026-04-24 Rovo Dev Driven Development retrospective:

Surface Mode Subagents Output Mutation
Implementation loop edit/build one-per-skill, ad-hoc adversarial review (!review-pr) code + tests + PR yes (writes code, opens PRs, deploys to dev shard)
Research Mode investigate 2-4 per-domain (top-down or bottom-up) synthesis report + next-actions no (read-only); action-handoff is a separate human-confirmed step

The composition: a developer can use Research Mode to scope an ambiguous question ("why does this problem keep resurfacing?") into a synthesis report with concrete next-actions, then convert one of those next-actions into a Jira ticket and hand it to the implementation loop for execution. The two modes operate on different points in the SDLC — investigate-before-acting vs. build/edit-the-file.

Seen in

Last updated · 542 distilled / 1,571 read