Atlassian’s own performance guidance caps you at five tools per subagent — everything else about building a Rovo Agent is a form, not code, but that one number is the first real ceiling you hit. Building an agent in Agent Studio means filling in an Identity section and one or more Subagent sections — instructions, tools, knowledge, reasoning depth — then hitting Activate. No IDE, no manifest file, no deploy step. This page is the honest walkthrough: what you’d actually click, what a real “trigger + action + knowledge” agent looks like when it’s done, and where the no-code path stops and a Forge build starts.

What are you actually building when you “build a Rovo agent”?

Two layers, and the naming trips people up. The agent is the outer shell: its name, description, and standing behavior — the thing a teammate finds in Chat and talks to. The subagent is where the work actually lives — per Atlassian’s Studio docs, a subagent is “how you want the agent to behave in different situations,” and it’s the subagent, not the agent shell, that holds instructions, tools, knowledge scope, and reasoning settings.

A simple agent has one subagent doing everything. A more capable one has several, each scoped to a different job — the agent acts as a coordinator and hands a request to whichever subagent is built for it. If you’ve only ever chatted with one of Atlassian’s 20+ out-of-the-box agents, this distinction is invisible; it becomes the thing you’re actually configuring the moment you build your own.

How do you actually build one, step by step?

You can start from three places — Chat, Studio, or the assignee picker inside a Jira issue — and from any of them you get two paths:

Path 1 — describe what you want. You answer a few guided questions in a chat window (what’s this agent for, what should it be called, what should someone ask it), Rovo drafts a name, instructions, and conversation starters, and you select Next to review before it’s saved as a real, editable agent.

Path 2 — manual setup. Select “Skip to manual setup” and fill the form directly. This is the version worth knowing in detail, because it’s the same form either path lands you in:

  • Identity — Name, Description (what shows when someone’s browsing the agent list), Behavior (standing instructions on role and tone), and optional Conversation starters (generic ones auto-populate if you skip this).
  • Subagent → Instructions — a custom prompt defining how this subagent responds to a request. This is the actual “system prompt” layer, in plain language.
  • Subagent → Skills — guide how the subagent approaches a task and which of its tools to reach for, before it acts.
  • Subagent → Tools — the actions it’s allowed to take. Atlassian’s own guidance: keep it to five or fewer per subagent, filtered by app or keyword, or tool-selection accuracy degrades.
  • Subagent → Knowledge — the context it reads before answering. Three modes: all organizational knowledge, custom (you pick specific Confluence spaces, Jira projects, or Google Drive folders — picking a Confluence parent page pulls in its child pages automatically), or none.
  • Subagent → Reasoning — how much iterative thinking it does before responding, trading speed and cost against answer quality.

Select Activate, and the agent exists — sharable, chattable, done. No separate publish or deploy step; Activate is the ship.

What does a real “trigger + action + knowledge” agent look like?

Concretely, using only components Atlassian ships:

  • Trigger — how it gets invoked. Three real options: someone chats with it directly in Rovo Chat; someone types /ai (or /Rovo) while editing a Jira issue or Confluence page; or a Jira/Confluence Automation rule fires the “Use Rovo agent” action — you pick the agent, write a prompt (which can reference ticket fields), and the reply lands in {{agentResponse}} for a following step to use. That third one is the closest thing to a real event trigger the no-code builder gives you, and it still needs a project or space admin to build the rule — the agent itself doesn’t listen for events on its own.
  • Actions (tools) — the concrete out-of-the-box set spans creating a Jira work item, updating a work item’s status, running a JQL search, drafting or updating a Confluence page, creating a Jira Service Management request, and (via connected third-party tools) sending a Gmail message or creating a Google Calendar event. Every one of those is rate- or scope-limited in ways worth knowing before you rely on them: bulk Jira actions cap at 20 work items per run, agent-created calendar invites cap at four attendees, and required Jira fields can still force a follow-up question back to the user.
  • Knowledge — a scoped read source, set at the subagent level as described above. This is what turns “generic chatbot” into “knows our release process” — point it at the actual space or project, not “all organizational knowledge,” if you want consistent, on-topic answers.

Put together: a “release notes agent” might trigger on /ai inside a Confluence page, hold the tool “create/update Confluence page,” and scope its knowledge to the engineering space’s changelog history. Nothing here is bespoke — every piece is a dropdown selection.

How do you test it before anyone else sees it?

There’s no separate staging environment — you test in the same Chat interface you’d use it in day to day. Build the agent, chat with it directly, and check three things: does it call the tool you expect (not a different one, not none at all), does it read from the knowledge scope you set rather than guessing, and does it stay inside the instructions you wrote when the request is slightly off-script. Because agents inherit the permissions of the person using them rather than getting their own access grant, also sanity-check the answer under a normal team member’s account, not just an admin’s — what the agent can see and act on will differ.

Where’s the ceiling — and when do you actually need Forge?

Be honest about this rather than selling past it. Agent Studio’s tools are the actions Atlassian and its connectors ship — Jira, Confluence, JSM, Google. There is no field anywhere in Studio for “call my own API” or “run this custom function.” The moment a use case needs a bespoke action — hitting an internal service, multi-step business logic, anything beyond the built-in tool list — you’re not extending Studio, you’re building a Forge app with a custom rovo-agent module, which means actual code, a manifest, and a deploy pipeline, not a form.

That’s a real fork in the road, and it’s a different decision from the one this page covers — we’ve kept the depth on when to make that call, and what you gain and give up either way, on a separate page rather than re-arguing it here. The one thing worth internalizing before you start clicking through Studio: if your mental model going in is “no-code,” build the simplest version first and hit the five-tools-and-built-in-actions wall on purpose, rather than guessing at Studio’s edges from the outside.

Should you build one yourself, or have it built?

If the agent is genuinely “answer questions from this Confluence space” or “file a ticket from a chat message,” Agent Studio is the right tool — build it, it’s a form, not a project. Where teams get stuck is everything around the form: instructions specific enough the agent doesn’t wander, knowledge scoped tightly enough that answers stay accurate, and — most often — realizing mid-build the real requirement needs a custom action Studio doesn’t have, at which point the work quietly becomes a Forge project with none of the up-front planning a code project usually gets.

Hit Agent Studio’s ceiling, or don’t want to be the one debugging tool selection and knowledge scope by trial and error? We take Rovo agents, Forge apps and Jira customizations from spec to deployed. Configure what you need and see the price and timeline instantly →