Field notes from the Atlassian trenches.

A front door is a promise. It says something worth entering is on the other side. The fastest way to break that promise is to swing the door open and reveal one enormous room with every document your company has ever produced piled in the middle of the floor.

In Part 1 of this series, we put up the front door: Company Hub, and why an intranet built into Confluence beats the beautiful-but-abandoned kind. Today we walk through it. This is the part where a Confluence intranet becomes rooms people can navigate instead of rubble they give up on — the structure, the content, and the one thing that quietly decides whether any of it gets used.

Spaces are your rooms

Confluence's organizing unit is the space, and the simplest, most durable structure is one space per team or department. Think of each as a room. It has its own customizable homepage — put the team's goals, the links they reach for, and the people who work there front and center — and its own blog for news, wins, and the human stuff that builds culture. Upload your logo and Confluence's look-and-feel shifts to match, a small touch that makes the place feel like yours and quietly helps adoption.

The discipline is resisting two temptations. Don't spin up forty spaces on day one just because your org chart has forty boxes; you'll get sprawl nobody can navigate. And don't cram everything into three mega-spaces either. Mirror how people actually work and where they actually look, then let the structure grow as real need appears. A good intranet has rooms. It doesn't have a hoarder's garage.

Don't move everything — link it

Here's the mistake I watch teams make the moment they decide to "build an intranet": they treat it as a migration project and try to drag every existing document into a new home. Months of copying later, half of it is stale the day it lands. You don't have to work that way. Confluence lets you drop Smart Links straight into the page tree, so a resource that lives somewhere else still shows up where people look for it — without being duplicated. You can embed and edit content from the other tools your teams already use, too: design files, spreadsheets, code repositories. The intranet becomes a hub that points to where things truly live, not a landfill you pour copies into. Less migration, less staleness, more signal.

Make the rooms worth visiting

A room with four blank walls doesn't get used, and neither does a wall-of-text wiki page. This is where Confluence's richer palette earns its keep, because whiteboards, databases, and video all live directly inside a page. A few intranet uses that pull their weight:

• Databases turn a static page into something structured and filterable: a real employee directory, a tools-and-access registry, a policy index, or a "who owns what" table your whole company can search instead of guess at.
• Whiteboards let planning and brainstorms live where the context is — embedded in the page rather than screenshotted into it after the fact.
• Video (and Loom is part of the family now) means a two-minute "welcome from the founder" or a quick how-to sits right on the page, warmer and clearer than a paragraph trying to do the same job.

One newer addition worth knowing: Remix, in open beta as of early 2026, takes a dense section — a data table, a long process description — and turns it into a chart, an infographic, or a timeline. Pages with visuals get read more often, so it's a small feature with an outsized effect on whether anyone actually absorbs what you published.

The part that decides everything: can people find it?

I'll be honest, because that's the job: you can build the tidiest set of rooms in the world and the intranet still fails if people can't find what's inside them. Structure is necessary; it isn't sufficient. What tips a Confluence intranet from "filing cabinet" to "genuinely useful" is that you can ask it. Rovo — now included in every paid Confluence Cloud plan — brings AI-powered search across Confluence, Jira, and connected tools like Slack and Google Drive, and it's permission-aware, so people only ever see what they already have access to. Ask "What's our parental leave policy?" in plain language and you get the answer from your own space, not a list of thirty maybe-relevant pages. Knowledge cards define your company's own acronyms; people cards show who owns what. The gap between an intranet people browse and one they ask is the gap between one they tolerate and one they rely on.

The Avaratak Take

Build in this order: rooms first, then furnishings, then findability. Spaces that mirror how your teams actually work, existing content linked rather than laboriously migrated, pages made worth visiting with databases and video and the occasional Remix, and search sitting at the center of all of it. The trap is doing it backwards — pouring in content before there's a structure to hold it, or standing up spaces faster than anyone can maintain them.

The honest test of a finished intranet isn't how it looks in the launch email. It's whether, six weeks later, finding something is faster than asking a colleague. When that's true, the intranet stops being a place people are told to use and becomes the place they choose to start. That's the outcome we design for — the boring, compounding kind that's still paying off long after the launch confetti is swept up.

In Part 3, the finale: keeping it alive. Permissions that protect the right things without strangling the useful ones, content that gets reviewed and retired instead of quietly rotting, the analytics that tell you what's working, and the handful of moves that get people through the door in the first place.

If you'd rather not draw the floor plan alone, that's our job. As an Atlassian Solution Partner, Avaratak helps teams turn Confluence from a room full of rubble into an intranet with rooms worth entering. Come find us at avaratak.com.

Try this before you finish your coffee: ask five colleagues to open the company intranet right now, from memory, no searching. Count how many actually can. The pause you're imagining is the entire problem — and no amount of redesigning the homepage carousel is going to fix it.

Here's the uncomfortable truth I've watched play out at company after company. Most intranets aren't broken. They're abandoned. Someone spent a quarter building a polished landing page with a rotating banner and a "Message from Leadership," everyone dutifully clicked through it during onboarding, and then it quietly became the digital version of the supply closet — full of useful things, visited only when something has already gone wrong.

This is the first post in a three-part series on using Confluence as your intranet. Before we get into spaces, databases, and the mechanics of building the thing (that's Part 2) or keeping it alive once it's built (Part 3), I want to start somewhere less glamorous and more important: why the old intranet died, and the one thing Confluence quietly gets right.

Why your last intranet flatlined

Traditional intranets fail for a reason that has nothing to do with how they look. They fail because they're a separate place. The work happens in one set of tools, and the "information" lives somewhere else entirely — a destination you have to remember to visit, maintained by a team that owns it in name only. Content goes stale because updating it means leaving the tools you actually use. Nobody can find anything because search was an afterthought. So the bookmark withers, and people just ask in chat instead.

Meanwhile, the cost of all that hunting is real. McKinsey has put the share of the workweek that knowledge workers spend simply searching for and gathering information at close to a fifth. That's a full day a week, per person, lost to "where is that document?" An intranet is supposed to be the answer to that question. Most of them are just another place to look.

The thing Confluence gets right

Confluence starts from a different premise, and it's a deceptively powerful one: your teams already live here. The meeting notes, the project specs, the runbooks, the decision logs — for a lot of organizations, that's already in Confluence. So an intranet built on Confluence isn't a new destination bolted onto the side of your work. It sits directly on top of the source of truth your teams are already creating every day.

That single shift changes the maintenance math. Content stays fresh because the people who own it are already in the tool. The HR space that holds your policies is the same place HR works. The engineering runbook your intranet links to is the live one — not a copy someone forgot to update in 2023. You're not maintaining a separate showroom. You're putting a front door on the house everyone already lives in.

Company Hub: the front door, built in

That front door has a name: Company Hub. It's a customizable, company-wide landing page available on Confluence Cloud's Premium and Enterprise plans, and the reason I like it as a starting point is that it asks almost nothing of you. It's built directly into Confluence — no add-ons, no Marketplace apps, no advanced configuration. App and site admins set it up (and can delegate editing to people across departments, so HR, IT, and Comms each curate their own corner), and most teams can stand up a genuinely useful version in a day or less.

You get a top links menu for the evergreen stuff people reach for constantly — payroll, PTO requests, the org chart, the brand kit, the on-call rotation. You get spotlight modules for the messages that actually matter this week, cards and carousels for grouping related resources, and your own name, logo, and colors so it feels like your company rather than a generic template. Worth noting for the admins reading this: Company Hub now lives inside Rovo Studio, alongside automations and assets, which is where Atlassian has been consolidating the platform's building blocks.

A little honesty before you get excited

Because we don't do hype around here, two caveats. First, Company Hub specifically is a Premium-and-up feature — but using Confluence as an intranet isn't gated behind that. Even on Standard, you can build a perfectly serviceable intranet out of spaces, customizable homepages, and space blogs (more on that in Part 2). The Hub is the polished front door; the house works without it.

Second, set your expectations honestly. Out of the box, Company Hub is a clean, functional entry point — not a pixel-perfect, multi-brand, fully personalized portal. If your comms team's north star is a heavily designed, marketing-grade experience, you may eventually want a Marketplace app layered on top. But here's what I tell clients: the goal of an intranet was never to be a museum. It's to be the place people actually start their day and actually find what they need. On that score, "built into the tool you already use" beats "beautiful but abandoned" every single time.

The Avaratak Take

An intranet doesn't earn its keep by looking impressive in a launch announcement. It earns its keep on a random Tuesday, when a new hire needs the expense policy and finds it in eight seconds instead of firing off a chat message and waiting twenty minutes. The reason we steer clients toward Confluence here isn't that it has the flashiest homepage builder — it's that it removes the fatal flaw of the old model. When your intranet and your work live in the same place, "keeping it current" stops being a heroic act of will and becomes a side effect of doing the job.

Start with the front door. Point Company Hub at the five things your people need most, and resist the urge to boil the ocean. The architecture underneath — the spaces, the databases, the search that makes it all findable — is where the real leverage hides, and that's exactly where we're headed next.

In Part 2, we'll build out the rooms behind that front door: how to structure spaces so your intranet scales instead of sprawls, how to bring in content you've already got without a painful migration, and how Rovo turns the whole thing into an intranet you can simply ask.

If you'd rather not draw up the blueprint alone, that's literally our job. As an Atlassian Solution Partner, Avaratak helps teams turn Confluence from a document graveyard into the place work actually starts. Come say hello at avaratak.com.

Picture a Monday-morning access request landing in your queue: "Hi — can you give me access to the Marketing space?" Simple enough, until you realize you've become a detective. Is that the Jira space where the marketing team tracks campaigns, or the Confluence space where they keep their brand guidelines? They might have nearly identical names. They might have exactly identical names. Welcome to the one genuinely tricky consequence of everything we've covered — and the subject of our finale.

This is part three of our series on Jira spaces. We started with the rename and creating your first space, then moved on to templates and reuse. Today we get to the grown-up stuff: who's allowed to create spaces, how to keep a sprawling estate navigable, and how to stop the word "space" from turning every request into a guessing game.

Who gets to create a space?

Governance starts at creation, and Jira gives you two levers. Creating a company-managed space requires the Administer Jira global permission — deliberately a high bar, because these spaces carry shared schemes that affect everyone. Creating a team-managed space is governed by its own "Create team-managed spaces" global permission, which by default is granted broadly, so most users can spin one up on their own.

That default is a choice you should make consciously rather than inherit by accident. Wide-open team-managed creation is wonderful for autonomy and challenging for anyone trying to keep a tidy estate; locking it down protects consistency but routes everything back through admins. There's no universally correct setting — only the one that matches how much sprawl your organization can tolerate. Worth knowing, too: a space admin (someone with the space-scoped Administer Spaces permission) is not the same as a Jira admin. You can hand someone the keys to their space without handing them the keys to the building — and you usually should.

Space categories: a map for the estate

Once you have more than a handful of spaces, you need a way to see across them. That's what space categories are for: group related spaces together and your teams can view work across all of them in one place — every space belonging to a department, a portfolio, or a business unit, surfaced together instead of scattered. It's the difference between a filing cabinet and a pile.

One governance note: changing a space's category requires the Administer Jira global permission, so categorization stays an admin-controlled decision rather than something that quietly drifts. Use that to your advantage — a deliberate category structure, maintained centrally, is one of the cheapest ways to keep a large Jira estate legible as it grows.

The two-spaces problem (and how to survive it)

Here's the headache the rename created, and there's no point pretending otherwise: Confluence has always had spaces, and now Jira does too. Both can carry similar — or identical — names, which means "the Marketing space" is suddenly ambiguous in a way it never was when Jira had "projects" and Confluence had "spaces." Atlassian has acknowledged this directly and said it's working on ways to make the distinction clearer in the experience. That's reassuring, but you don't have to wait for it.

The practical defense is a naming convention, and it's worth agreeing on one as a team. Make the tool obvious in the name, or use a consistent prefix, so a Jira delivery space and a Confluence knowledge space never collide in conversation or in a search bar. Encourage people to name the tool in access requests — "the Jira Marketing space," not just "Marketing." Small habits, but they quietly eliminate a whole category of daily confusion before it starts.

Spaces vs. Atlassian Projects: the other lookalike

There's a third "project-shaped" thing in the mix, and we promised back in part one we'd return to it. A Jira space is your execution layer — the container where work items live and teams get things done. Atlassian Projects, which live in Atlassian Home, are something else entirely: a high-level, cross-tool view of an initiative, complete with goals, timelines, stakeholders, and status updates. One is where the work happens; the other is how you tell the story of that work to everyone who needs the big picture.

Getting this distinction into your teams' heads is genuinely useful. When someone says "project," it's now fair to ask which kind they mean — and once everyone shares the mental model of space for execution, Atlassian Project for oversight, a whole class of cross-purposes conversations simply stops happening.

What about JQL, APIs, and Data Center?

For the technically minded, the governance news is mostly reassuring. JQL still accepts "project" as a term, with a "space" alias on the way, and your APIs, Forge apps, and automation rules are unaffected — so the message to your automation-heavy teams is "nothing to rewrite today." The work that does need doing is human-facing: update your documentation, runbooks, and training so your language matches the interface, rather than leaving new hires to reconcile a tool that says "space" with a wiki that says "project." And if you run a hybrid estate, keep one fact in view — this change is Cloud-only, with no plans for Jira Data Center, so your self-hosted instances will keep saying "project." Your trainers and documentation should account for both dialects.

The Avaratak Take

Here's the throughline of the whole series. Technically, renaming projects to spaces is about as low-risk as a platform change gets — nothing breaks, nothing needs rebuilding. Linguistically and operationally, though, it's an invitation to get your house in order. The organizations that handle it well do four unglamorous things: they decide deliberately who can create spaces, they use categories to keep the estate navigable, they adopt a naming convention that keeps Jira and Confluence spaces distinct, and they teach their teams the difference between a space and an Atlassian Project. None of that requires new software. All of it prevents a thousand small confusions.

A rename, in other words, is the cheapest governance prompt you'll ever get. The clarity is free if you reach for it — and genuinely expensive in wasted time if you don't. That's the work we love most: not the click-by-click configuration, but the naming conventions, permission models, and shared mental models that decide whether a Jira estate stays legible at scale or slowly becomes a place where nobody's quite sure which "space" anyone means.

That wraps our three-part tour of Jira spaces — from what changed and how to create one, through templates and reuse, to governing it all today. If you'd like a second set of eyes on your space governance — creation permissions, categories, naming, the works — that's exactly what we do as an Atlassian Solution Partner at Avaratak Consulting. Find us at avaratak.com. We'll help you keep every space straight.

I once watched an admin build the same Jira project four times in one week. Same workflow, same fields, same permission scheme, same three boards — typed out by hand each time, like a scribe copying a manuscript by candlelight. By Thursday he had a fifth request in the queue and the faintly haunted expression of a man who has glimpsed his own future. There's a better way, and it's been sitting in the Create dialog the whole time.

Welcome back. In part one we untangled the projects-to-spaces rename and stood up a first space. Today is the part that actually buys back your time: how to stop building every space from scratch. Templates, shared configuration, and a custom-template trick that quietly turns space creation from a bottleneck into a self-serve system.

Templates: your running start

Every time you create a space, Jira hands you a library of templates, organized two ways: by use case and by app. The use-case view groups them around what a team is trying to do — Scrum and Kanban for software teams, simple task tracking for lightweight work, and ready-made starting points for business teams in marketing, HR, and legal. The app view groups them by product, so if you run Jira Service Management you'll find IT service desk and customer service desk templates waiting there.

One detail that matters: the templates you see depend on the Jira apps you're subscribed to. No Jira Service Management subscription, no service desk templates. And here's a small gotcha worth knowing before you click — if you pick a template tied to an app you don't currently have access to, Jira shows a checkbox offering to grant yourself access. Tick it and you're added to that app's default group, which means you now count as a licensed user of it. Handy when you meant to do that; an unwelcome surprise on the invoice when you didn't. Read the checkbox.

Shared configuration: borrow from a space you already trust

Templates are a great starting point, but they're generic. The real time-saver is shared configuration — creating a new space that inherits its setup from an existing one. As you create the space, you can choose to share settings with a space you've already built, pulling in its permissions, workflows, work types, and other schemes rather than reconstructing them click by click.

This is the move for organizations that want every team's space to look and behave the same way. Build one space properly — the permission scheme your security team signed off on, the workflow your auditors like, the fields your reporting depends on — and every space spun up from it starts life already compliant. Consistency stops being something you enforce after the fact and becomes something you get for free at creation.

Custom templates: turn your best space into a blueprint

Here's the trick I wish more teams knew about. Once you've built a space that genuinely works — the one other teams keep asking to copy — you can save it as a reusable template. From that space, head to Space settings → Details, open More actions, and choose Save as space template. Give it a clear name and a description so teams know when and why to reach for it, and it joins the template gallery alongside Atlassian's built-in options.

That's how you bottle institutional knowledge. Your "golden" software space, your standard service desk, your marketing-intake setup — each becomes a one-click starting point instead of a tribal recipe only one admin remembers. And because the template carries the configuration, the next team doesn't just get a similar-looking space; they get the actual, considered setup you worked out the hard way.

Self-serve, but governed

The piece that makes this genuinely scalable arrived for Enterprise customers earlier this year: admins can now choose exactly who is allowed to create spaces from a given custom template. Open the template, select who can create new spaces from it, and grant access to specific users or groups. Now your teams can self-serve a perfectly configured space without filing a ticket — and without the free-for-all that usually makes admins nervous about self-service in the first place.

One important boundary to keep straight: that access controls space creation only. It decides who can spin up a space from the template; it does not set the permissions inside the resulting spaces. Those you still configure separately, per space. Conflating the two is a classic way to accidentally hand out more access than you intended, so keep the line bright in your head.

A note on the two space types

All of this interacts with the company-managed versus team-managed choice we met in part one. Company-managed spaces are where shared schemes live, so they're the natural home for the "build once, reuse everywhere" pattern when central consistency is the goal. Team-managed spaces travel with their own self-contained configuration, which is exactly what makes them fast and autonomous — and worth templating too, so even your independent teams start from a sensible baseline rather than a blank slate. And if you're arriving from another tool entirely, remember you can import a space and its work items during creation, so a migration doesn't mean rebuilding history by hand.

The Avaratak Take

Treat templates as products, not afterthoughts. The teams who win here pick their two or three most-requested space types, build a deliberately excellent version of each, save them as named custom templates, and write a one-line description so the right people reach for the right blueprint. Then they decide — on purpose — who's allowed to self-serve which template. That combination is the whole game: consistency without bottlenecks, autonomy without anarchy.

The number to watch is how many one-off "can you set up a space for us" tickets land in your admins' queue each month. Done well, that number falls toward zero, your admins get their Thursdays back, and the spaces that do get created are more consistent than the hand-built ones ever were. That's the rare improvement that makes both the governance crowd and the move-fast crowd happy at once.

In part three, we close the series with the grown-up stuff: who's allowed to create what, how space categories give you visibility across a sprawling estate, and how to keep Jira spaces, Confluence spaces, and Atlassian Projects from turning every access request into a guessing game.

If you'd like help designing a set of golden space templates your teams will actually use — and a governance model that decides who gets to use them — that's squarely the work we do as an Atlassian Solution Partner at Avaratak Consulting. Find us at avaratak.com.

Last autumn, a client messaged me in a quiet panic. "Abe — somebody moved my projects. The menu says Spaces now. Did we lose something? Did I break something?" I've since fielded a dozen versions of that exact message, and the answer never changes: nothing's broken, nothing's lost, and no, it wasn't you. Atlassian simply renamed one of the most fundamental ideas in Jira — and the change has been quietly rolling across every Cloud site on the planet.

If you've logged into Jira lately and done a double-take at the navigation, this one's for you. Welcome to part one of a three-part series on creating and managing spaces in Jira. We'll start where the confusion starts: what actually changed, why it's more than a find-and-replace, and how to stand up your very first space without second-guessing every click.

So what happened to "projects"?

Here's the headline, minus the drama: Jira "projects" are now called "spaces." That's the whole change. It applies across every Jira Cloud product — Jira, Jira Service Management, and Jira Product Discovery — and Atlassian has been refreshingly blunt that this is purely a terminology shift. The functionality, behavior, and scope of those containers are identical to what they were. Your boards, workflows, automation rules, and saved filters all work exactly as before. Projects got a new name. Everything else stayed put.

The rollout is already behind us, too. Atlassian started with Free and Standard plans in September 2025, moved Premium and Enterprise in October, and wrapped up the stragglers — including the slower, stability-first release tracks — by early December. By the time you're reading this, "spaces" is simply the language of Jira Cloud. One note for the on-premise crowd: Atlassian has said it has no plans to bring this change to Jira Data Center, so if you're self-hosted, your projects are staying projects.

Why rename something this central?

This is the part I think deserves more credit than the eye-rolls it earned in a few corners of the community. The word "project" carries baggage. Ask ten people what a project is and most will describe something with a start date, an end date, a defined scope, and a tidy finish line. But that's almost never how a Jira container behaves. A support queue doesn't "finish." A marketing team's space runs for years. A product backlog is gloriously, permanently open-ended.

Moving to "space" matches the word to the reality: these are flexible, ongoing hubs for organizing work, not time-boxed initiatives. It also lines Jira up with Confluence, where "spaces" have always been a team's home base, and it reinforces the broader Teamwork Collection vision — Jira, Confluence, Loom, and Rovo speaking one shared vocabulary instead of four dialects.

There's one more reason, and it's a clever one. Atlassian also introduced Atlassian Projects — a genuinely separate feature that lives in Atlassian Home and gives leaders a high-level view of work across tools, complete with goals, timelines, stakeholders, and status updates. If Jira had kept calling its containers "projects," you'd have "Jira projects" and "Atlassian Projects" meaning two completely different things in the same breath. Renaming the Jira container to "space" untangles that knot: spaces are where work gets done, and Atlassian Projects are how you narrate that work across the organization. We'll come back to this in part three, because it trips people up constantly.

Creating your first space

Enough backstory — let's build something. Creating a space uses the same muscle memory as creating a project did, just with updated labels. From the side navigation, hover over Spaces and select Create space (you can also reach it via Settings → Spaces → Create space). From there:

• Pick a template. Templates are grouped by use case and by app. Scrum and Kanban for software teams, IT and customer service desk templates if you run Jira Service Management, and ready-made starting points for business teams in marketing, HR, and legal. The templates you see depend on the Jira apps you're subscribed to.
• Choose company-managed or team-managed. This is the single most consequential decision in the whole flow, and it's worth slowing down for — more on it below.
• Name it. Give the space a clear name and key. Future you, and every teammate searching for it later, will thank you for a naming convention that actually means something.
• Create. That's it. Your space is live and ready for work items.

A couple of conveniences worth knowing: you can create a space that shares its configuration with an existing one — borrowing its permissions, workflows, and schemes rather than rebuilding from scratch — and you can import a space and its work items from another tool if you're migrating in. We'll spend all of part two on exactly this, because reuse is where space creation stops being a chore.

Company-managed vs. team-managed: the fork in the road

Jira gives you two flavors of space, and the difference comes down to who holds the keys. Company-managed spaces are configured by Jira admins using shared schemes for permissions, workflows, and fields. They're the right call when you need consistency and governance across many teams — standardized processes that have to look the same everywhere. Creating one requires the Administer Jira global permission.

Team-managed spaces hand control to the team that owns them. Whoever creates the space becomes its administrator and configures it themselves, no central admin ticket required. They're ideal for autonomous teams that want to move quickly. By default, any user can spin up a team-managed space, though admins can gate that behind the "Create team-managed spaces" global permission.

Neither is "better." The honest answer — the one we give every client — is that the right choice depends on your appetite for autonomy versus standardization, and the two can absolutely coexist in the same Jira site. We'll dig into how to choose well in part two.

"But what about my JQL and automation?"

This is the question that keeps admins up at night, so let me put it to bed. Your existing JQL clauses, saved filters, automation rules, REST APIs, and Forge apps all keep working. Behind the scenes, "project" still functions as a term in JQL for backward compatibility, and Atlassian has said it will add a "space" alias over time. In plain English: you don't need to rewrite anything to keep working today. Years of custom logic didn't evaporate overnight — which is exactly how a terminology change ought to be handled.

The Avaratak Take

It's tempting to file this under "much ado about a noun" and move on. I'd push back, gently. Words shape behavior. For years, the term "project" quietly told non-technical teams that Jira wasn't really for them — it was for engineers running time-boxed deliverables. "Space" sends a more inclusive signal: this is a home for your team's work, whatever shape that work takes. That's not marketing gloss; it's the kind of small language shift that lowers the barrier to adoption for the marketing, HR, legal, and operations teams who were always welcome but never quite felt invited.

So here's our advice: don't treat the rename as a cosmetic nuisance to grumble through — treat it as a prompt. Update your internal documentation and training so your language matches the tool. Use the moment to revisit whether your space naming conventions still make sense. And start drawing the line in your own head between a Jira space (execution) and an Atlassian Project (oversight), because getting that mental model right now will spare you a lot of confused Slack threads later. A rename is cheap. The clarity it unlocks, if you lean into it, is not.

Next up in part two: how to stop building every space from scratch — templates, shared configuration, and the custom-template trick that turns space creation from a bottleneck into a self-serve system.

Wrestling with how to structure your spaces, or whether company-managed or team-managed is right for your teams? That's the kind of thing we untangle every day as an Atlassian Solution Partner at Avaratak Consulting. Find us at avaratak.com — we'll help you make the call with your best interests first.

Ask a developer what fraction of their day goes to actually writing code, and then watch their face do something complicated. Atlassian's own research puts a number on the grimace: roughly 84% of a development team's day is spent on everything around the code — tickets, reviews, context hunting, status archaeology, the connective tissue of software work. The code was never the bottleneck. The loop around it was.

Welcome to the finale of Rovo Week. Across five workdays we've opened five doors: Search finds anything, Chat explains anything, the ready-made agents handle the routine, and Studio builds the specialist. Today, the fifth door: Rovo Dev, Atlassian's AI agent for the software loop itself — and then the sequence that ties the whole week together.

An agent that works the loop, not just the editor

The market is not short of tools that autocomplete code. Rovo Dev's distinction is its address: it lives in the loop between Jira, your codebase, and Bitbucket, which means the context travels with the work. In practice:

• Assign a Jira work item to Rovo Dev the way you'd assign it to a teammate, and get back a draft implementation as a pull request — linked to the ticket, waiting for human review. The why arrives attached to the what.
• First-pass code review. Diff summaries and flagged risks in Bitbucket before a human reviewer spends their attention. The reviewer reviews, instead of spelunking.
• Codebase Q&A. "Where is the rate limiter configured?" answered with pointers into the code, not a chat-thread séance with whoever wrote it in 2022.
• The toil tier. Tests, docs, commit messages, and release notes drafted from the actual work items they describe.
• A CLI for the terminal-dwellers, because the best place to meet a developer is wherever they already are.
• Pipeline chores. Rovo Dev is the default agent provider in Bitbucket's Agentic Pipelines — the setup we covered when a flaky test learned to fix itself and open a draft PR for a human to merge.

Notice the pattern in every bullet: draft, then review. The human keeps the merge button. And notice the quiet advantage underneath: because Rovo Dev rides the Teamwork Graph, it starts informed — Atlassian's internal testing showed agents using that graph context produced 44% better answers on roughly half the tokens. Context isn't garnish here. It's the dish.

Measure, don't vibe

The trusted-advisor note for this one: pilot with a baseline. Atlassian's investment in DX — the developer-experience measurement platform — signals the grown-up question every engineering leader should be asking. Not "is the AI impressive?" but "did cycle time, review latency, and developer experience actually improve?" Pick one willing team, record the before, run the pilot, and count merged-versus-rejected agent PRs. Good numbers will fund the expansion; honest bad numbers will have cost you almost nothing to learn. Both outcomes beat vibes.

One engine, five doors

Here's the through-line of the week. Rovo isn't five features that happen to share a logo. It's one context engine — the Teamwork Graph, mapping how your people, work, decisions, and tools connect — with five doors into it. Search finds, Chat explains, the agents draft, Studio specializes, Dev ships. And each door pays off more because the others are open: Chat answers better because Search's connectors fed the graph; your Studio agent drafts better because the knowledge got tidied for Chat; Rovo Dev codes better because the Jira ticket carries the why. The compounding is the point.

The Avaratak Take: a sane sequence

1. Connectors and permissions first. Feed the graph; fence it properly. Unglamorous, and worth more than everything below it.
2. Search for everyone. Zero training required, trust earned daily.
3. Chat habits next. Citations clicked, knowledge hygiene exposed and fixed.
4. Two ready-made agents where mistakes are cheap, onboarded like new hires.
5. One custom agent in Studio, with a written job description and a named owner.
6. A Rovo Dev pilot with one willing team and a baseline metric.

Six steps. No oceans boiled, no big-bang rollout, and every step earns the trust the next one spends. That sequencing — and the honest conversation about which step your organization is actually ready for — is precisely the work we do as an Atlassian Solution Partner at Avaratak Consulting.

That's Rovo Week: five doors, one engine, and a path through all of it that respects both your people and your patience. If you'd like a guide for the walk, find us at avaratak.com. We'll hold the doors.

Here's a prediction you can hold me to: the most valuable AI agent in your company will not be built by IT. It will be built by the most annoyed person on your team — the one who has bounced the same malformed intake request back to its sender forty times this quarter and has, at long last, had enough. Annoyance, properly channeled, is a product requirements document.

Welcome to Part 4 of Rovo Week. So far we've opened three doors: Search (find anything), Chat (ask anything), and the ready-made agents (delegate the routine). Today is the door I get the most questions about: Rovo Studio, where you build the teammate nobody ships in a gallery — the one shaped exactly like your team's most persistent paper cut.

No-code, but not no-thought

Studio's promise is refreshingly plain: describe the agent's job in everyday language, scope its knowledge to specific Confluence spaces or Jira projects, give it the actions it's allowed to take, test it, and share it with the team. Templates get you a running start, and since Studio reached general availability with natural-language prompting as the on-ramp, Atlassian has reported a sevenfold jump in Studio-built workflows and agents. The distance between "someone should really automate this" and "I automated this before lunch" has gotten remarkably short.

Three extensions worth knowing before you build. First, automation: agents can be triggered by your existing Jira automation rules, which means they work without being asked — the request arrives, the agent acts. Second, for the developers in the room, Forge is the pro-code path for custom agents and deeper integrations when plain language stops being enough. Third, Atlassian's MCP support means agents from the wider ecosystem can tap your Teamwork Graph context too — a move with strategy implications big enough that we gave it its own post.

Four agents worth building first

• The intake bouncer. Reads every new request, labels it, routes it, and politely asks for whatever's missing before a human ever sees it. Your triage queue stops being a guessing game.
• The Definition-of-Done checker. Reviews stories against your actual DoD before they enter the sprint. The mid-sprint "wait, where are the acceptance criteria?" conversation, retired with honors.
• The Friday compiler. Drafts the weekly status update from real ticket movement — what shipped, what slipped, what's blocked — so the human adds judgment instead of reconstructing history from memory.
• The handbook concierge. Answers policy questions grounded only in your HR or team-handbook space. "Only" is the load-bearing word in that sentence; scoped agents are accurate agents.

Guardrails that keep it delightful

A few rules we install everywhere. Scope knowledge sources deliberately — an agent fed your three best spaces beats one gorging on your entire archive. Remember that permissions still apply, so an agent can never surface anything its user couldn't already open. Keep a human approval step on anything outbound or customer-facing. And give every agent a named owner, because agents without owners become haunted houses: still standing, faintly active, nobody remembers why, and everyone's slightly afraid to go inside.

The Avaratak Take

Write the job description before you open Studio. If you can't describe the job in five plain sentences — what it reads, what it produces, when it runs, what it must never do, and who reviews it — the agent can't do the job in any number of sentences. Then pick one workflow that is repetitive, text-heavy, and low-risk, and build for that alone. Measure minutes saved per week; a real number will fund your next three agents better than any demo ever could. The forty-minute build is genuinely the easy part. The discipline around it is the product.

Tomorrow we close the week with the door the engineers have been eyeing since Monday: Rovo Dev, the agent that works the software loop itself — plus the sensible sequence for adopting everything we've covered.

If your team has a paper cut that deserves an agent — and wants a guide to make sure it's built with the guardrails on — that's a workshop we love running as an Atlassian Solution Partner at Avaratak Consulting. Find us at avaratak.com. Bring your annoyances; we'll bring the job descriptions.

I onboarded a new teammate this month. Total ramp-up time: about ten minutes. No laptop request, no benefits enrollment, and — I've checked — not one cup of office coffee consumed. It drafts release notes, never misses a handoff, and takes feedback with a grace I can only describe as aspirational.

Welcome to Part 3 of Rovo Week — five workdays, five practical doors into Atlassian Rovo. We opened with Rovo Search (find anything) and followed with Rovo Chat (ask anything). Today we cross the most important line in the series: from AI that answers to AI that does. Meet Rovo Agents — specifically, the ready-made ones you can put to work this week without building a single thing.

The difference a job description makes

Chat is a brilliant generalist: ask it anything and it answers from your organization's knowledge. An agent is a specialist. It has a defined role, scoped knowledge, and a set of tasks it carries from start to finish — multiple steps, not one reply. Atlassian ships a growing gallery of pre-built agents, and the summoning ritual is delightfully familiar: invoke one from Chat, @mention it on a Jira work item or Confluence page the way you'd tag a colleague, or wire it into an automation rule so it picks up work without anyone asking at all.

A tour of the ready-made roster

• For engineering teams: agents that draft release notes from completed work items, suggest backlog cleanup, and flag stories missing acceptance criteria. The Friday-afternoon tier of work, handled before Friday.
• For service teams: the Rovo-powered virtual service agent in Jira Service Management answers from your knowledge base, gathers missing details conversationally, and resolves routine requests end to end — around the clock, queue-free. We went deep on this in our Service Collection coverage; the short version is that "tier 1" is steadily becoming a job description for software.
• For comms and marketing: a comms-crafting agent that turns a messy internal update into an audience-ready announcement in your tone — minus the four rounds of wordsmithing.
• For leadership and the PMO: decision summaries and project digests assembled from real work activity. The briefing you wish someone had written, written.
• For absolutely everyone: meeting notes turned into action items with owners, so the follow-ups actually survive contact with Friday.

If this sounds like early-adopter territory, the numbers disagree: Rovo is already in use at three-quarters of the Fortune 500, with millions of Rovo-assisted actions happening every month. The roster isn't a lab demo. It's on the field.

The honest part

Agents are spectacular at drafts, triage, and tedium. They are not your final judgment, and the well-designed ones don't pretend to be — output arrives as a draft for a human to review, and that isn't training wheels, that's the operating model. Treat agent output the way you'd treat a sharp new hire's first pass: frequently right, occasionally confidently wrong, always worth a read. The review step is where the value gets locked in, and skipping it is how good tools earn bad reputations.

The Avaratak Take

Onboard agents exactly like you onboard people. Give each one a clear job, in writing. Point it at your best pages, not all your pages — an agent grounded in your tidiest space will outperform one gorging on your archives. Review its first two weeks of output the way a good manager would. Then, and only then, loosen the leash. Start where mistakes are cheap: internal drafts long before anything customer-facing. And resist the urge to deploy six at once — two well-onboarded agents beat six neglected ones every single time. Pick the pair that erases your most hated recurring chore, and let the results fund the expansion.

Tomorrow, door number four: the agent you won't find in any gallery, because nobody has built it yet. We're going into Rovo Studio to roll our own.

If you'd like help choosing which agents to onboard first — and writing job descriptions they can actually live up to — that's the kind of practical AI adoption we guide every week as an Atlassian Solution Partner at Avaratak Consulting. Find us at avaratak.com. Our coffee consumption, I promise, remains entirely human.

Every organization has one. The person who somehow knows everything — which decision got made in which meeting, where the real spec lives, why the billing code does that strange thing on the last day of the month. They're a treasure. They're also a single point of failure with a calendar, and the week they go on vacation, your team's velocity quietly drops by a third while everyone waits for them to come back and answer questions.

Welcome to Part 2 of Rovo Week — five workdays, five practical doors into Atlassian Rovo. Yesterday was Rovo Search, the Ctrl+F for your entire company. Today we walk through the second door: Rovo Chat, which is what happens when that irreplaceable coworker becomes available to everyone, all the time, without ever needing a vacation.

What makes it different from every other chat window

The fair question first, because the world is not exactly short on AI chat boxes. What earns Rovo Chat a place in your workday is one word: context. A generic assistant has read the internet; Rovo Chat has read your organization. It's grounded in the Teamwork Graph — the same context layer behind yesterday's search results — which maps your Jira work items, Confluence pages, goals, and connected tools into one living web of who-did-what-and-why. Ask it a question and it answers from your company's actual knowledge, with citations you can click, and with your existing permissions fully respected. You cannot chat your way into anything you couldn't already open.

Five conversations worth having this week

• The post-vacation debrief. "What changed on Project Falcon while I was out?" Instead of excavating two hundred notifications, you get a summary of decisions, status changes, and open blockers — sources attached. Returning to work stops feeling like returning to a crime scene.
• Decision archaeology. "What did we decide about usage-based pricing, and where is it written down?" The phrase "I swear we discussed this" stops costing your team forty minutes a pop.
• Meeting prep in ninety seconds. Ask for a summary of the epic, its open risks, and what's currently blocked — before the standup. Walk in informed instead of nodding strategically.
• First drafts grounded in reality. A status update drafted from actual ticket activity rather than memory. You supply the judgment; it supplies the receipts.
• Ask the handbook. Policy and process questions answered from your own documentation, page linked. The kind soul who used to field those pings gets their afternoons back.

One more lever worth knowing: when the ask outgrows a quick answer — "compare these three retrospectives and draft the recurring themes" — Rovo Chat's heavier reasoning mode can take on genuinely multi-step work and hand back a deliverable, not just a reply. The line between asking a question and delegating a task is getting delightfully blurry, which happens to be the perfect setup for Monday's post.

And it lives where the questions occur: in the panel beside your Jira and Confluence work, and in the browser extension, so the conversation is never more than two clicks from wherever you are.

The honest part

Here's the sentence I owe you as a trusted advisor: Rovo Chat is a mirror. It reflects the state of your knowledge base with perfect fidelity. If your Confluence is a well-tended garden, the answers are remarkable. If it's a junk drawer of outdated pages and triplicate specs, Chat will faithfully summarize the junk — politely, confidently, and with citations to pages you should have archived in 2024. That isn't a flaw in the tool; it's the most useful diagnostic you'll run all year. It's also why the citations matter. Click them. Always click them. Trust gets earned one sourced answer at a time.

The Avaratak Take

"AI readiness" gets discussed like a procurement question. It's mostly a hygiene question. The single highest-leverage thing you can do before rolling out Rovo Chat costs nothing: archive the dead pages, mark the canonical ones, and fix the permissions quietly hiding your best content. Treat your Confluence like the training material for every AI teammate you will ever onboard — because that is precisely what it is. The organizations getting outsized value from Chat aren't the ones with the biggest budgets; they're the ones whose knowledge was worth reading in the first place. Pleasingly, that's a fixable condition, and the fix improves life for the humans too.

Monday, door number three — and this is where the week gets fun: Rovo Agents, the ready-made teammates who don't just answer questions but actually do the work. Bring your backlog.

Until then: if your knowledge base needs to become garden rather than junk drawer before the AI teammates arrive, that's a tune-up we run all the time as an Atlassian Solution Partner at Avaratak Consulting. Find us at avaratak.com — citations available on request.

Try a quick experiment. Think of a document you know exists somewhere in your company — a deployment runbook, a pricing one-pager, that decision page from last autumn that finally settled the great naming debate. Now be honest with yourself: could you put a cursor on it in under two minutes? If you felt a small spike of dread just reading that, welcome. You're exactly who this week is for.

Starting today, I'm running Rovo Week on the Avaratak blog: five posts across five workdays, each one a practical answer to the question I hear constantly from clients — "Okay, but what do we actually use Rovo for?" Not the keynote version. The Tuesday-afternoon version. We open with Search today, move to Chat tomorrow, spend Monday with the ready-made agents, Tuesday building our own, and close the week with Rovo Dev. One door per day, all leading into the same house.

Door number one is the simplest and, I'd argue, the most underrated: Rovo Search. Or, as I describe it across the table from clients: Ctrl+F for your entire company.

The problem nobody puts in the budget

Your organization does not have a knowledge problem. It has a finding problem. The runbook exists. The spec exists. The decision was documented, by someone, somewhere, with the best of intentions. It's just scattered across Jira, Confluence, Slack, Google Drive, SharePoint, Figma, and at least one tool nobody will admit to still using. Atlassian's State of Teams research puts the cost of that scatter at a figure I still have trouble saying out loud: 2.4 billion hours a year lost to information hunting across Fortune 500 organizations. That's not a productivity rounding error. That's an invisible department whose entire job is looking for things.

Rovo Search attacks the scatter directly. One search box that reaches across your Atlassian tools and the third-party ones you've connected — Google Drive, SharePoint, Slack, Teams, GitHub, Figma, and a long list of others — and brings back results ranked by what's actually relevant to you and your work, courtesy of the Teamwork Graph that maps how your people, projects, and content connect. Two properties make it trustworthy enough for grown-up organizations. First, it's permission-aware: you can only find what you already had access to, so search never becomes a side door. Second, it lives where you do — inside your Atlassian tools and in a browser extension that follows you anywhere. (If you want the deeper story on how Atlassian search learned to speak human, I wrote about that shift in Goodbye Keyword Karaoke. Today is about what to do with it.)

Five things to point it at this week

• Onboarding archaeology. New hires don't know what the runbook is called or which space it lives in — and with Rovo Search, they don't have to. Describe the thing, find the thing. It's the fastest way I know to shrink "time to first useful day."
• "Who owns this?" Because results ride on the Teamwork Graph, you're not just finding documents — you're finding the people attached to the work. The next time something wobbles at 4:55 PM, the answer to "who do I even ask?" is one search away.
• Retiring version roulette. Six copies of the same deck exist; one of them is current. Graph-ranked results surface the canonical, recently touched version instead of the 2023 souvenir edition.
• The whole picture, one results page. The Jira epic, the Confluence spec, the Figma file, and the Loom walkthrough about the same initiative — together, instead of four separate expeditions.
• Search from wherever you already are. The browser extension means no pilgrimage back to a portal mid-task. The question gets answered where it occurred to you.

The practical bits clients always ask about

Rovo's core capabilities, Search included, come with the paid plans of Jira, Confluence, and Jira Service Management — AI usage allowances vary by plan, so it's worth a quick look at where your organization sits. Connectors are set up by your admins, and here's the sentence I make every client write down: because Rovo respects your existing permissions, your permission hygiene is now a search-quality issue. Overly locked-down spaces make good knowledge invisible; overly open ones surface things you'd rather they didn't. Either way, search will show you the truth about your setup faster than any audit.

The Avaratak Take

If you're wondering where to start with Rovo — and most teams are — start here. Search is the one capability that demands zero behavior change: nobody needs training to type into a search box. The payoff is immediate, the risk is minimal, and there's a quieter benefit underneath: every good search result builds organizational trust in the Teamwork Graph. That trust is the foundation you'll need later in the week, when we start handing actual work to agents. Teams that skip straight to agents without earning it tend to relearn this lesson the expensive way.

Two preparation moves before rollout: audit your connectors (the graph can only search what's plugged in), and review your permissions (see the sentence you just wrote down). An afternoon of groundwork, months of compounding payoff.

Tomorrow, door number two: Rovo Chat — what happens when the search box becomes a conversation with a coworker who has read everything your organization ever wrote.

And if you'd like a guide for the whole journey — connector audits, permission reviews, and a Rovo rollout sequenced so each step earns the next — that's exactly what we do as an Atlassian Solution Partner at Avaratak Consulting. Find us at avaratak.com. We'll help you find everything else, too.

Here's a fun diagnostic I run with new clients: I ask to see their Jira Service Management project, and then I ask one question. "When a ticket comes in, how does your team know which one to work on first?" The answers are revealing. Sometimes it's "whoever shouts loudest." Sometimes it's "Dave just knows." Occasionally it's a long pause followed by "...vibes?"

If your service desk runs on vibes and Dave, this post is for you. Because underneath every JSM rollout that actually works — including all the AI-powered wizardry getting keynote time lately — sit three unglamorous load-bearing walls: SLAs, queues, and automation. Get these three right and everything else gets easier. Get them wrong and no amount of AI will save you, because you'll just be disappointing people faster.

Let's build them in the right order.

Step one: SLAs — write the promise down

An SLA in JSM is simply a clock attached to a promise. "We'll respond to high-priority requests within one hour." "We'll resolve standard requests within two business days." The clock starts, pauses, and stops based on conditions you define — and that's where most teams stumble, so let's be precise.

Head to Project settings → SLAs. Out of the box, JSM gives you Time to first response and Time to resolution. Start with exactly those two. For each, you define three things:

• Start condition. Usually "Issue created." Simple, defensible, hard to argue with.
• Pause condition. This is the one everyone forgets, and it's the one that keeps your metrics honest. Set the clock to pause when the status is Waiting for customer. If the requester goes silent for three days, that's not your team's three days — and your SLA report shouldn't say otherwise.
• Stop condition. For first response: the first public agent comment. For resolution: the resolution field being set. Note that distinction — resolution set, not "status changed to Done." Workflows drift; the resolution field tells the truth.

Then attach goals to segments of work using JQL. A goal of one hour where priority = Highest, eight hours for High, two business days for everything else. And assign the right calendar to each goal — JSM lets you define working hours, so a ticket filed Friday at 6 PM doesn't breach a 9-to-5 team's SLA over the weekend. Unless you genuinely run 24/7, in which case, set the calendar to say so and staff accordingly.

One trusted-advisor note before you set anything aggressive: an SLA is a promise to other humans. Set targets your team can actually hit at normal staffing, not targets that look impressive in a slide. A 95% hit rate on an honest goal beats a 60% hit rate on a heroic one, every single quarter.

Step two: queues — make the promise visible

SLAs without queues are like speed limits without speedometers. The queue is where your agents live all day, so design it like you'd design a kitchen: the things you reach for most should be closest to hand.

Queues are built in Project settings → Queues (or right from the agent view), and each one is just a JQL filter with columns and a sort order. The pattern I install almost everywhere:

• "Breach imminent" at the very top: open issues sorted by Time to SLA breach, ascending. The ticket closest to breaking a promise is always the first thing every agent sees. This single queue does more for SLA performance than any pep talk ever delivered.
• "Unassigned" next: anything without an owner. Work that nobody owns is work that nobody does.
• Per-team or per-request-type queues after that: hardware, access requests, HR onboarding — whatever your real lines of work are.
• "Waiting for customer" at the bottom: parked, paused, out of the way.

And then the hard part: stop. Queue sprawl is real. I've audited projects with twenty-six queues, of which agents used four. Every queue is a claim on attention; if nobody works from it, delete it. Five to eight well-named queues beats two dozen clever ones, and your new agents will onboard in an afternoon instead of a week.

Step three: automation — defend the promise while you sleep

Now the quiet robot. JSM's automation lives in Project settings → Automation, and every rule follows the same grammar: when something happens, if conditions are met, then do something. The craft is in choosing rules that protect the SLAs and queues you just built, rather than automating randomly because the editor is fun (it is, though).

The starter set I'd put in any project:

• Auto-triage on intake. When a request is created, set priority and route it based on request type. Password resets don't need a human to decide they're a password reset.
• The breach defender. When an SLA hits, say, 30 minutes remaining, ping the assignee; at 15 minutes, escalate to the team lead and bump it into a high-visibility queue. Your SLA report stops being an autopsy and starts being an early-warning system.
• The nudge. When a ticket sits in Waiting for customer for three days, post a friendly reminder. After seven days of silence, resolve it with a polite note and an invitation to reopen. Stale tickets evaporate; agents stop babysitting ghosts.
• Balanced assignment. Round-robin new requests across available agents so work spreads evenly instead of piling onto whoever answered fastest last sprint.

Two rules of the road: test every rule in a sandbox or low-stakes project before trusting it, and revisit your rule list quarterly. Automation that misfires silently is worse than no automation — and rules, like queues, accumulate barnacles.

The Avaratak Take

Notice the order we built in: SLA first, queue second, automation third. That's not arbitrary. The SLA defines the promise, the queue makes the promise visible, and the automation defends the promise when humans are busy, away, or asleep. Teams that bolt on automation before defining their promises end up with very efficient chaos.

And here's the forward-looking part: this trio is also the foundation everything new gets built on. Every AI capability arriving in JSM — virtual agents, auto-triage, autonomous resolution — reasons over the structure you define here. An agent can't honor an SLA you never configured or route to a queue that doesn't exist. The boring plumbing is the prompt. Do it well, and the shiny stuff actually shines.

If you'd like a second set of eyes on your SLA targets, a ruthless queue audit, or an automation rule set that earns its keep, that's exactly the work we love at Avaratak Consulting. As an Atlassian Solution Partner, we'll tell you honestly which promises your team can keep — and then help you build the machinery that keeps them. Find us at avaratak.com. Dave deserves the help.

Every engineering team has a ghost in the build. It's that one test that passes on Tuesday, fails on Wednesday, and passes again on Thursday for reasons no one can name. So we do the thing we all swore we'd never do: we hit "re-run" until the build goes green, mutter something about timing, and move on. The test never gets fixed. CI trust quietly erodes. And six weeks later, half the team treats a red build the way we treat a "check engine" light — technically important, practically ignored.

Atlassian just shipped something that goes straight for that ghost. As of mid-May, Bitbucket's Agentic Pipelines — the feature that hands repetitive engineering chores to AI agents — now supports Claude as a provider alongside Atlassian's own Rovo Dev, and teams already using Claude Code can plug it directly into Bitbucket Pipelines without extra infrastructure or integration glue. The mechanism is almost suspiciously simple: add provider: claude to your pipeline configuration, and if you leave that line out, Bitbucket defaults to Rovo Dev. No new platform project. No quarter-long rollout.

I'll be honest about why this caught my attention, and it isn't the headline. It's what it says about where Bitbucket is heading.

From "build and test" to "handle the boring stuff"

For years, Pipelines was a CI/CD engine: build, test, deploy, repeat. Agentic Pipelines reframes Bitbucket as an orchestration platform for AI agents that handle the low-value, high-effort, repetitive work surrounding code — things like updating READMEs, triaging security reports, cleaning up feature flags, and generating PR descriptions. The stuff that's too small to schedule and too annoying to enjoy.

There's a number Atlassian likes to cite here, and it stuck with me: development teams spend roughly 84% of their day doing things other than writing code. If even a slice of that 84% can be delegated to an agent embedded right in the pipeline, you're not "adding AI" for the brochure — you're giving expensive, talented people their afternoons back. That's the anti-hype version of the AI story, and it's the one I actually believe in.

The flaky-test agent, and the part that matters

Atlassian's flagship example is a flaky-test remediation agent, and the workflow is worth walking through because the final step is the whole point.

You point it at a flaky test. The agent pulls the test's full execution history, failure patterns, and surrounding code context, runs the test to observe the failure firsthand, hypothesizes a likely root cause — timing issues, shared state, environment dependencies, test ordering — proposes a plan, makes targeted changes, and re-runs the test to verify the fix holds.

And then it stops. It opens a draft pull request and tags the person who triggered the fix as the reviewer, who then reviews the change and merges it.

Read that again, because it's the difference between a tool I'd recommend to a client and one I'd quietly steer them away from. The agent does the archaeology nobody wants to do. The human keeps the judgment and the merge button. That's not a limitation Atlassian forgot to remove — that's good design. Agents are extraordinary at tedious investigation. They are not your release manager.

The fine print I'd make every client read first

Here's where the trusted-advisor hat goes on. Running Claude Code through Agentic Pipelines falls under Atlassian's third-party product terms, which means your source code, prompts, and logs are sent to Claude Code, and Atlassian states it is not responsible for the privacy, security, or costs involved on that side.

For a lot of teams, that's a perfectly reasonable trade. For a regulated client, a defense contractor, or anyone with strict data-residency commitments, it's a conversation to have before anyone types provider: claude — not after. The capability is excellent. Knowing exactly what leaves your boundary, and getting sign-off to send it, is just due diligence. The Rovo Dev default keeps that data inside the Atlassian estate, which is why it's the sensible starting point for the cautious.

The Avaratak Take

If you want to try this without turning your CI into a science experiment, here's how we'd roll it out:

• Start with exactly one chore. Resist the urge to automate everything you've ever resented. Pick a single repetitive task — flaky-test cleanup is a great first candidate — and let the agent earn trust there before you expand its job description.
• Keep the human in the loop on purpose. The draft-PR-and-reviewer pattern isn't training wheels; it's the operating model. Treat agent output like a sharp junior engineer's first pass: frequently right, occasionally confidently wrong, always worth a read.
• Settle data governance up front. Decide whether provider: claude or the Rovo Dev default fits your compliance posture, and write that decision down where your team can actually find it.
• Measure the thing. Track how many flaky tests actually get retired, and how many agent PRs you merge versus reject. Good numbers make the case for expanding. Bad numbers mean you spent one line of config learning that — cheaply.

It's still open beta, and Atlassian has signaled that Claude Code is just the first of more third-party CLIs to come. Translation: the orchestration layer is opening up, and the teams that get comfortable now will have a head start when the catalog grows.

The exciting part isn't that your pipeline can suddenly think. It's that it can finally take the chores off your plate so your people can do the work only people should be doing. The agent fixes the flaky test. You decide whether the fix is right.

Always with your best interests first. That part doesn't get automated.

Weighing where AI agents fit in your Atlassian stack — and which guardrails belong around them? That's exactly what we do at Avaratak.

I counted the open tabs in my browser before my coffee had finished brewing the other morning. Twenty-three. A Jira board I'd sworn I would triage, two Confluence pages I was “almost done with,” a Loom I kept meaning to watch, a fistful of articles opened with the best of intentions, and a calendar invite glaring at me from somewhere near the end. Not one of them was browsing in any meaningful sense. Every single one was a task wearing a tab's clothing.

If that scene feels a little too familiar, you're in excellent company — and as it turns out, that exact pile of half-finished intentions is the problem Atlassian just spent $610 million trying to solve.

Wait — Atlassian bought a browser?

It did. In September 2025, Atlassian announced it was acquiring The Browser Company of New York — the team behind the Arc and Dia browsers — for roughly $610 million in cash, and the deal closed that October. If your first reaction is “a teamwork-software company bought a web browser?”, you're not alone. That was my reaction too, for about ten minutes. Then I read the thinking behind it, and it clicked.

Here's how Atlassian co-founder and CEO Mike Cannon-Brookes framed it: today's browsers were built for browsing — reading the news, watching videos, looking up recipes — not for the work most of us actually do in them all day. Most of those open tabs, he noted, represent a task that needs doing. A meeting to schedule. A design to review. A work item to update in Jira. A memo to write. Before long, you can't see the work for the forest of tabs.

Dia — the AI browser The Browser Company launched in beta in mid-2025 — was built around a different premise: a browser you can actually talk to, one that understands the tabs you have open rather than just rendering them. Atlassian's plan is to take that, aim it squarely at knowledge workers rather than the general public, and wrap it in the enterprise-grade security and compliance that real organizations require. As Atlassian's head of product Sanchan Saxena described it, the idea is to blend Arc's power-user polish, Dia's AI and speed, and Atlassian's two decades of understanding how the best teams actually operate.

For a sense of why anyone would chase this: Atlassian's own 2025 State of Teams research puts the time lost hunting for information at Fortune 500 organizations at a frankly staggering 2.4 billion hours a year. The browser is where that hunt happens. It's also, not coincidentally, where a handful of other players have started launching AI browsers of their own — so Atlassian is stepping into a suddenly fashionable space, but from an angle nobody else can easily copy: the context of how your company actually works.

The part I find genuinely interesting: they're already using it

This is where the story stops reading like a press release and starts being useful — because almost none of this is vaporware parked in a someday folder.

Start with the unglamorous groundwork. Long before Dia entered the picture, Atlassian had already been quietly teaching its AI to live in the browser. The Rovo browser extension drops Rovo's Search, Chat, Agents, and inline definitions into whatever browser you're already using — and, crucially, it works even outside Atlassian's own products. The muscle memory of “an assistant that follows me across my tabs” was already being built into people's workdays.

Then there's Dia itself. By the time Atlassian's Team '26 conference rolled around this spring, Dia was already in daily use by Atlassians around the world and had opened a closed beta for advanced enterprise features — including a Guard integration for data protection that's on its way. That sequencing matters. Atlassian is using the thing internally and hardening the security story before pushing it out broadly, which is precisely the order of operations you want from a vendor you're trusting with company data.

The announcement that made me sit up, though, was Dia Reports. Rather than you opening a browser, tracking down five sources, and asking an AI nicely, Dia Reports generates browser-native briefings on its own — think interview prep documents or decision memos — by weaving your everyday tools together with the context already living in Atlassian's Teamwork Graph. The stated ambition is for it to surface the briefing you needed before you thought to ask, and to require less prompting from you over time. A browser that quietly does the reading and a first pass at the thinking is a very different animal from the tab forest I opened this piece complaining about.

Underneath all of it sits the Teamwork Graph — Atlassian's context layer mapping how your people, projects, decisions, and tools connect. A browser perched on top of that graph isn't merely displaying pages; it understands that the Jira tab, the Confluence doc, and the Slack thread are three windows onto the same project. And the appetite is clearly there: Atlassian reports Rovo is now used by 75% of the Fortune 500 and more than 90% of its enterprise customers, with over 14 million Rovo-assisted actions in a single recent month. The browser is simply the next surface for all of that momentum.

The Avaratak Take

So what do I tell clients who hear “Atlassian bought a browser” and aren't sure whether to care? A few things, with the trusted-advisor hat firmly on.

First, the browser is quietly turning into a place where work gets done, not just a window you peer through. That's a shift worth planning for even if your own rollout is a year out. Second, the real differentiator here is governance — the Guard integration and the deliberate enterprise focus are the entire point, and they're exactly where consumer AI browsers tend to wobble. If you operate in a regulated industry, that's the detail to keep an eye on. Third, and refreshingly, you don't have to switch browsers next Tuesday to get value: the Rovo extension already delivers much of the “AI in my browser” upside inside the browser you have today, while Dia is the deeper, native step for teams who are ready for it.

And one honest caution, because that's the only way we know how to do this work. The prize was never fewer tabs — it's less context-switching. Bolt a brilliant AI browser onto a messy, undocumented way of working and all you'll have is a very articulate narrator for your chaos. The teams who win with this will be the ones whose Jira hygiene, Confluence knowledge, and Teamwork Graph are in good enough shape that the browser has something worth reasoning over. That groundwork isn't glamorous, but it's where the leverage hides.

Which brings me back to my twenty-three tabs. The honest fix was never a faster browser — it was a browser that understood nineteen of them were one project wearing a trench coat. That's the future Atlassian is building toward, and it's exactly the kind of shift we love helping teams get ahead of. If you'd like to pressure-test what an AI-native browser could mean for the way your organization actually works — and which groundwork to lay first — that's a conversation we have for a living as an Atlassian Solution Partner at Avaratak Consulting. Find us at avaratak.com. We'll be the ones with a suspiciously small number of tabs open.

A client called me in early July last summer — let's call him the VP of "I'll Just Check Email Once a Day." He'd packed the family into the car, driven north to a cabin with a dock and a canoe, and promised everyone within earshot that this time he was actually going to disconnect. He lasted about eleven hours. By the next morning he was opening Jira on his phone over breakfast, and by the time he called me he wasn't relaxed — he was refereeing. Two tickets had been sitting unassigned for three days because their usual owner was also on PTO. An SLA was minutes from breaching. Nobody downstream knew who to ping. His words, not mine: "I didn't take a vacation. I took my laptop somewhere prettier."

If that lands a little too close to home, you're in good company. It's practically the unofficial anthem of summer for any team that lives in Jira and Confluence. We spend eleven months building momentum, and then the warm weather arrives and half the org rotates out the door in staggered, overlapping waves. The work doesn't stop. The people just pause. And the gap between "the work" and "the people" is exactly where things quietly fall through the floor.

Here's the reframe I offer clients every year around this time: the problem was never the vacation. Vacations are good. People should take them — fully, without a laptop balanced on a cooler. The problem is the coverage gap, and a coverage gap is an operations problem, not a willpower problem. You don't close it by guilting people into checking in from the lake. You close it before anyone leaves, by teaching your Atlassian stack to hold down the fort.

What "holding down the fort" actually looks like

Jira and Confluence automation is one of those capabilities sitting right under everyone's nose — already included in the tools you pay for, and routinely underused. At its core it is gloriously simple: when something happens (a trigger), if certain conditions are met, then do something about it (an action). That's the entire grammar. The craft is in pointing it at the right summer problems.

A handful that earn their keep every July:

• Auto-reassignment for the out-of-office. When a ticket lands on someone who's away, you don't want it marinating in a digital lost-and-found until they're back and sunburned. A well-built rule spots work assigned to anyone on your "out this week" list and quietly routes it to their designated backup, with a comment explaining why. The original owner returns to a handled queue instead of a horror show.
• Scheduled sweeps so nothing goes stale. A scheduled trigger can comb your boards on whatever cadence you choose — every morning, say — flag anything that's gone quiet too long, nudge the right person, or escalate before a deadline becomes a missed one. Think of it as the conscientious colleague who never takes a day off.
• SLA and priority escalations on autopilot. If a high-priority issue drifts toward a breach while its owner is unreachable on a beach somewhere, the rule notices and bumps it up the chain on its own. Your customers never feel the staffing gap, which is rather the entire point.
• Balanced, round-robin assignment. When you're down three people, dumping everything on whoever's left is just a recipe for a second wave of burnout. Automation can spread incoming work evenly across whoever is actually around, so your skeleton crew stays upright.
• Expectation-setting, handled for you. A small but underrated win: a rule that posts a friendly note on new requests letting stakeholders know the team is at reduced capacity this week and here's the realistic turnaround. Transparency, automated — and nobody has to remember to send it.

And this isn't a Jira-only story. Confluence automation can keep your knowledge base honest while people are away: publishing a weekly "who's covering what" page, archiving stale drafts, and reminding page owners to review their runbooks before they head out so whoever's covering isn't reverse-engineering a process from half-memory and hope.

A two-week, pre-vacation tune-up

You don't need a six-month transformation program to feel the difference. Here's a pattern I walk teams through. A couple of weeks before peak PTO season, map your critical paths — the handful of workflows that genuinely cannot stall, like customer-facing support, incident response, anything with a contractual clock ticking on it. For each one, ask a deceptively simple question: if the primary owner vanished tomorrow, what would break, and who would even notice? Wherever the honest answer is "nobody, until it's too late," you've found a candidate for a rule. Most teams need fewer rules than they expect; the trick is putting them in the right five places rather than fifty random ones.

Then — and this is the step everyone is tempted to skip — test it before you trust it. Run new rules against a quiet sandbox or a low-stakes project first and watch them work for a few days. Automation that misfires while everyone is away is worse than no automation at all, because there's nobody around to catch it. Build it, prove it, then go.

The Avaratak Take

Automation isn't about replacing the people who make your team great. It's about protecting their time off so they come back rested instead of resentful. We've watched the difference play out more than once: the team that set up thoughtful coverage rules in June spends July shipping calmly at half strength, while the team that didn't spends it forwarding frantic Slack messages to a manager who was supposed to be flipping burgers. Same tools. Wildly different summers.

The forward-looking piece — and where we're increasingly steering clients — is pairing those dependable rules with the AI now woven through the Atlassian platform. You can hand a Rovo agent a work item the same way you'd assign it to a teammate, or @mention one in a comment to summarize a long thread and propose next steps. A rule routes the work; an agent can take a first pass at it; and the colleague covering walks into context instead of chaos. Picture coming back from a week away to a tidy "here's what happened and here's what's waiting on you" rather than four hundred notifications and a knot in your stomach. The fundamentals haven't changed, though: the teams who win the summer are the ones who set things up before they leave, not the ones heroically improvising from a hammock.

So before you flip on your out-of-office and close the laptop, do your Atlassian stack the same favor you're about to do yourself — give it a proper plan for the quiet weeks. If you'd like a second set of eyes on which workflows to automate first, and just as importantly which to leave alone, that's exactly the sort of thing we love untangling as an Atlassian Solution Partner at Avaratak Consulting. Set the rules, pack the sunscreen, and let the automation earn its keep while you earn your tan. Find us at avaratak.com — we'll be the ones not checking Jira from the beach.

Go count the words in the last service request your team received. Not the thread that grew around it afterward, just the original description. I would put money on it landing somewhere between “it’s broken” and a lone screenshot with no caption. That blank-ish description field is quietly the most pessimistic piece of real estate in your entire toolchain, because everyone who looks at it already knows what comes next: the interrogation.

You know the routine. The agent turns into a detective working under bad lighting. “Which browser? What were you doing right before? Can you send a screenshot? Does it happen every time?” Three replies and a day and a half later, the actual fix takes ninety seconds. The work was never the hard part. Reconstructing what happened was.

Here is the shift I have been genuinely enjoying lately, and it is one we have started putting in front of our clients at Avaratak: what if the ticket showed up already knowing most of the answers? Not because your users suddenly became excellent technical writers overnight, but because they hit record instead.

The two-minute video that does the paperwork

Since Loom joined the Atlassian family back in October 2023, it has stopped behaving like a separate screen-recording app you bolt on the side and started behaving like a native part of the Cloud platform. One Atlassian login now covers Jira, Jira Service Management, Confluence, and Loom, the same account in the same neighborhood. That tidiness matters more than it sounds, but it is not the headline.

The headline is what Loom’s AI does with a recording once you stop talking. Record a quick walkthrough of the problem, and Loom can turn that clip into a fully populated Jira work item: a title, a written summary, and the steps it watched you take. And because a Jira Service Management ticket is simply a Jira work item wearing a service-desk badge, that populated item lands right in your queue. The blank description field fills itself out.

It goes further than a tidy summary. While it records, Loom can quietly gather the technical breadcrumbs developers usually have to beg for: device details, operating system and browser, app version, console errors, and the failed network calls hiding underneath the obvious symptom. Your customer thinks they recorded a two-minute “here’s what’s annoying me.” Your engineer receives a near-complete bug report. Everybody got what they needed, and nobody had to ask “what’s your browser version” for the ten-thousandth time. One housekeeping note for the planners among us: these AI workflows live on Loom’s Business and Enterprise tiers, so it is worth confirming which plan your team sits on before you promise anyone the moon.

The recording does not die in an inbox

Most workplace video has a tragic life cycle. Someone records something useful, shares it once, and it sinks to the bottom of a chat thread, never to be searched again. Video has always been a dead end for service work, because you cannot paste a forty-minute screen share into a knowledge base and expect anyone to scrub through it.

This is where the pairing earns its keep. Loom’s AI writes a transcript and a summary for every recording, which means the video finally behaves like text: findable, skimmable, quotable. Take that walkthrough of a common fix, drop it into a knowledge base article in Confluence (the same engine behind your Jira Service Management knowledge base), and you have turned one answer into a self-serve resource. The next person with that exact question watches the ninety-second clip and never files a ticket at all. That is the quiet magic of deflection: the best ticket your team handles is the one that politely never gets created.

Where this actually shows up on a Tuesday

The theory is lovely; the practice is where I get excited. A few patterns we keep recommending:

• Let customers show, not spell. A single recording replaces a six-message email chain of “can you clarify.”
• Let agents reply in person. Instead of writing a twelve-step wall of text, an agent records the fix on screen. Warmer, clearer, and weirdly faster to make than to type.
• Hand off across time zones without losing the plot. Tier-one records the context before clocking out, and a colleague three time zones away wakes up to a story instead of a mystery.
• Onboard new agents once. Capture the messy, undocumented workflows a single time and reuse them forever, instead of re-explaining the same quirk to every new hire.

None of these require a heroic transformation project. They require a record button and the willingness to press it.

A trusted-advisor word before you sprint off to record everything

Here is where I will be straight with you, because that is the only way we know how to do this work. A tool is one ingredient, never the whole recipe. If tickets are vague and resolutions are slow, video will help, but it will not paper over a service process that was never designed in the first place. Start narrow. Pick your three highest-volume request types, add Loom to exactly those flows, and watch two numbers: how long resolution takes and how your customer satisfaction scores move. Let the evidence earn the rollout.

The teams I expect to pull ahead over the next few years are not the ones who learn to type faster. They are the ones who hit record, let the work explain itself, and reinvest the reclaimed hours into the problems a transcript can never solve: the judgment calls, the tricky humans, the things worth a real conversation. Lights, camera, and a service desk that finally has the full picture before the first reply. Roll the tape.

Quick question before we get started: how many of your teams will be leaning on AI agents eighteen months from now? Go ahead, put a number on it. Now estimate the Rovo credits they will burn, the Forge apps they will spin up, and the departments that have not even asked for access yet.

If your honest answer landed somewhere between "no idea" and "ask me after lunch," you have just put your finger on one of the quietest, most expensive tensions in enterprise software today. We have spent years buying multi-year licenses to predict a future that now changes on a weekly basis. It is a bit like ordering a fixed-size wardrobe for a toddler — admirable optimism, guaranteed not to fit by spring.

This month Atlassian announced something aimed squarely at that tension, and as an Atlassian Solution Partner I have been hoping for a model like it. It is called Flex, a new commercial approach built, in Atlassian's words, for the AI era. Let me walk you through what it actually is, why the timing is sharp, and what I would whisper across the table if a client asked me about it.

A fixed wallet, flexible adoption

Here is the elegant part. Instead of committing to a rigid set of products and seat counts years in advance, Atlassian's largest customers can commit to a budget — a fixed "wallet" — and then spend it across the entire portfolio as their needs shift. Add users here, roll Confluence out to a new department there, pour budget into Rovo credits when an agentic use case suddenly proves its worth. Same wallet, different week, different priorities.

Atlassian frames it around three moves a customer can make, and each one is worth slowing down on:

• Commit to a budget, flex within it. Budget owners keep their predictability — finance still knows the number — while teams stop needing a fresh round of approvals every single time they want to try another Atlassian app or service. Anyone who has watched a promising pilot die in a procurement queue knows exactly how valuable that is.
• Consume flexibly across the platform. Users, products, and AI capabilities — from Rovo Dev's agentic experiences to autonomous support in the Service Collection — all drawn from the same pool. The organization adapts; the paperwork does not multiply.
• Optimize how spend fuels innovation. As usage evolves, customers keep redirecting budget toward whatever is actually delivering value — Atlassian products, Rovo credits, Forge usage, Bitbucket Pipelines, and the other platform capabilities that matter most to them.

What I appreciate here is the philosophical shift. Traditional licensing asks you to be a fortune teller. Flex asks you to be a grown-up with a budget and changing priorities — which, refreshingly, is what most enterprises actually are.

Why now? Because the ground is genuinely moving

A couple of numbers from Atlassian put the timing in context. More than 300,000 customers are on its cloud platform, and over 75% of the Fortune 500 are already running Rovo. Atlassian also notes it is shipping new innovations weekly — fresh Rovo capabilities, and new ways in DX to measure whether AI investments are actually paying off.

Sit with that for a second. If the vendor is shipping meaningful capability every week, a purchasing model frozen for three years is not just inconvenient — it quietly works against you. You would be locked out of your own upgrade path. Flex reads as Atlassian acknowledging that the cadence of value has changed, so the cadence of adoption needs to change with it.

It also bridges two worlds that usually sit in separate rooms: traditional seat-based licensing and modern usage-based consumption. Flex spans both. For anyone who has tried to reconcile "we pay per seat for this, but per usage for that" across a sprawling estate, that unification is its own small mercy.

The honest, trusted-advisor footnote

Now the part where I keep my integrity intact. Flex is being developed in partnership with select enterprise customers, and it is pointed squarely at Atlassian's largest organizations — the ones running long-term, multi-product relationships across many teams. So if you are a thirty-person shop, this particular announcement is not your moment, and I will not pretend otherwise. Your flexibility lives elsewhere in the Atlassian story, and we can happily map that out separately.

But if you are an enterprise wrangling many departments, several Atlassian products, and an AI roadmap that refuses to hold still, this is a development worth a real conversation rather than a casual scroll-past. The right next step is not a spreadsheet — it is a clear-eyed look at how your teams consume Atlassian today versus how Flex would let them consume it tomorrow. That gap is usually where the interesting decisions live.

What I am taking away

The most forward-thinking thing a software company can do right now is not another feature — it is removing the friction between a customer and their own willingness to adopt. Flex reads like Atlassian betting that the winners of the AI era will not be the teams who guessed their usage correctly in 2026, but the ones who stayed free to change their minds. That is a bet I happen to agree with.

At Avaratak Consulting, we spend our days helping enterprises turn the Atlassian platform into momentum rather than overhead. A commercial model that lets adoption breathe makes that work more honest and a good deal more fun. As an Atlassian Solution Partner, we are glad to help you pressure-test whether flexible adoption fits your estate, sequence the rollout, and keep your spend pointed at what actually moves the business. If Flex has you curious, find us at avaratak.com — my opinions, fittingly, are not fixed.

If you've ever watched a developer toggle between Jira, an IDE, three browser tabs, a Slack thread, and a Confluence page just to start a ticket, you already understand the problem Atlassian decided to solve last week. It's the same problem I see across nearly every engineering organization Avaratak walks alongside: developer time is hemorrhaging out the sides of every "agile" process we've ever drawn on a whiteboard. The work isn't the work anymore. The shuffle between tools is the work.

On May 20, Atlassian quietly dropped one of those announcements that sounds modest in the headline and turns out to be a quiet seismic shift in the agent-orchestration story they've been telling all year. The headline: Cursor is now an agent inside Jira. You can assign a Jira work item to @Cursor the same way you'd assign it to your teammate Priya. The agent picks it up in the cloud, gets to work, and pings you back inside Jira when it needs input or is ready for review. When it opens a pull request, that PR is automatically linked back to the ticket. No copy-paste. No "wait, which branch was that again?"

Here's the part that made me sit up a little straighter, though.

The DX data finally caught up to what we've been seeing on the ground

Atlassian referenced a multi-year DX study showing that developer velocity has been failing to keep pace with raw AI model capability — and the reason isn't because the models aren't good enough. The friction is everywhere around the IDE: context switching, planning, alignment, bug triage, code review. Agents have been brilliant at writing functions and abysmal at knowing why we wanted that function in the first place.

I've watched this play out in real engagements. A team installs a coding assistant, celebrates the productivity bump for three weeks, then plateaus. Why? Because the assistant doesn't know what the product manager promised the customer on Tuesday. It doesn't know that there's a sibling ticket blocking deployment. It doesn't know which Confluence page holds the architectural decision that everyone except the new contractor has memorized. The model wasn't the bottleneck. Context was.

That's what makes the Cursor-in-Jira move structurally interesting. Atlassian isn't trying to sell you on another coding agent — Cursor already has loyal fans. They're positioning Jira as the orchestration layer where humans and agents share the same workspace, the same backlog, and the same source of truth.

What you can actually do (and why your dev team will care)

I'll keep this list focused, because the announcement itself is generous with detail. Here's where I'd be paying attention if I were leading engineering today:

• Mention @Cursor in a Jira comment and a new agent session spins up against that work item. It's the same muscle memory as tagging a teammate.
• Automation rules can route entire categories of tickets to Cursor — think dependency bumps, lint cleanups, the "boring but necessary" tier of work that quietly eats Friday afternoons.
• Team members who don't have a local dev environment can still ship code. Designers, technical PMs, junior engineers in onboarding — they can kick off work and a PR appears for review. The blast radius of "I need to clone the repo first" just got a lot smaller.
• Rovo enriches the ticket with Teamwork Graph context before handoff, so Cursor doesn't start cold. It starts informed.
• Spec-driven flows sync agent-readable specs with Confluence, meaning your written intent and your executed code stop drifting apart by sprint three.

And the other direction matters too. Engineers working inside Cursor can pull live context out of Atlassian — issues, linked specs, dependencies, decisions — through the Teamwork Graph CLI or the Rovo MCP server. Atlassian shared internal testing numbers showing a 44% improvement in answer quality and 48% fewer tokens used when agents leverage that graph. That's not a rounding error. That's the difference between an agent that hallucinates a function signature and one that gets it right the first time.

What this means if you're running a real engineering org

Here's where I'll put on the trusted-advisor hat, because every client we work with at Avaratak is asking some version of the same question: "How do I adopt AI in engineering without burning the org down?"

A few honest observations.

First, this move makes the case for treating Jira as your system of record for AI work, not just human work. If your tickets are sloppy, your agents will produce sloppy output — faster than ever. The ticket-hygiene work most of us have been kindly suggesting for years just became urgent. Acceptance criteria, linked epics, properly tagged components — these aren't nice-to-haves anymore. They're the prompt.

Second, this is going to expose which teams have genuinely invested in Confluence as a living knowledge base versus which have used it as a graveyard for outdated decks. Spec-driven development only works when the specs exist and are findable. If your architecture decisions live in a Slack DM from 2024, this is your gentle nudge.

Third — and I'll say this kindly — the "I'll wait until the AI hype settles" strategy just got more expensive. Cursor in Jira is available on every paid Jira subscription. The barrier to entry is roughly one Marketplace install. The teams that learn the orchestration muscle now will be running circles around the ones still debating whether to pilot something next quarter.

Where Avaratak sits in all of this

We've been quietly preparing for exactly this moment. Helping clients clean up their Jira schemes, retire automation rules that no longer serve them, get Confluence spaces into a shape where Rovo and the Teamwork Graph can actually do meaningful work, and design governance models for agent-driven workflows that don't accidentally merge something interesting into production at 2 a.m.

Cursor in Jira is a feature. The real opportunity is the operating model underneath it. That's the conversation worth having.

If you're curious what this could look like in your environment — or if you'd like a second set of eyes on whether your current setup is ready to hand work to agents without regrets — that's the kind of conversation we're glad to have. Always with your best interests first. That part doesn't get automated.

I've spent more of my professional life than I care to admit playing a game I'll call Keyword Karaoke — that frantic exercise of typing every possible word you can remember about a document, hoping search will eventually reward you with the file you swear you wrote three Tuesdays ago. "Q2 strategy draft" — nope. "Roadmap planning notes" — still nothing. "That thing with the chart Maria sent" — absolutely not.

If you've nodded along to even one of those, welcome. You're among friends.

At Avaratak, we work with teams every day who don't have a knowledge problem. They have a finding problem. The information exists. It's well-written. It's even (mostly) organized. But the second someone needs to retrieve a specific insight in a live meeting, the search bar suddenly feels like a slot machine.

That's why I've been watching the latest wave of search improvements rolling through the Atlassian ecosystem with the focused enthusiasm of someone who has personally lost weekends to this problem. The shift unfolding right now — the move toward structured queries that blend natural language with precise filters — is one of the quietly important changes I've seen in years. And I want to talk about why it matters more than its modest billing suggests.

The way humans actually remember things

When you try to find a document, you don't think in metadata. You think in fragments: "that thing Maria shared in chat last month before the client review," or "the Confluence page with the table about Q3 hiring."

Traditional search was built to match exact strings. It rewards people who can recall precise titles, which — let's be honest — is approximately nobody after lunch on a Wednesday.

Structured queries flip the model. You describe what you remember, in plain language, and the search layer translates that into a combination of natural-language understanding and targeted filters — people, dates, work types, statuses, spaces, you name it. The result feels less like searching a database and more like asking a very well-organized colleague who has actually read everything you've ever shipped.

The Teamwork Graph quietly doing the heavy lifting

None of this works without context. And context is exactly what Atlassian has been stockpiling for years inside the Teamwork Graph — the connective tissue mapping people, projects, decisions, documents, and tools across your organization.

When natural-language search rides on top of that graph, something interesting happens. You stop searching for documents and start searching for meaning. The query "decisions our team made about pricing last quarter" stops being a Hail Mary and starts being an answerable question.

For our clients — many of whom are operating in regulated industries where decisions need to be traceable, and others who are scaling fast and losing institutional memory even faster — that shift is quietly transformative.

Why this matters for the AI-native organization

I'll get a little forward-looking here, because that's what we do at Avaratak: every team is becoming an AI-native team, whether they realize it yet or not. The companies that win the next five years won't be the ones with the smartest models. They'll be the ones whose models have the best context.

And context retrieval is the bottleneck right now. The most expensive AI agent in the world is useless if it can't find the relevant decision your team made six months ago. Structured queries are, in a real sense, the picks and shovels of the AI era — the unglamorous infrastructure that makes every fancier capability actually work.

It's also the kind of feature you don't fully appreciate until the third time it saves you in a single afternoon.

What we're telling our clients

A few practical things we've been advising the teams we work with:

First, audit your Atlassian footprint with fresh eyes. The richer and cleaner your Teamwork Graph, the smarter your search results. Disconnected tools, orphaned spaces, and abandoned projects aren't just clutter — they're noise that dilutes the signal everywhere else.

Second, get your governance right before you scale AI. Permissions, classifications, and content-lifecycle policies become exponentially more important when natural-language search can surface anything to anyone with the right phrasing. We've helped a number of clients walk through this conversation deliberately, rather than discovering the gaps in production. Strongly recommended.

Third, train your team to write for retrieval. Page titles, structured metadata, and consistent labeling used to be polite courtesies. Now they're the difference between "we found it" and "we'll just create another one." Small habits compound at scale.

The long view

I keep coming back to a simple thought: the value of your work has always been locked behind the question of whether anyone could find it later. That ratio — value created vs. value retrievable — has been quietly broken for decades. We just got used to it.

What's genuinely exciting about the direction Atlassian is heading is that the gap is closing. The tools are starting to meet humans where we actually live: half-remembered, slightly hurried, asking imperfect questions and expecting good answers.

That feels like the right direction. And it's exactly the sort of capability we love helping our clients put to work — because the best technology in the world only matters when teams can actually use it.

As an Atlassian Solution Partner, Avaratak Consulting sits squarely in this work: helping teams tune their Teamwork Graph, design governance that scales, and turn the latest wave of AI-native search into something measurable inside the business. If you'd like to talk through what this could look like in your environment, find us at avaratak.com. The coffee is metaphorical, but the advice is real.

I've spent the better part of my career standing up Jira Service Management projects for clients, and I have a confession — I have a soft spot for a well-oiled queue. The clean SLA dashboards. The neatly tagged tickets. The faint hum of a workflow that actually works. It is, for a consultant, the equivalent of a color-coded sock drawer.

So when Atlassian rolled out the Service Collection announcements at Team '26 under the cheeky banner “shatter the service quo,” my first reaction was a raised eyebrow and a quiet "go on…" By the time I finished the keynote, the white paper, and Shamik Sharma's recap, my second reaction was very different: this is not a coat of AI paint on an old shed. This is a rebuild.

Here is what I am telling Avaratak's clients about what just landed.

Solution Composer: service desks in minutes, not months

If you have ever sat in a kickoff meeting for a new JSM project, you know the rhythm. Weeks of permissions matrices. Request-type debates. Queue mapping. Automation rule sketching. At least one impassioned argument about whether the field should be labeled incident or issue. It is useful work, but it is also why "we'll get the HR portal stood up next quarter" is a sentence I've heard far too many times.

Solution Composer flips that script. Admins describe the service they want in plain English — “Build me an HR onboarding portal for the Williams Racing team,” to use Atlassian's own example — and Rovo drafts the underlying workflows, request types, automations, branding, and AI agents that power it. Because it is grounded in the Teamwork Graph (Atlassian's unified data layer that maps people, services, assets, and the relationships between them), it does not start from a blank page. It reuses proven patterns from your existing Atlassian estate.

Translation for clients: configuration timelines measured in weeks are heading toward minutes. That does not make solution partners obsolete. Quite the opposite. It means our hours stop getting eaten by configuration plumbing and start getting spent where they actually matter — governance, change management, and designing service experiences people don't dread using.

Rovo Service: tier-1 deflection that earns its keep

Every "AI chatbot" I have evaluated over the last three years had the same problem. It could answer FAQs. It could not actually do anything. The moment a user needed software provisioned, access approved, or a benefits change kicked off, the bot waved a white flag and tossed the ticket over the wall to a human queue.

Rovo Service is genuinely different, and it is available now. It is an AI teammate that autonomously executes multi-step workflows — provisioning software, managing access, running HR onboarding, handling common employee requests — end to end, with humans in the loop. It taps the Teamwork Graph to understand who the requester is, what their role allows, and which approvals and downstream systems need to be orchestrated. Then it hands off to a human gracefully when judgment is required.

The phrase I keep underlining when I explain this to leadership teams is judgment is required. That is the whole game. The work that needs human nuance now actually reaches humans, instead of getting buried in a queue of password resets and birthday balloon order requests.

Incident Command Center: one place when the wheels come off

Anyone who has been on a Sev-1 bridge call knows the experience. A Slack channel, two Zoom rooms, three observability tools, a runbook in Confluence that may or may not be current, and someone in a different time zone asking "who owns this?" The Incident Command Center (coming soon) consolidates alerting, investigation, and communications into a single AI-native journey.

It pulls signals from across the Teamwork Graph — third-party observability tools like New Relic and Dynatrace, service maps from Assets, deployment data from Bitbucket, GitHub, or GitLab, even feature flags — and assembles likely root causes, blast radius, recommended actions, and predicted business impact in real time. Rovo Ops then handles the heavy post-incident lifting: drafting the PIR, and handing off to Rovo Dev to generate the work items that prevent a repeat.

The unified asset, log, and trace intelligence piece is the part that genuinely excites me. We do a lot of Assets work at Avaratak, and the long-standing pain point has always been the same — CMDB data lives in one silo, log data in another, traces in a third. When an incident hits, somebody has to mentally stitch them together at 2 a.m. Atlassian's new partnerships with Honeycomb, Lansweeper, and Coralogix mean that signal now lands inside JSM, not in yet another browser tab.

JSM grows up — and brings the right tools with it

The other quiet revolution at Team '26 is that Jira Service Management is officially becoming a full Enterprise Service Manager. Native surveys arrived with templates for HR, business, and IT — no more bolting on a third-party survey app just to capture CSAT. Workforce Optimization (currently in early access) brings real scheduling, capacity planning, and intelligent work assignment to service teams. And the platform itself is extending into HR, marketing, legal, facilities, and any other function your enterprise wants to standardize.

Pair that with Employee Live Chat in the portal — which finally lets self-service flow seamlessly into real-time human support without losing context — and you have a service experience that respects the user's time at every step. Self-service first, AI assistance next, live human when needed, in that order, without a single "let me transfer you" black hole.

What I am telling clients to do now

Three things, in order.

First, audit your current JSM estate honestly. Which projects were stood up in a rush three years ago and could be reimagined from a Solution Composer prompt instead of held together with duct tape and tribal knowledge?

Second, identify your top five repetitive tier-1 request types and ask whether Rovo Service could resolve them end-to-end. That is where ROI shows up fastest, and where credibility for the broader AI program gets earned.

Third, if you operate incident response at any meaningful scale — or if you run an Assets practice that has been waiting for the day asset, log, and trace data finally play nicely together — start planning now for how the Incident Command Center reshapes your runbook strategy. The teams that get ahead of this will look like wizards in twelve months.

The service desk of 2026 does not look like the one we built in 2019, and the gap is only going to widen. The good news is that the platform is finally doing the heavy lifting, which means humans get back to the work humans were always meant to do. That is a future worth advising on — and one we at Avaratak Consulting are genuinely excited to help our clients build.

In 2018, spinning up a new JSM project meant a partner workshop, a stack of discovery questions, two weeks of building, and a launch checklist that mostly got ignored. In 2026, an admin describes what they need to a chat box and Rovo configures permissions, queues, branding, and integrations in roughly the time it takes to refill a coffee.

The interesting question isn't whether that's faster. It's what becomes possible when configuration stops being the bottleneck.

The Service Collection — Atlassian's umbrella for the next generation of JSM and its connected operations tools — got the kind of stage time at Team '26 that signals a deliberate strategic shift. The product story isn't “we made JSM better.” It's “JSM isn't a helpdesk product anymore. It's the operating layer for every service team in your company, and the AI runs the boring parts.” Here's what's actually new, what it changes, and what we'd tell you to do about it if we were sitting across the table.

Solution Composer: configuration by description

Solution Composer is the headline that should make every operations leader pause. An admin describes the service they want to launch — “HR onboarding tickets with manager approval and a 48-hour SLA, branded for our People team, routed through our existing Slack workspace” — and Rovo assembles the project: request types, queues, permissions, approval workflows, integrations, branding. What used to be a multi-week build becomes a multi-minute conversation.

Honest partner take: this changes our implementation work too, and we think that's healthy. The value an Atlassian Solution Partner adds was never really in the click-by-click building of a Service Project. It was in helping you decide what to build, how it should fit your operating model, and what the change management looks like when you put real humans on the other end of it. Rovo gets very good at the first part of that sentence. The other parts still need a trusted advisor in the room — probably more than before, not less.

Rovo Service: when “tier 1” stops meaning “a person”

Rovo Service is the autonomous L1 agent. Not the “suggest an answer” virtual agents you've seen for years — an agent that takes action: pulls context from the Teamwork Graph, asks the right clarifying questions, accesses connected systems, and resolves common requests end-to-end without a human ever touching the ticket.

The deflection conversation changes shape here. The old metric was “what percentage of tickets can the bot answer before a human gets involved?” The new metric is “what percentage of resolutions can the agent execute autonomously?” Those are not the same number. Provisioning a Jira account, granting Confluence space access, generating a one-time password reset link, kicking off an HR document workflow — these are actions, not answers. Rovo Service is built to take them.

Incident Command Center: detection through resolution, one workflow

Incident Command Center pulls detection, investigation, and resolution into a unified workflow with Rovo-assisted root-cause analysis. For engineering teams, this is the piece that finally puts Atlassian on the same page as the modern incident response stack — bridging Jira Software, Jira Service Management, Compass, and the operational data they sit on top of.

The piece that earns its keep is the AI-assisted RCA. When an incident drops, Rovo can pull recent deploys, related Compass components, prior incidents with similar signatures, on-call context, and the Confluence runbooks that someone actually wrote down. The investigation phase — historically the slowest part of an incident — gets shortened from “hunt through six tools” to “review what Rovo already pulled together.”

Asset, log, and trace intelligence in the same fabric

This is the piece we want to flag specifically, because it's where the strategy gets interesting. The Service Collection unifies asset intelligence, log analytics, and trace data into the same operational picture that JSM and Incident Command Center are already running on.

Translation: when an incident hits, the on-call engineer doesn't tab-hop between five tools to understand what's actually going on. Assets, logs, traces, related tickets, and prior incidents — all surfaced in one place, all queryable by Rovo. The phrase “single pane of glass” is overused, but the point holds.

If your team has been investing in Atlassian Assets (and a few of ours have), this is where the investment compounds. The asset graph stops being a CMDB sitting off to the side and becomes the connective tissue between “what changed” and “what broke.”

Employee Live Chat: the missing handoff

Employee Live Chat fills a gap that's been quietly painful for years: the handoff from self-service to a human, without losing context. A requester starts in the portal, the Rovo virtual agent works the problem, and when escalation is needed the conversation hands off to a live agent with the full history intact — same surface, same thread, no “let me transfer you, please re-explain everything” experience.

It sounds small. It isn't. The friction at the bot-to-human boundary is where most virtual agent rollouts actually fail in production.

Beyond ITSM: JSM as a multi-team chassis

The Service Collection's broader bet is that JSM stops being an IT product. Surveys, workforce optimization tooling, and expanded templates for HR, Marketing, Legal, and Facilities — the chassis that started in IT now ships with first-party support for every internal service team you have.

This is the version of the argument we made in our recent DM Helpdesk piece, but with the product depth to back it up. The teams who treat JSM as “the IT ticket tool” in 2026 are leaving a strategic asset on the shelf.

What we'd actually do about this

The trusted-advisor instinct is to slow down and pick the right entry point. Three practical first moves we're recommending to clients:

1. Pilot Solution Composer on something small and new. Pick a service request type you don't have yet — a new vendor onboarding flow, a marketing brief intake, a facilities ergonomics request. Use Composer to stand it up from scratch. You'll learn very quickly what Rovo handles brilliantly and where you still need design judgment.
2. Stand up a brand-new service team on the Slack or Teams integration. If your HR team is currently running a DM-and-spreadsheet operation, that's the cheapest, highest-impact pilot in the room. The Composer plus chat-integration combination compresses what used to be a quarter-long project into a couple of weeks.
3. If Incident Command Center is on your radar, run a tabletop drill first. Map your current incident process to what the unified workflow assumes. The gaps will tell you exactly where your runbooks, on-call rotations, and Compass coverage need attention before you flip the switch.

And one piece of honest framing: not every Service Collection announcement is generally available the day after the keynote. Some are GA, some are beta, some are directional. We're tracking which is which for clients so the roadmap stays grounded.

Why this matters

The economics of service teams are about to shift. If tier-1 truly automates, headcount conversations change. If new service projects spin up in minutes, the partner relationship changes too. Both shifts favor companies that move thoughtfully — not the ones who over-commit on day one or wait for everyone else to figure it out first.

As an Atlassian Solution Partner, Avaratak Consulting is built for this kind of phase change: equal parts Atlassian Assets, JSM rollout, and the practical change-management work the big-picture announcements rarely talk about. If you're looking at the Service Collection and trying to figure out what's actually worth piloting in the next ninety days, find us at avaratak.com.