The fastest way to tell if you’re about to hit Rovo Agent Studio’s ceiling: try to describe your agent’s job as a flowchart with more than one decision point. Studio agents are excellent at “when asked, do this one Jira/Confluence/JSM/Google thing.” They’re not built for “do this, then check a condition, then call our internal API, then decide what to do next based on the response.” That second shape is a Forge app, not a Studio configuration — and knowing which one you’re building before you start saves a rebuild. This page is the decision, not a tutorial for either path.

What Agent Studio actually builds

Studio is Atlassian’s no-code agent builder — inside the app switcher under Studio → Agents → Create. You either describe the agent in natural language or configure it manually, and per Atlassian’s own docs the pieces you’re filling in are: a name and description, instructions (a custom prompt defining how it responds), conversation starters, skills (orchestrating tools with reasoning), knowledge (a Confluence space or Jira project it can draw context from), tools (picked from a list), and a reasoning depth setting that trades speed and cost for how many iterative steps the agent takes.

The built-in tools, per Atlassian’s tools documentation, come from four categories: Jira (create/update work items, JQL search), Confluence (create, edit, move pages), Jira Service Management (raise requests, summarize incidents), and Google (send Gmail, create Calendar events). That’s the entire built-in surface. If your agent’s job is fully inside that list, Studio is not just adequate — it’s the right tool, and reaching for Forge would be over-engineering a form.

Where the ceiling actually is

Three concrete limits, all from Atlassian’s own documentation, not vibes:

  • A recommended maximum of five tools per agent. Not a hard block, but Atlassian’s stated guidance — past that, an agent re-interpreting a text prompt on every turn starts picking the wrong tool or dropping steps in a multi-step ask. This is the tell that you’re asking Studio to do too much orchestration.
  • No tool outside the four built-in categories. Need to call an internal API, a vendor’s webhook, a database, or literally any system that isn’t Jira/Confluence/JSM/Google? Studio has no field for that. There’s no “custom API call” tool in the picker.
  • No real conditional branching. Studio’s “skills” orchestrate the tools you’ve picked using reasoning over your instructions — it’s the agent inferring what to do from a prompt each time, not executing fixed code. For a single clear ask, that’s fine and often better than code (it’s naturally flexible to phrasing). For “if the issue is a bug and older than 30 days, do A; otherwise do B, then check a second condition,” you’re asking a language model to reliably execute branching logic every single run — and Atlassian’s own community and support material consistently flags multi-step conditional logic as where no-code agents get flaky.

Put together, the pattern is: Studio is for “call one of these known actions, well.” The moment your requirement is “run custom logic” or “reach a system not on the list,” you’ve left Studio’s design center.

What building in Forge unlocks

A Forge-built agent uses two manifest modules together, per Atlassian’s developer docs: rovo:agent declares the agent itself (instructions, prompt, which actions it can call), and action defines what it can do — a real Forge function. Per the action module reference, that function receives structured input from the conversation plus deterministic app context (the issue key, the content ID, the account calling it), can run arbitrary code — including calling any external API — and can return up to 5 MB of processed data (string or JSON) for the agent to turn into a natural-language response.

That unlocks everything Studio’s picker can’t offer: custom conditional logic that’s actually deterministic code (not re-inferred prompting), calls to any external system with an API, data transformation before the agent ever sees it, and — per the same docs — support for multiple Atlassian apps in one agent and hooking into automation rules so the agent can act asynchronously off an Atlassian event. It’s a real deployed app, with the build and maintenance overhead that implies (Forge’s dev cycle, permissions/scopes at install, testing), traded for the ceiling being gone.

The decision, concretely

Ask these in order — the first “yes” tells you where you land:

  • Does the job only ever touch Jira, Confluence, JSM, or Google, using one of the built-in actions? → Studio. Don’t build an app for this.
  • Do you need more than ~5 tools, or does the agent keep picking the wrong one / missing steps? → You’ve hit the documented tool-count ceiling. Start scoping a Forge rebuild of the busiest paths.
  • Does the logic have a real “if this, then that, else check something else” shape? → Forge. Studio’s reasoning is prompt-inference, not branching code, and it will be unreliable at scale on this.
  • Does the agent need to call anything outside Jira/Confluence/JSM/Google — an internal tool, a vendor API, a database? → Forge, no way around it. There’s no custom-API tool in Studio’s picker.

If you land on Forge, you’re not throwing away the Studio work — the instructions, knowledge sources, and conversation design carry over conceptually. What you’re rebuilding is the tool layer: Studio’s picked actions become Forge functions, which is exactly the piece that unlocks everything above.

Hit the ceiling and don’t want to be the one learning Forge to get past it? We take Rovo agents from spec to deployed — custom actions, external API calls, the multi-step logic Studio can’t do. Configure what you need and see the price and timeline instantly →