AI has long been part of the Atlassian product experience – as a summarisation feature in Jira, as a writing assistant in Confluence, as smart suggestion logic in Jira Service Management. With Rovo, Atlassian has built these capabilities into a dedicated AI layer that searches content, summarises information, and responds to queries.
One thing was still missing, however: a way to bring these AI capabilities into custom-built Forge apps. Anyone wanting to build an app that works with language models had to fall back on external providers. That meant managing their own API keys, running external infrastructure, and sending data outside of the Atlassian platform.
That’s changing. With the Forge LLMs API, recently released by Atlassian in preview, Forge apps can call Claude models directly – without data ever leaving Atlassian’s infrastructure. This article explains what that means in practice and which scenarios it opens up.
From a technical perspective, the Forge LLMs API is an extension of the Forge platform that allows apps to call language models – not through an external service, but directly within Atlassian’s infrastructure. Currently, Claude models are available in the Haiku, Sonnet, and Opus variants.
What does that mean in practice? A Forge app can send a request to a language model – say, the content of a Jira ticket – and receive a structured response, all without that data leaving the Atlassian platform in the process. For organisations with strict data protection or compliance requirements, this is a significant difference.
Closely connected to this is the Runs on Atlassian badge, which we’ve covered in previous posts: 5 Reasons to Switch to “Runs on Atlassian” Apps and How to Identify “Runs on Atlassian” Apps. This certification signal indicates that an app operates entirely within Atlassian’s infrastructure – no data flows out, no external hosting takes place. Apps using the Forge LLMs API can continue to carry this badge. Previously, adding AI features to a Forge app meant giving up this trust signal. That trade-off no longer exists.
What can actually be built with the Forge LLMs API right now? The following three use cases are realistic solutions achievable with the API in its current state. These are not hypothetical scenarios – they are practically implementable today.
Incoming Jira issues are often incomplete, inconsistently worded, or difficult to categorise. A Forge app can pass the content of a newly created ticket to a language model and generate a structured assessment: What is this about? What priority seems plausible? Are there similar existing issues that should be referenced? The result lands directly in the ticket – as a comment, a populated field, or an internal note for the responsible team. The model prepares the final human decision rather than making it.
Confluence pages often grow without clear control: content becomes outdated, structure grows inconsistent, cross-references get lost. A Forge app could analyse a page upon saving or on demand and surface relevant feedback: Which sections are thin? What’s missing compared to similar pages in the same space? Where does the content contradict itself? This creates a useful first filter that can benefit documentation efforts early in the process.
In a support context, the first assessment of a request often determines how quickly it gets handled. A Forge app can read incoming JSM requests, categorise them, and attach an initial assessment – before a human agent has even opened the ticket. Which department is affected? Does this look like a known error class? How urgent does the request sound? This reduces manual triage work and speeds up handling, without replacing the human decision.
The Forge LLMs API is a technical development – but its relevance goes beyond the engineering layer. Depending on your perspective, different questions arise.
Anyone building or planning Forge apps previously faced a clear trade-off: AI features were possible, but they required external infrastructure. That meant higher complexity, additional cost, and the loss of the Runs on Atlassian badge. The Forge LLMs API has shifted that equation. AI-powered functionality can now be built as a native part of a Forge app, without your own model infrastructure and without binding yourself to a separate provider.
For development teams, AI integration is no longer a compromise – it’s a concrete differentiator. Apps that incorporate AI meaningfully while still meeting the requirements of compliance-sensitive customers will stand out from basic feature extensions.
The central administrative questions here are: “Where does our data live? Who has access to it?” The Forge LLMs API gives a clear answer: data stays within the Atlassian platform, there is no separate vendor agreement, and no additional data protection impact assessment is needed for an external AI system.
For organisations already using Atlassian Cloud products and having completed the relevant compliance reviews, this means AI functionality in custom-built apps operates within the same regulatory framework as the rest of the platform. That’s a practical advantage.
One operational detail worth planning for: adding the Forge LLMs API to an existing app triggers a major version upgrade, which requires explicit administrator approval before the updated app can go live. Teams rolling out AI features to existing apps should factor this approval step into their release planning.
The Forge LLMs API is a meaningful step – but it should be assessed with clear eyes. First, on status: the API is in preview. Its scope, behaviour, and terms may still change. A team building an app based on the current state should treat this as an investment in early experience, not as a stable foundation for a critical production application.
On model choice: the situation is currently limited. Only Claude models are available. Teams that prefer other models for technical or organisational reasons will still need external integrations. Atlassian is exploring which additional models might be included in future, but has made no concrete commitments.
On modality: the API currently supports text input and output only. Multimodal capabilities – such as processing images or file attachments – are not yet available and may be added in a later release. Use cases that involve screenshots, diagrams, or binary content are out of scope for now.
There are also the platform-level constraints inherent to Forge: execution timeouts, quota limits, and the general dependency on Atlassian’s infrastructure all apply to LLM calls as well. Anyone planning complex, long-running AI workflows needs to factor in these structural limits of the Forge platform.
And finally: the API doesn’t replace an AI strategy. As with any tool, its value depends on whether the use case is well-defined. A Forge app that calls a language model without a clear problem to solve will not deliver value. The technical barrier is now lower – but the need for solid conceptual work remains.
The Forge LLMs API marks a point where two developments converge: Atlassian’s continued build-out of AI capabilities at the platform level, and the growing expectation that custom-built apps should be able to draw on those same capabilities.
For teams developing Forge apps – whether in-house or with a partner – this is a concrete reason to stop treating AI as a separate topic. The infrastructure is in place, the data protection framework is clear, the technical barrier has dropped.
What’s needed now is well-defined use cases and the willingness to build early experience before the API leaves preview – and before the competition to ship good solutions intensifies.
Does your team want to explore the Forge LLMs API or integrate AI capabilities into a custom Forge app? Our experienced Atlassian development teams support you with architecture, implementation, and certification. Get in touch via email or simply schedule an initial remote meeting with us.