Skip to content

ATLASSIAN 2026-08-28 Tier 3

Read original ↗

Atlassian — Agentic automation in practice: putting standard engineering work on autopilot

Summary

A first-party Atlassian Engineering post describing a production three-part agentic system that puts recurring, predictable engineering work — using security vulnerability remediation as the worked example — fully on autopilot. The architecture is a Dispatcher → Coding Agent → Closer loop, each built as a versioned Bitbucket Agentic Pipeline step invoking Rovo Dev non-interactively, with prompts, model/tool config, and reusable skills living in the repository alongside application code. The Dispatcher (a scheduled Jira Automation rule) fetches eligible work within a time window, classifies automatable vs judgement-requiring items, deduplicates and batches items sharing one underlying fix, and dispatches one coding-agent run per batch. The Coding Agent is a thin harness that reads the dispatched items, invokes a fix-vulnerability skill — a decision tree encoding how vulnerabilities are fixed in this specific codebase (direct dep bump vs platform-baseline bump vs transitive-dep override vs base-image tag vs sidecar pin) — and opens a PR only after the build passes ("No green build, no PR"). The Closer runs after deployment, verifies the change was merged and that the deployed build actually includes it before transitioning the Jira item to done — leaving items open rather than falsely claiming success, and designed to be idempotent so daily re-runs are safe. Reported results (May–July 2026): 120+ vulnerabilities resolved, 55+ automated PRs merged, 95% first-run merge rate. The thesis: "The prompts are the system" — institutional knowledge encoded as versioned, reviewable, improvable artifacts in the repo; everything else is infrastructure.

This is the vulnerability-remediation companion to the Jira team's earlier KTLO post (sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in), which covered flaky-test triage and stale-feature-flag cleanup with the same Jira-as-substrate + Rovo Dev + work-item-as-prompt shape.

Key takeaways

  • A three-part loop is the reusable shape. The system decomposes into "a dispatcher that finds work, a coding agent that does it, and a closer that finishes the loop." Each is a separately invoked, versioned pipeline agent — not one monolithic agent — which keeps each stage's prompt narrow and reviewable. Canonicalised as dispatcher-coding-agent-closer. (Source: sources/2026-08-28-atlassian-agentic-automation-in-practice-putting-standard-engineering-work-on-autopilot)

  • The Dispatcher makes four decisions before any coding agent runs: "1. Fetch: find eligible work items within the configured time window. 2. Classify: distinguish work the system can handle automatically from work that needs human judgement. 3. Deduplicate and batch: combine items that share the same underlying change, so one coding-agent run can address them together. 4. Dispatch: start a coding-agent run for each batch and pass along the relevant context." Deduplication/batching is the interesting bit — many vulnerability tickets often collapse to one dependency bump.

  • The skill is where the real work is, and it is a decision tree. The coding-agent prompt is deliberately thin ("read context, invoke the skill, report back"); the codebase-specific knowledge lives in .rovodev/skills/fix-vulnerability/SKILL.md. That skill walks the same decision tree an engineer would — where does the vulnerability live? → application dependency (direct → bump; platform-baseline-fixes-it → bump baseline; transitive → bump parent, or declare-and-force-override if platform-locked, or declare explicitly if unlocked; isolated sub-component → override there) / base container image (→ bump image tag) / sidecar (pinned → update pin; platform-managed → "Not our fix to make. Close and flag it."). Canonicalised as decision-tree-skill.

  • "No green build, no PR" is the trust primitive. After applying a fix the skill "confirms the dependency resolves to the patched version, runs the build to confirm nothing is broken, opens a pull request — titled, described, and linked to the vulnerability ticket." The always-on CI gate before the PR is the single rule the post credits with making the system trustworthy — an instance of agentic-pr-triage.

  • The Closer verifies deployment, not just merge, and is idempotent. "The Closer is triggered after a deployment and answers the question that matters: is the fix actually live? [...] verify that the corresponding change was merged, and confirm that the deployed build includes it before transitioning the item to its final state. If it cannot establish that evidence, it leaves the item open rather than claiming success. The workflow is idempotent by design, so re-running it is safe and does not create duplicate actions or close items twice." Canonicalised as idempotent-closer-verifies-deployment; leans on concepts/idempotent-operations.

  • Prompts are the system; store them with the code. "The prompts are the system. They encode institutional knowledge in a form that's versioned, reviewable, and improvable. Invest here first, everything else is infrastructure. Store them in the repository alongside the code they operate on." Everything — bitbucket-pipelines.yml (agent step definitions), .rovodev/*.md prompts, .rovodev/pipeline-config.yml (model + MCP + tool permissions), and .rovodev/skills/ — lives in-repo and is reviewed like code. Canonicalised as prompts-as-the-system.

  • Generic prompts don't understand your world. "A prompt that works for one codebase won't work for another. Specialize for your frameworks, conventions, and dependency patterns." This is why the skill encodes this codebase's dependency-management specifics rather than general advice.

  • Iterate on real runs, not theory. "A prompt that works once isn't done. It needs failure logs and continuous tightening to become reliable. Track your first-run merge rate and keep improving until it compounds." The 95% first-run merge rate is the headline reliability metric the team optimises.

  • Use a dedicated service account for agent PRs. "PRs opened by the agent should be attributed to a bot, not a personal identity. This removes ownership ambiguity, makes automated work instantly recognisable in your PR feed, and keeps machine-generated changes cleanly separated from human contribution history." Canonicalised as dedicated-service-account-for-agent-prs.

  • The pattern generalises beyond security. "Any work your team does repeatedly on a schedule, following the same steps, with a clear definition of done, is a candidate for this kind of automation." This is the KTLO delegation criterion restated.

Systems / platform stack

  • Bitbucket Agentic Pipelines — defines each agent as a versioned pipeline step in bitbucket-pipelines.yml, triggered on a schedule, by an event, or programmatically. The pipeline step declares the OAuth-style scopes it runs with (e.g. read:repository, write:repository, write:pullrequest).
  • Rovo Dev — the AI coding runtime that powers each agent; reads/writes code, runs builds, interacts with Atlassian products. Invoked non-interactively in the pipeline. Config excerpt pins modelId: claude-sonnet-4-6 (Claude Sonnet 4 family).
  • Atlassian MCP tools — give agents scoped, permissioned access to Jira, Bitbucket, and Confluence APIs. pipeline-config.yml allowlists the exact tools (e.g. searchJiraIssuesUsingJql, getJiraIssue, transitionJiraIssue, createPullRequest, getPullRequests) via toolPermissions and points at an allowedMcpServers list — a per-agent least-privilege boundary.
  • Jira — the work-item substrate; a scheduled Jira Automation rule triggers the Dispatcher, and item status is the source-of-truth that makes the loop idempotent.

Repository layout (from the post)

my-service/
├── bitbucket-pipelines.yml       # Agent definitions and pipeline
├── .rovodev/
│   ├── vuln-autopatch.md         # Dispatcher: finds and dispatches eligible work
│   ├── vuln-codingagent.md       # Coding agent: applies a fix and opens a PR
│   ├── vuln-autotransition.md    # Closer: closes the loop after deployment
│   ├── pipeline-config.yml       # Model, MCP, and tool permissions
│   └── skills/
│       └── fix-vulnerability/    # Reusable codebase knowledge
│           └── SKILL.md
└── src/                          # Application code

Operational numbers

  • 120+ security vulnerabilities resolved (May–July 2026).
  • 55+ automated PRs merged.
  • 95% first-run merge rate — "no rework, no failed tests."
  • Dispatcher runs daily, before working hours, so fixes wait in PRs by the time the team starts.

Caveats

  • Tier-3 source and a product post (promotes Rovo Dev / Bitbucket Agentic Pipelines), but included because the architecture content — the dispatcher/coding-agent/closer decomposition, the decision tree skill, the idempotency + deployment-verification design, and the concrete production numbers — is the majority of the body.
  • Metrics are self-reported and scoped to Atlassian's own repos; no breakdown of what the remaining 5% first-run failures were.
  • The pipeline-config.yml and bitbucket-pipelines.yml snippets are explicitly "excerpts" / "simplified" — not the full production config.

Source

Last updated · 766 distilled / 2,225 read