Building Custom Rovo Agents with Forge

Rovo agents bring generative AI into everyday Atlassian work. Pre-built agents work great for standard tasks; but once use cases become more complex and demanding, combining them with Atlassian Forge is the way to go.

Forge provides the technical infrastructure, the security model, and the interfaces needed to equip Rovo agents with deep system integrations and specific logic.

The Foundation: Why Forge Is the Basis for Rovo

A Rovo agent built on Forge is, at its core, a Forge module that runs natively in the Atlassian Cloud. This brings relevant architectural advantages with it.

No external infrastructure required. AI requests and context data stay within the Atlassian Cloud environment. When using the Forge LLMs API, no separate server infrastructure or external OpenAI/Anthropic integration is required.

Automatic context inheritance. Forge actions run in the context of the calling person. The request includes a principal.accountId, so permission checks can build on the existing visibility and access structure of Jira or Confluence.

Native UI event handling. Agents can be addressed directly from the Rovo chat sidebar, or – indirectly, via automation rules – linked to events in Jira or Confluence.

The Anatomy of a Forge-Based Rovo Agent

Building a Rovo agent within the Forge framework essentially relies on two main building blocks, declared in the central configuration file, manifest.yml.

1. The Agent Module (rovo:agent)

This is where the agent’s identity is defined: name, description, icon, and the primary prompt (the persona). The description matters because Rovo uses the name and description to decide which agent is a match for a given user query. conversationStarters can also be defined here – suggested opening questions displayed in the chat.

2. Actions (action) and Function Calling

Unlike a plain chatbot that only answers questions, a Forge agent is meant to act. Actions give the agent specific tools; technically, these are regular Forge resolver functions. Rovo decides on its own, via function calling, when to invoke an action – for example, to read custom fields, run a JQL search, or trigger an internal workflow.

Important here: as with any other Forge resolver function, app developers and Atlassian share responsibility for ensuring actions are properly authorized. The pitfall for the team: it must not assume that permission checking happens automatically “through the AI.” It has to live in the action logic itself.

The Third Building Block: Event Handling via Automation Rules

Contrary to what one might assume, the rovo:agent module has no trigger field of its own for event-based execution. The “active,” background variant instead runs through a separate mechanism: automation rules.

Here’s how it works: you add a Rovo agent to an automation rule as a step. The rule then reacts to an Atlassian app event (e.g., “issue created”) or a schedule, and calls the agent with an additional, rule-specific prompt. The agent’s result can then be passed to downstream automation steps via smart values.

The practical difference from a classic Forge trigger module is that the event logic doesn’t live in the agent’s manifest, but in the separate, declarative automation configuration. That’s an additional layer you need to account for when designing the architecture.

The Limit: No Built-In Knowledge

One important aspect often gets lost in marketing materials: a Forge-based Rovo agent (also referred to as a “Marketplace Agent”) has no automatic access to the search and knowledge plugins that native Atlassian agents come with. Out of the box, it’s a bare-bones LLM.

This has two consequences for development:

Retrieval has to be built explicitly. If the agent is meant to access custom app data, that requires a dedicated action – it isn’t indexed automatically. Standard Confluence or Jira content can be attached as a knowledge source separately through the Rovo admin panel, but that’s an admin-side configuration step, not something the agent gets by default.

Prompt engineering differs from Rovo Studio. Prompts that work well in Rovo Studio (the no-code environment) don’t carry over 1:1 to Forge agents. Retrieval behavior and tool usage have to be explicitly instructed in the prompt, since the implicit capabilities of Studio agents are missing.

Anyone who ignores this difference risks building an agent that is syntactically configured correctly but, in practice, comes across as “clueless” – because it lacks the tools needed to produce the expected answers.

Practical Example: The Agent in Action

The interplay becomes clear using the example of a support assistant:

1. A user creates a ticket.
2. An automation rule reacts to the “issue created” event and calls the Rovo agent with a rule-specific prompt.
3. The agent evaluates the ticket data and, via a Forge action, runs a JQL search for related issues.
4. The results are summarized via the Forge LLMs API and added to the ticket as an internal comment – without any data leaving the Atlassian ecosystem.

From Development to Deployment

Declarative configuration. Most of the logic, scopes, and agent capabilities are structured directly in the Forge manifest.

Granular security scopes. Developers explicitly grant minimal permissions (e.g., read:jira-work), which simplifies the security audit for enterprise customers.

Security screening by Atlassian. Under Atlassian’s terms of use, Rovo agents are subject to a security review. If issues are identified, Atlassian can block the agent’s deployment or suspend access to the Rovo APIs until the issue is resolved.

Multi-environment lifecycle. Using the Forge CLI, the agent can be seamlessly rolled out and versioned across development, staging, and production environments.

Conclusion

The tight coupling of Forge and Rovo makes it possible to build not just simple chatbots, but deeply integrated, rule-based AI assistants with full control over data flow, permissions, and logic.

The difference from no-code approaches, however, lies not only in greater control but also in greater effort: event handling runs through a separate automation layer, and the lack of built-in knowledge connectivity makes explicit prompt and action design mandatory rather than optional.

Planning to build a custom Rovo agent on Forge? If your team wants to build it yourselves, our Forge Developer Trainings cover exactly that. Would you rather have it built and hardened for you? Our Atlassian development team is here to help.