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.

Every JSM admin knows the unofficial timeline for launching a new service project. It isn't “two weeks.” It's two weeks of clicking, three weeks waiting on approvals for the queue structure, two more weeks debating whether HR can share IT's portal, a week debugging integrations, and a final executive review that adds permissions nobody asked for. Total: roughly forever.

Atlassian announced something at Team '26 that breaks that timeline. Several somethings, actually. The Service Collection — Atlassian's umbrella for JSM, Assets, ITSM tooling, and a growing set of cross-functional service capabilities — got the biggest single-event upgrade in its history. Here's what changed and what it means for organizations that already live inside it.

Solution Composer: the headline that actually earns the marketing copy

Solution Composer is the announcement that genuinely reset the implementation conversation. Admins describe what they need — “stand up a Marketing intake portal that routes creative requests through a two-stage approval, brands consistently with our design system, and notifies the team lead in Slack” — and Rovo configures the permissions, queues, branding, and integrations to match.

Minutes, not weeks.

The skeptical reflex is to dismiss this as a launch-day demo. It isn't. The architecture that makes Composer possible — Rovo agents with read/write access to JSM configuration, the Teamwork Graph as context, and Rovo Studio as the underlying automation layer — has been quietly accumulating over the last twelve months. Composer is what happens when those pieces converge.

For organizations, this changes the math on whether to spin up a service project at all. The marketing team that needed request intake but wasn't going to wait six weeks for IT to build one? They can have it by Tuesday. The HR team running an inbox-and-spreadsheet system because the formal rollout kept slipping? Done by Wednesday.

For Solution Partners, the work shifts upstream. The hours we used to spend configuring permission schemes and queue structures move into what actually matters — workflow architecture, change management, integration strategy, the design conversations that decide whether a rollout sticks or sits unused.

Rovo Service: autonomous tier-1, end to end

Rovo Service is the second floor of this same building. The Rovo virtual agent handled deflection — answering common questions, gathering missing info, routing tickets to humans. Rovo Service goes further: autonomous resolution of tier-1 requests, full lifecycle. Reset a password. Provision an access role. Order a peripheral. Pull a report. The agent owns the work it's qualified to do and hands off cleanly when it isn't.

The right framing isn't “AI handles support.” It's “tier-1 stops being a human job for the work that doesn't need a human.” The people currently doing that work get redeployed to the things only humans can do — relationship management, complex troubleshooting, change coordination.

Incident Command Center: the war room collapses into a single surface

Incident Command Center is the operational headline. It unifies detection, investigation, and resolution in one place — replacing what used to be Opsgenie alerts, JSM tickets, Confluence runbooks, and a Slack war room held together with tribal knowledge.

Rovo-assisted root-cause analysis is the differentiator. The agent reads incoming alerts, scans recent changes (deployments, config edits, infrastructure events), correlates against historical incidents, and surfaces likely root causes while humans are still trying to figure out who to page. It isn't replacing on-call judgment. It's removing the first twenty minutes of “wait, when did this start?” from every incident.

The Service Collection is no longer the IT service desk

The quieter shift, but maybe the most strategically important: JSM is now treated as the chassis for every internal service team, not the IT department's tool that other teams borrow.

Surveys are baked into the request flow, closing the loop on every interaction without bolting on a separate tool. Workforce optimization features — forecasting, scheduling, capacity planning — bring the kind of analytics that contact centers have had for two decades into internal service teams.

This matters because the operational maturity gap between IT and other internal service functions is enormous. IT has had ITSM tools for thirty years. HR is still mostly working out of email and shared drives. Marketing intake lives in Slack DMs. Legal triage happens by tap on the shoulder. The Service Collection's expansion isn't a feature release — it's an acknowledgment that every internal service team deserves real tooling.

Employee Live Chat: the missing piece of the portal-to-human handoff

Employee Live Chat fills a quietly painful gap. Self-service catches what it can. When it can't, the requester wants to talk to a person right now — not file a ticket and wait an hour. Live Chat handles that transition seamlessly: the conversation context carries forward, the agent picks up where the virtual agent left off, and the resolved exchange still becomes a tracked artifact for reporting and pattern detection.

Paired with the JSM-in-Slack and Teams integrations, the portal stops being the only chat surface. It becomes one of several, chosen by where the requester already is.

Asset, log, and trace intelligence — unified at the incident

For the Assets-heavy organizations we work with, the most underrated announcement is the unification of asset, log, and trace intelligence inside the incident workflow.

Assets gave us the inventory and topology — what exists, what it depends on, who owns it. The new architecture combines that with live operational data (logs, traces, metrics from connected observability sources) so the incident commander sees the whole picture in one surface: which service is impacted, what's downstream, what changed recently, what historical incidents resemble this one, and which engineer worked the last one like it.

For organizations that have invested in building out their Assets model, this is a multiplier on that investment. The work spent mapping CIs, services, ownership, and dependencies suddenly powers every incident response. The work that felt like “we should probably have an inventory” is now the foundation for AI-assisted root-cause analysis. If you've been waiting for a payoff moment on the Assets program, this is it.

What this means for organizations already inside the Collection

The Service Collection has been quietly accumulating capability for several years. Team '26 was the moment those capabilities crossed a threshold. The collection is no longer a set of tools you buy and stitch together. It's an operating system for service work — internal and external, IT and non-IT, reactive and proactive.

The immediate decisions are pragmatic. What service teams have you been wanting to formalize but couldn't justify the implementation cost? Composer changes that math. What incidents have been eating senior engineering hours on diagnosis? Incident Command Center plus unified intelligence changes that math. What deflection rate have you been quoting that you privately suspect is generous? Rovo Service will move it.

For organizations not yet in the collection, the question is sharper. The build-vs-buy curve just bent. A lot.

This is exactly the kind of moment where the trusted-advisor work matters. The orgs we work with have legitimate questions about what to adopt first, how to migrate from older tooling cleanly, and how to design service architectures that survive the next round of platform changes. As an Atlassian Solution Partner, Avaratak Consulting helps service teams pick the right pieces of the new Service Collection, sequence the rollout, and tune the Rovo agents, Composer outputs, and incident workflows for what your organization actually needs. If the Team '26 announcements left you with more questions than answers, avaratak.com is a good place to start.

Your IT team isn't running a service desk. They're running an unindexed DM queue that occasionally produces tickets. Same for HR. Same for Finance. Same, probably, for whichever poor soul in Legal keeps getting pinged about NDAs at 4:47 PM on Fridays.

The work is getting done. The data isn't getting captured. And the people doing the helping have no way to prove how much of their week is spent helping.

There's a fix, and it's been quietly maturing inside the Atlassian stack for years: run Jira Service Management directly inside Slack and Microsoft Teams. With the Team '26 Rovo updates layered on top, this isn't just possible — it's the way you should be thinking about every internal service team in your organization.

The portal problem nobody wants to admit

Every IT director has the same story. They roll out a beautiful self-service portal. They send a launch email. They run a lunch-and-learn. And six months later, 60% of requests still arrive as DMs to whoever the requester knows personally on the IT team.

This isn't a training problem. It's a physics problem. People file requests where they already are. They are in Slack or Teams all day. They are not in your portal. They will never be in your portal.

You can fight that. Or you can route around it.

What “JSM in Slack/Teams” actually does in 2026

The Atlassian-native integrations for Slack and Microsoft Teams have quietly become genuinely capable. The current state of play:

• Raise requests from inside a conversation. Slash command, message action, or emoji reaction. A guided form appears inline. No portal hop required.
• Turn any message into a ticket. Someone DMed the wrong person? Right-click the message, “Create request.” The conversation context travels with it.
• Approvals in chat. Managers approve software access, time off, hardware requests, and contract reviews — all from Slack or Teams without ever opening Jira.
• Two-way sync. Agent comments show up in chat. Requester replies update the ticket. The conversation and the ticket are the same artifact.
• Channel-as-service-desk. Run an active triage channel where your team chats and works publicly — and any message can become a tracked, SLA-bound request without breaking flow.
• Rovo virtual agent. This is the bit that changed everything in the last twelve months. The virtual agent answers from your knowledge base, gathers missing info conversationally, triages priority, and only escalates to a human when it can't resolve. Powered by the Teamwork Graph, it sees the full context across Jira, Confluence, and connected sources — which is why answer quality is roughly 44% better than first-generation virtual agents.

This isn't just for IT

The most common mistake we see: organizations buy JSM, deploy it for IT, and stop. Internal JSM is a service-team chassis, not an IT tool. The same Slack/Teams workflow runs equally well for:

• HR — onboarding checklists, time off, benefits questions, “where's the holiday calendar?”
• Finance — expense help, PO approvals, budget questions
• Legal — NDA requests, contract reviews, policy lookups
• Marketing and Creative — asset requests, brand approvals, design queue intake
• Facilities and Workplace — desk reservations, building access, equipment

Every one of those teams is currently running an invisible queue out of DMs and channel pings. Every one of them deserves an SLA, a knowledge base, and a virtual agent doing the first round of triage.

The metrics that actually move

When this rollout is done well, four numbers shift in the same quarter:

• Time to first response. Drops sharply, because the virtual agent responds in seconds and humans only see what needs them.
• Volume of human-touched tickets. Common JSM customer ranges show 30–50% of repetitive requests resolved entirely by the virtual agent in the first 90 days.
• Hidden work, surfaced. Work that was happening in DMs now shows up in the data. Sometimes this is uncomfortable. It's also exactly what your leadership team needs to make staffing decisions that aren't guesses.
• Employee satisfaction. People don't have to learn another tool. They get answers faster. The two reliably move together.

The gotchas worth flagging before you commit

Three pitfalls we routinely steer clients around:

1. Don't run dual intake. If both Slack DMs and the JSM portal are “official” intake, you've added a tool, not replaced one. Pick the chat-first surface, repurpose the portal as the agent's interface, and communicate the change clearly. The transition needs executive air cover for the first month.
2. Train the virtual agent on what's actually true today. The knowledge base needs to reflect how the company actually operates right now — not the SOP that someone documented in 2021 and nobody has updated since. A virtual agent that confidently delivers stale answers is worse than no virtual agent. Audit and refresh the knowledge base before you flip the switch.
3. Permissions vary by service team. Default visibility settings that work for IT will not work for HR or Legal. Channel-based intake is great for IT triage and a privacy disaster for benefits questions. Plan request-type permissions and notification scopes before you launch, not after the first complaint.

Why this matters more in 2026 than it did in 2024

The Team '26 announcements made it clear where Atlassian is pointing JSM. The Rovo virtual agent is now context-aware across the entire Teamwork Graph. Third-party agents (Cursor, Copilot, Claude, Gemini) can pull JSM context through the MCP server. Rovo Studio lets non-developers build automations that tie incoming requests to downstream actions across Confluence, Jira, and connected tools.

Translation: the chat-based service desk is no longer just a convenience. It's the surface where AI gets to be genuinely useful to your internal teams. The organizations that wire this up in 2026 are going to have a meaningfully different cost-to-serve curve than the ones still defending their portal a year from now.

This is the kind of project where the tooling is mature, the integrations are first-party, and the gating factor is design and rollout discipline. As an Atlassian Solution Partner, Avaratak Consulting helps internal service teams stand up Slack and Teams-based JSM with the virtual agent properly tuned, the request types properly scoped, and the change management properly handled — so the rollout actually gets used. If your team is one DM avalanche away from burnout, find us at avaratak.com.

Most executives I work with don't have a data problem. They have a translation problem.

Their inbox is a fire hose of weekly updates, Slack lights up with status emojis at three in the afternoon, and somewhere on a second monitor a Jira dashboard is quietly loading itself into irrelevance. They can see everything. They just can't see what matters. So they ask a chief of staff, who asks a program manager, who asks a team lead, who asks Jira — and by the time the answer arrives, the question has already changed.

That's not a Jira problem. That's a dashboard design problem. After a few years of helping leaders at Avaratak Consulting wire up Atlassian tooling for the C-suite, I can tell you the fix is far less about plugins and far more about intent.

Here's how I help executives turn their Jira dashboards from wallpaper into a steering wheel.

Start with the decision, not the data

The single biggest mistake I see at the leadership level is building a dashboard that shows everything an executive could know. The result is what I call the airline-cockpit effect — every dial lit up, none of them prioritized, and a pilot whose eyes glaze over before takeoff.

Before opening Jira, I ask my executive clients three questions. What decisions do you make weekly? What decisions do you make quarterly? And what would you stop doing if you trusted the data more? The answers shape the dashboard.

A CFO who needs to reforecast quarterly cares about delivery confidence on revenue-impacting initiatives. A COO who runs operational reviews wants flow efficiency and aging work. A CEO in fundraising mode wants a one-page proof that strategy and execution are not, in fact, strangers. Decision first. Data second. Always.

Build in three layers, not one

I recommend a three-tier dashboard architecture, because no executive should ever have to scroll past a sprint burndown to find their strategic line of sight.

The top layer is the Strategic dashboard, and this is where Atlassian's Goals feature earns its keep. Each company OKR gets its own card, with status, owner, and the list of Initiatives or Epics rolled up beneath it. A Filter Results gadget with a JQL query along the lines of "Goal" = "OKR-12" AND status != Done gives a live tally of every piece of work tied to that objective. If the count is zero, that's a conversation. If the count is two hundred, that's a different conversation.

The middle layer is the Programmatic dashboard, where Plans (formerly Advanced Roadmaps) really shine. Here executives see the timeline view of cross-team initiatives, dependencies flagged in red, and capacity warnings before they become quarterly apologies. A Two-Dimensional Filter Statistics gadget — initiatives on one axis, RAG status on the other — turns a forty-minute roadmap conversation into a thirty-second glance.

The bottom layer is the Operational dashboard, and frankly, most executives shouldn't live here. But it's invaluable for the rare deep dive: a Sprint Health gadget, a Created vs. Resolved chart, and an Aging Issues report will tell you whether the engine room is humming or grinding. Keep it one click away, not front and center.

Wire OKRs to the work, not the other way around

The connection between strategy and Jira tickets is where most organizations quietly leak value. Teams write OKRs in one tool, plan epics in another, and pray they correlate. The cleaner pattern: define every Goal directly in Jira's Goals feature, then link each Initiative, Epic, and even Story to that Goal through the native hierarchy.

Suddenly your dashboard can answer the question every board asks: How much of our engineering capacity is going toward our top three objectives? One JQL query. One number. One honest conversation.

I also recommend adding a custom field called Strategic Theme or Investment Bucket. It costs ten minutes to set up and pays for itself every quarterly review. Slice your delivered work by theme and you'll almost always discover — uncomfortably — that thirty percent of your roadmap is going toward something nobody in the room can name.

Cadence beats sophistication

A beautifully designed dashboard that nobody looks at is just expensive art. I coach executive teams to embed dashboard reviews into the rhythm of business — fifteen minutes at the start of a monthly leadership meeting, with two simple questions: what changed since last month, and what decision do we need to make this month?

Confluence pages with embedded Jira dashboards (yes, the Jira Issues macro still works beautifully) make this even easier. The narrative lives in Confluence. The live data lives in Jira. The executive lives, briefly, in clarity.

A note on trust

Here's where I'll put on my trusted-advisor hat for a moment. Dashboards don't create accountability. People do. Jira will happily report green on a project that's hiding a six-week dependency risk if no one updates the status honestly.

The best executive dashboards we've helped build at Avaratak are paired with a cultural agreement: yellow is a gift, red is a sign of leadership maturity, and the only unacceptable status is silence. Tools are accelerators. Trust is the engine.

Where to start tomorrow

If you're an executive reading this and wondering where to begin, do this on Tuesday afternoon:

1. Pick your top three OKRs and create them in Jira's Goals.
2. Ask each owner to link their active Epics to the corresponding Goal — no exceptions, no orphans.
3. Build one Strategic dashboard with three Filter Results gadgets, one per OKR, showing live counts of open and in-flight work.

By Friday, you will see your organization in a way you almost certainly haven't before — not as a list of projects, but as a portfolio of bets against the outcomes you actually said mattered.

Jira is not a project management tool. In the hands of a thoughtful executive, it's a strategy-execution platform. The dashboard is just the windshield.

If you'd like help wiring yours up, that's exactly what we do. The team at Avaratak Consulting has spent years turning Atlassian's surface area into executive leverage, and we'd be glad to compare notes on what's possible inside your organization. Find us at avaratak.com.

Steer well.

There's a quiet rule in enterprise software: never hand away the part of your platform that customers can't replicate. Atlassian just broke that rule on purpose.

The headline announcement at Team '26 wasn't a new AI feature, a fresh agent, or even a pricing change. It was a posture shift. Atlassian is opening the Teamwork Graph — its 150-billion-connection context layer, built over two decades of enterprise use — to third-party AI agents and tools through both an MCP server and a new command-line interface.

Most of the news coverage is treating this as one bullet in a long list. We think it's the whole story.

The Teamwork Graph, briefly

The Graph isn't a search index. It's a continuously updated map of how work, people, decisions, code, and external assets connect across your organization. Jira issues, Confluence pages, Loom recordings, Figma files, Google Drive docs, code repos, SharePoint folders — anything customers link in gets ingested and woven into the relationship layer.

Atlassian says tools using the Graph have seen a 44% improvement in answer quality while consuming half as many tokens, because they pull the relevant context instead of dumping the whole haystack into the model's lap. That second number is the one your finance team should be circling.

Why opening it up is the strategic move, not the generous one

The instinctive read on this announcement is “Atlassian is being generous.” It isn't. It's being precise.

Here's what Atlassian figured out before its peers did: in 2026, the differentiating asset for enterprise AI isn't the model. Frontier models are commodities — you can swap them every quarter. The asset that can't be commoditized is the structured context of how your specific organization works. Atlassian has been building that asset since before “AI strategy” was a phrase anyone had to put in a deck.

So when Atlassian opens the Graph to Claude Code, Cursor, GitHub Copilot, Microsoft Copilot, Gemini CLI, and any other MCP-compatible agent, they're not giving anything away. They're making themselves the substrate every other agent has to plug into. Jamil Valliani, Atlassian's VP and AI Product Chief, framed the intent simply: “We want to get that power into everyone's hands.” Read between the lines: the more agents that depend on your Graph for context, the harder it gets for a customer to leave.

It's a moat that grows wider every time someone else's agent connects to it.

The Slack contrast

The reason this move stands out is that we just watched a different player do the opposite. Slack — under Salesforce — spent the last two years tightening the screws on its data graph: restricting how developers could index and store messages, throttling enterprise search vendors that had built businesses on top of the Slack corpus, and only grudgingly opening MCP access earlier this year after sustained pressure.

The framing was “security.” The market read it as moat preservation. It made companies like Glean and Dropbox Dash scramble. It made customers wary.

Atlassian is going the other direction, and Valliani has been unsubtle about why. The Teamwork Graph wasn't built in reaction to the AI moment — Atlassian was building it years before “agent” became a product category, deliberately, to be exactly this kind of platform. Opening it isn't a strategic pivot. It's the punchline of a setup that's been running since the early 2000s.

That's a meaningfully different posture for any enterprise weighing where to consolidate its work-context layer. Lock-in by superior open access is a much more durable position than lock-in by closed APIs. The first kind survives a regime change in IT leadership. The second kind invites a procurement review.

How this lands in real environments

Three practical implications for the next 90 days:

• The “should we let Cursor/Claude Code/Copilot touch our Atlassian stack?” question now has a vendor-blessed answer. The MCP server (open beta) and the new CLI are designed for that exact use case. Governance is built in — every agent interaction is auditable and traceable. If your security team has been blocking outside agents for lack of a sanctioned path, that excuse just expired.
• Microsoft shops get a real bridge. Atlassian is integrating the Teamwork Graph and Rovo directly into Microsoft Teams and Copilot via MCP. For organizations that live primarily in M365 but run their work in Jira and Confluence, this closes the gap between where teams communicate and where work actually lives. No more swivel-chair context switching.
• The “Atlassian-light” deployments just got more valuable. A customer using Jira and nothing else still has a Graph that any third-party agent can now query. Even if you're not buying deeper into the Atlassian stack, the data you've already accumulated is more useful than it was last week. That changes the ROI math for keeping (or expanding) what you already have.

The Rovo updates worth flagging in the same breath

Three Rovo updates landed alongside the Graph announcement and are directly relevant to the same strategy:

• Rovo Search is up to 40% faster on Jira, and from inside Jira it now searches across Figma, Google Docs, and the rest of your connected ecosystem through one interface.
• Max mode in Rovo Chat is the new heavy-lift reasoning mode. Hand it a multi-step task and it'll spin up a virtual machine, write Python if needed, learn an unfamiliar process from scratch, and produce the output. One Atlassian demo: building a podcast briefing from Confluence pages, including the audio file, with no prior instructions on how to make a podcast. Max mode is also available to third-party agents through the same MCP surface.
• Rovo Studio is generally available, with natural-language prompting as the new on-ramp. Atlassian reports a 7x growth in Studio-built workflows and agents since the early release. The barrier to “let's actually build the thing” just got significantly lower for the non-developer side of your org.

What we'd advise this week

If you're an Atlassian customer, three quick moves:

1. Audit which third-party AI tools your org is already using. Cursor, GitHub Copilot, Claude Code, ChatGPT, Microsoft Copilot — if any of those are in your environment, you now have a sanctioned path to give them real Atlassian context. Pilot one. See what 44% better answer quality looks like in your own workflows.
2. Get a baseline on your Graph completeness. The Graph is only as valuable as what's plugged into it. Inventory your connected sources — Drive, SharePoint, Figma, code repos — and identify the obvious gaps. Filling those is the highest-leverage AI work you can do this quarter.
3. Reset your AI vendor conversations. The right question to ask any AI vendor pitching you right now isn't “what model do you use?” It's “how do you access my context, and who owns that context?” Atlassian just made it easier to give a confident answer on the second question.

The deeper point Atlassian leadership clearly wants you to internalize: context is the new platform layer. The vendors who open it up win. The vendors who hoard it lose customers slowly, then all at once.

As an Atlassian Solution Partner, Avaratak Consulting helps teams turn moves like this into actual outcomes — auditing your Graph, plugging in the agents your team is already trying to use, and making sure the governance scaffolding is in place before, not after, things get interesting. If you'd like a second pair of eyes on where to start, find us at avaratak.com.

Every product manager I've ever met has at some point opened a spreadsheet, stared at 247 rows of "great ideas," and quietly wondered if they should just start a llama farm in Wisconsin instead.

I get it. The pain isn't a lack of ideas — it's the gulf between "this would be amazing" and "this is in production." For years, product teams have lived in one tool to think, another to plan, a third to spec, and a fourth to actually build. By the time an idea reached engineering, half its context had evaporated like coffee in a sprint-planning meeting.

That gulf is exactly what Atlassian closed when they wired Jira Product Discovery directly into Jira Software. And as a Solutions Partner who spends a healthy chunk of every week watching teams discover this connection for the first time, I can tell you — the reactions range from "wait, that's it?" to "where has this been all my life?"

Let me walk you through it.

JPD: where chaos earns its way onto the roadmap

Jira Product Discovery is Atlassian's home for the messy, beautiful, pre-roadmap chaos. It's where customer feedback gets captured, ideas get scored, opportunities get compared, and roadmaps get built. Think of it as the strategy whiteboard your team always wished it had — but one that doesn't get erased on Friday afternoons.

Inside JPD, you're working with ideas, not tickets. You can tag them, score them with custom fields, prioritize them with RICE or ICE or your own brand of arithmetic alchemy, and roll them up into views tailored for executives, customers, or that one stakeholder who only wants to see things in dark mode.

Jira Software: where ideas grow up and ship

Jira Software, on the other hand, is the engine room. It's where epics get broken into stories, stories get broken into tasks, and tasks get broken into a developer's afternoon. Sprints, backlogs, boards, releases, dependencies — it's the operational machinery of getting code out the door.

Either tool is powerful on its own. Together, they're a different animal entirely.

The magic happens in the Delivery panel

Inside any JPD idea, there's a Delivery panel on the right side. From that panel, you can either create a brand-new epic or task in Jira Software, or link to one that already exists. The link is bidirectional — JPD knows about Jira, and Jira knows about JPD.

A few details I love:

• One idea, many epics. You can link a single idea to multiple epics across multiple Jira Software projects. Big initiatives don't get squeezed into one team's lane.
• Your math, your call. Choose your delivery progress calculation — by issue count or by story points. Either way, JPD displays a progress bar inside the idea that reflects what's actually happening in delivery.
• Context comes along for the ride. Embed the idea's description and fields straight into the new epic, so engineers don't have to swivel-chair between tools to understand why they're building what they're building.
• Cloud and Data Center, side by side. Premium plan users can connect JPD to Jira Data Center instances — a huge win for enterprises straddling Cloud and on-prem.

Why this matters — the trusted-advisor take

Here's where I'll pull on my Avaratak hat for a moment, because the integration isn't just a feature. It's a different operating model.

When discovery and delivery live in separate tools, you get something I call "context loss tax." Every hand-off costs information. A PM writes a brilliant idea doc; an engineer reads a stripped-down ticket; somewhere in between, the why goes missing. Multiply that by a year of work, and you've built a roadmap of features nobody quite remembers asking for.

When the two are connected, the why travels with the work. An engineer opening a Jira epic sees the linked idea, the original customer insights, the priority score, and the strategic context — without leaving Jira. A PM watching the JPD idea sees real-time delivery progress without DM'ing the engineering manager for the third time that week.

That's not just convenience. That's organizational memory.

Three patterns we recommend at Avaratak

Three patterns I find myself recommending to clients constantly:

One idea, many epics. If you're shipping something cross-functional — say, a billing redesign that touches web, mobile, and backend — link one JPD idea to one epic per team. The delivery progress bar gives leadership a single number to watch instead of three Slack threads to chase.

Insights before commits. Use Jira Service Management as an insights pipeline into JPD. Customer feature requests flow from JSM into JPD as raw signal. Nothing moves to Jira Software until the idea has earned its way onto the roadmap. The result: a clean Jira backlog where every item is genuinely committed work, not aspirational debris.

Embed JPD views in Confluence. Stakeholders rarely want to log into another tool. Drop a JPD roadmap view into a Confluence page, wrap it in narrative context, and you've got a living strategy doc that updates itself.

The forward-thinking bit

The trajectory here is worth paying attention to. Atlassian is steadily collapsing the seams between strategy, planning, and execution. JPD ideas now show up directly in Jira Plans. AI features are being layered onto insights capture and roadmap synthesis. The tools are evolving toward something that feels less like a stack and more like a single fabric.

For teams still running discovery in spreadsheets and delivery in Jira, the migration is cheaper and easier than most expect. The hard part isn't the tooling — it's the habit change of letting ideas earn their way to delivery instead of arriving there by political momentum.

The bottom line

If your roadmap currently lives in three documents, four tools, and the heads of two senior PMs who happen to be on vacation, the JPD-and-Jira-Software pairing is one of the highest-leverage moves you can make this quarter. Less context-switching, more context-keeping. Less "what were we building again?", more "when does this ship?"

That's the kind of clarity we love helping our clients find at Avaratak. If your team's discovery-to-delivery flow feels more like a game of telephone than a relay race, we'd be happy to chat. We bring the playbook. You bring the ideas.