Every engineering team carries a steady stream of work that is necessary but rarely stimulating. Tasks such as triaging alerts, applying patches, or updating documentation follow a repeatable sequence: locate the issue, understand the change, implement a fix, run validation, and close the ticket. While each individual effort may seem minor, the cumulative effect is a significant interruption tax. Engineers lose focus, context‑switch frequently, and sprint planning becomes a game of fitting these chores between creative work. This drag not only slows delivery but also erodes morale, as talented people spend energy on routine execution instead of problem‑solving that drives innovation.
Security vulnerability remediation exemplifies this pattern, but it is far from the only one. New CVEs arrive continuously, each with a deadline and a prescribed playbook that rarely deviates. The real cost multiplies across every ticket, every team, and every quarter, manifesting as missed opportunities for feature development and technical debt accumulation. Recognizing that any predictable, schedule‑based activity with a clear definition of done can be treated as a candidate for automation opens a broader horizon. The goal is not to replace engineers but to shift them from the execution layer to the decision layer, where their judgment adds the most value.
Atlassian’s answer to this challenge is agentic automation: a system of AI‑powered agents that operate like knowledgeable teammates, guided by the organization’s own institutional knowledge. Rather than relying on generic, one‑size‑fits‑all prompts, the approach encodes the specific ways a team works—its frameworks, dependency patterns, and conventions—directly into the agents. This ensures that the automation understands the nuances of the codebase and can act with the same rigor a human would apply, while still delivering the speed and consistency of machines.
The architecture consists of three distinct agents that together close the loop on a unit of work. First, a dispatcher surveys the backlog, decides which items are eligible for automation, groups related tasks, and flags anything that requires human judgment. Second, a coding agent receives the selected items and carries out the necessary changes, drawing on detailed, code‑specific instructions. Finally, a closer runs after deployment to verify that the fix has actually reached production, confirming that the change was merged, built, and released before marking the item as complete. Each agent is invoked as a pipeline step, making the entire flow observable and controllable within the existing CI/CD system.
Implementation leverages standard Atlassian platform capabilities, meaning teams can replicate the pattern without procuring new tooling. Using Bitbucket Cloud with Agentic Pipelines enabled, each agent is defined as a versioned pipeline step. The steps invoke Rovo Dev in non‑interactive mode, while the prompts, configuration files, and reusable skills live alongside the application source code in the repository. This co‑location treats the automation logic as first‑class code: it can be reviewed, versioned, and improved through the same pull‑request workflow that governs production software.
The dispatcher’s intelligence resides in its prompt file, typically named something like .rovodev/vuln-autopatch.md. Rather than being a hidden rule engine, the prompt is a transparent set of instructions that guides the agent through a series of binary decisions: Is the work item a vulnerability? Does it belong to a known pattern? Is there sufficient context to proceed? Should it be batched with similar items? By encoding these choices in the prompt, teams gain full visibility into why an item was selected, grouped, or left for manual handling, fostering trust and enabling continuous improvement.
The coding agent, by contrast, keeps its own prompt deliberately minimal—often just a few lines that read the context, invoke the appropriate skill, and report results. The true expertise lives in the skill, a structured instruction set stored in the repository (for example, .rovodev/fix-vulnerability.skill). This skill captures where dependencies are declared, what patch‑application strategies exist for different languages or frameworks, and how to handle edge cases such as transitive dependencies or platform‑specific quirks. Because the skill is the single source of truth, engineers can invoke it directly in a Rovo Dev session, ensuring consistency between automated and manual fixes.
Under the hood, the skill functions as a decision tree that mirrors the reasoning an experienced engineer would use. Each branch outlines a specific fix strategy, the files to modify, the tests to run, and the verification steps to confirm success. The agent does not guess; it follows the codified knowledge, which improves over time as the team logs failures, adjusts the skill, and re‑runs the pipeline. This feedback loop transforms the automation from a static script into a living artifact that grows more reliable with each iteration.
After deployment, the closer agent steps in to answer the critical question: Did the fix actually make it into production? Its prompt (.rovodev/vuln-autotransition.md) directs it to locate the original ticket, confirm that a corresponding pull request has been merged, and validate that the deployed artifact contains the change. If any piece of evidence is missing, the agent leaves the item open rather than falsely asserting completion. Because the workflow is designed to be idempotent—relying on the current state of tickets, labels, and pull requests as the source of truth—running the closer multiple times cannot create duplicate actions or unintended side effects.
In practice, the dispatcher runs each day before the team’s core hours begin. By the time engineers log in, they find a set of pull requests ready for review, each representing a completed fix that passed the full build and test suite. If the coding agent encounters a compilation error, a failing test, or a situation requiring judgment, it halts and leaves the item untouched, preventing broken code from entering the repository. This design ensures that the only human effort required is the final pull‑request review, turning a previously tedious chore into a lightweight gate‑keeping activity.
The outcome is a shift in the engineer’s role from executioner to arbiter. Engineers spend less time context‑switching and more time evaluating whether an automated change aligns with broader architectural goals, thereby increasing the proportion of sprint capacity devoted to innovation. The backlog drains continuously instead of accumulating, and the predictability of the flow enables more accurate sprint forecasting and release planning.
Several guiding principles have emerged from Atlassian’s implementation that any team can adopt. First, invest in the prompts and skills as versioned code stored beside the product code; they are the true system, while the surrounding infrastructure is merely plumbing. Second, avoid generic prompts—tailor them to your specific frameworks, naming conventions, and dependency management practices. Third, iterate on real‑world runs: track merge rates, inspect failure logs, and continuously tighten the logic until the automation becomes reliable. Fourth, always verify before shipping: the agent must run the complete build and test suite before opening a pull request, establishing a non‑negotiable quality gate. Fifth, design for idempotency from day one, using existing system state as the source of truth so re‑runs are safe. Finally, attribute all agent‑generated pull requests to a dedicated service account, keeping machine contributions distinct from human history and simplifying audit trails.
While the example focuses on security vulnerability patching, the pattern applies to any repeatable, scheduled work with a clear definition of done: dependency updates, license compliance checks, documentation generation, or even certain types of refactoring. The market is seeing a surge in AI‑augmented DevOps tools that promise to reduce toil, but the most successful implementations share a common trait—they ground the automation in the team’s own knowledge rather than relying on opaque, black‑box models. Organizations that treat their institutional expertise as a first‑class asset will be able to scale these agents across multiple workflows, compounding the time‑to‑value gains.
To get started, identify one routine task that consumes a predictable amount of effort each sprint—perhaps a weekly library update or a daily log‑analysis ticket. Sketch out the decision steps involved, write them as a prompt, and encode the detailed fix logic as a skill in your repository. Configure a simple Bitbucket Agentic Pipeline that runs the dispatcher each morning, and monitor the resulting pull requests. Measure the merge rate, gather feedback from reviewers, and refine the prompts and skills based on actual outcomes. Once the first workflow demonstrates reliability, expand to additional processes, gradually moving more of your team’s effort from execution to judgment and unlocking greater capacity for innovation.