by Community Champions Dave Rosenlund and Cidoni Brind
Atlassian would like you to build.
Its own tools make the point: Forge for developers, Rovo for agents, and Rovo Studio, which now promises a custom Forge app from a single prompt, no code required. The barrier to creating custom extensions for your Atlassian Cloud platform has never been lower, and the invitation is aimed squarely at customers.
The Forge LLMs API is now what Atlassian calls “generally available,” which likely means it’s started to roll out gradually. You can now call hosted Claude models from inside a Forge app, without standing up your own model infrastructure and without your application’s data leaving the Atlassian platform. For a customer who wanted to add intelligence to an internal tool, that used to mean wiring in an outside model and defending the data path.
Now it is a few lines of code.
So, more customers are about to become builders of internal AI software. Whether they notice it or not, they are taking on the responsibilities that come with it.
Start with what Forge LLMs genuinely fixes, because it is real.
Standing up model infrastructure is work most teams should never have had to do, and Forge LLMs removes it. The request runs inside the Atlassian platform, and your application’s data does not leave it for a third-party AI service. For a whole class of internal projects, that clears the objection that used to end the conversation in security review: where does our data go.
Be precise about the size of that win. It reduces one common data-egress objection. It does not make your application pre-approved. Authorization, data access, prompt construction, output handling, auditability, and misuse prevention are all still reviewed, because those live in the app you wrote, not in the platform underneath it. The infrastructure got easier to clear. The application did not.
That distinction is important.
When building anything with AI was much harder, “can we build this” often resulted in the end of the conversation. It filtered out most ideas before they could even get to a POC.
Forge LLMs removes that filter. The prototype comes together in an afternoon, which is exactly why the interesting question is no longer whether you can build it. It is whether you want to own and operate it as software.
For many internal AI applications, the prototype is the easy part. What follows is the part that lasts. Someone has to write down how it works, answer for it when it breaks, keep it current as your data and your instance change, and support the people who come to rely on it. None of that shows up in the demo, and none of it ends.
Here is the part that surprises people, because it runs against how the rest of Forge works.
Most of the Forge platform comes with a generous free tier. The Forge LLMs API does not. There is no free monthly token allowance, and every request is billed to the developer of the app. When you are the customer building for your own organization, that developer is you. The cost does not wait for scale or success. It starts with the first production call and grows with every call after.
That changes what a popular internal tool means. Adoption you would normally celebrate is now a line on your own Atlassian bill.
Forge does give you real visibility into that spend. You get usage and token reporting, a cost estimator, and platform metrics. Useful, and necessary.
But visibility is not governance. The dashboard tells you what your application consumed. It does not decide who should have access, how often a user can invoke the feature, what counts as abuse, what budget is acceptable, when to throttle, or who signs off on the exception. Atlassian is direct about this: early adopters will need to build user, tenant, or edition-based limits into their own apps. Those are not settings you toggle. They are decisions you design, and they are yours.
Your application depends on a specific model, and models are not fixed points.
Each has its own status and retirement date. Atlassian's own guidance is to watch those dates and update your app before a model reaches end of life. When a model is retired, that can mean migration work, on your schedule or on theirs. You built a tool in an afternoon and signed up to maintain its dependency on a moving target for as long as it runs. That maintenance is more than a version bump. A new model can change how your app behaves, so you also own the evaluation of it, validating output quality, watching for regressions, and confirming acceptable behavior as models, prompts, and your own data change.
Enabling an LLM capability in the first place carries its own governance and permission decisions, and that is a separate matter from routine version maintenance. It is worth not confusing the two. What they have in common is that both land on you.
None of this is unique to Forge. It is what consuming any managed model service involves, whether the model is hosted by Atlassian, AWS Bedrock, OpenAI, or anyone else, and it is what owning software has always involved. The novelty is how little effort it now takes to acquire the obligation.
It is worth measuring all of this against Atlassian’s own words. This week CEO Mike Cannon-Brookes described open, governed AI as visibility into how agents operate, boundaries on what they can access, and a choice of models and providers, and he tied it to two moves. Atlassian joined NVIDIA’s Open Secure AI Alliance, an industry effort to build shared tools for securing AI agents, covering identity, permissions, guardrails, and logs. And it signed a letter backing open-weight models, the kind you can inspect, modify, and run yourself.
Read the first as a customer-builder and it is oddly clarifying. The controls that alliance exists to standardize are the same ones you will be hand-building into your own Forge app, because the platform does not hand them to you yet. Atlassian is helping define, at the industry level, the governance scaffolding it has not built into the thing you build with. That is less a criticism than a map. It marks which parts are your job now, and which may later arrive as shared tooling you can adopt instead of reinvent.
Read the second and the gap is sharper. Atlassian is advocating for a world of open, inspectable, choosable models while the tool it hands you runs models from a single provider, Anthropic’s Claude, closed-weight and absent from both coalitions Atlassian just joined. The choice of models and providers the CEO calls essential already exists in Atlassian’s own AI, where Rovo reaches across several providers. It is not yet in Forge LLMs, though the company says more models are being explored.
The two point the same way. Both describe where Atlassian says governed, open AI is going, and neither is what you get in the tool today, where you supply the governance and Atlassian supplies models from a single provider. The move is not to wait for that future but to build for it: keep the model call and the guardrails modular, so what you hand-roll now, and the single provider you are limited to today, can be swapped for the standards and choices that are, by Atlassian’s own account, coming.
This is not a case against building. Some of the best things a team does on Atlassian are the tools it builds for itself.
It is a case for building deliberately. The applications worth owning tend to share a shape. They use knowledge specific to your organization. They serve a workflow that matters and that lives naturally inside Atlassian. They have a named owner, a budget for what they consume, and a plan for keeping them alive. The ones that go wrong share a different shape. They duplicate something a packaged feature already does. They have no owner once the prototype earns its applause. They run on unbounded access and no cost ceiling, with no plan for the day the model retires.
How heavy that ownership feels depends on who you are. A large enterprise with a platform team, a consumption budget, and a governance function can absorb it, and may find Forge LLMs the cleanest way to give those teams a safe place to build. A smaller company gets the same easy build and a harder version of everything after it, with fewer people to carry the bill, the limits, the maintenance, and the lifecycle. The invitation is identical. The capacity to own what it produces is not.
And whatever you build, its ceiling is the context you can give it. A model reasoning over thin or stale information returns answers that are fluent, confident, and wrong. Model capability matters, but it is no longer the scarce part. What stays scarce is the operational knowledge your organization mostly never wrote down, the Unwritten Layer, and Forge LLMs does nothing to supply it.
Forge LLMs is a meaningful improvement. It reduces infrastructure effort, simplifies access to hosted models, and keeps processing inside the Atlassian platform. Those are real, and they make more internal AI applications possible.
They do not remove ownership.
The moment you turn a prompt into a production Forge app, you inherit a software product: a usage bill, an authorization model, an operating policy, a model dependency, a support obligation, and a lifecycle.
That is not a reason to avoid building. It is a reason to build deliberately.
Forge LLMs doesn't turn customers into AI companies. It turns them into software owners. And software ownership lasts far longer than a successful demo.
So, the question is no longer whether Forge makes an AI application easy to create. It is whether the application is worth owning.
This article is part of an ongoing article series exploring responsible AI adoption.
See also...
Dave Rosenlund and Cidoni Brind are Atlassian Community Champions. In their day jobs, they both work for Trundl, an Atlassian Platinum Enterprise Solution Partner.
Dave Rosenlund _Trundl_
2 comments