AI agents can help investigate failed builds, fix flaky tests and automate other development tasks. But setting up those agents has required more Pipelines configuration than it should.
Agent-powered steps often need different compute, permissions and runtime settings from ordinary build and test steps. Until now, teams have either repeated those settings across every agent-powered step or tried to make one set of global defaults work for everything.
We’re improving both sides of that experience:
- workspace admins can enable Bitbucket’s built-in AI agents without manually adding the complete agent configuration to every repository;
- teams can define reusable step configurations once, then apply them across multiple Pipelines steps.
Less YAML, fewer repeated settings, and a much shorter path from enabling an AI agent to getting useful work from it.
Enable Bitbucket’s built-in AI agents from workspace settings
Bitbucket already provides two built-in AI agents:
- Pipelines troubleshooter, which can investigate and fix failed Pipeline steps;
- Flaky test fixer, which can identify and remediate flaky tests.
Workspace admins can now enable these agents from Workspace settings → AI → Agentic Pipelines. Choose the agents the workspace should use and Bitbucket supplies the underlying agent configuration automatically.
Repositories still retain control. A repository can customise the default runtime used by built-in agents, including settings such as the build image or step size. A repository can also disable an agent’s trigger when that agent should not run there.
The workspace gets a sensible starting point; individual repositories can still adapt it where needed.
Define common step settings once
We’re also introducing reusable step configurations.
A step configuration is a named set of Pipelines options that can be shared across multiple steps. Teams can define the image, size, caches, services, permissions and other runtime settings once, then reference that configuration wherever those settings are needed.
Here’s the difference in practice. Without a reusable step configuration, each agent-powered step repeats the same runtime settings:
Before:
pipelines:
custom:
release-notes:
- step:
image: atlassian/default-image:5
size: 2x
script:
- agent: release-note-generator
review:
- step:
image: atlassian/default-image:5
size: 2x
script:
- agent: pr-reviewerWith a step configuration, the shared settings are defined once:
After:
definitions:
step-config:
agents:
image: atlassian/default-image:5
size: 2x
pipelines:
custom:
release-notes:
- step:
config: agents
script:
- agent: release-note-generator
review:
- step:
config: agents
script:
- agent: pr-reviewerIndividual steps can still override the shared configuration. That means teams can establish a common baseline without losing the ability to handle exceptions.
Although reusable step configurations make AI-powered steps much easier to manage, they are not limited to AI agents. Teams can also use them for common build, test or release configurations.
For example, a team might maintain:
- one configuration for ordinary builds and tests;
- another for release steps;
- a dedicated configuration for AI agents that need different compute or permissions.
The point is not another layer of abstraction. It is removing duplicated configuration while keeping each step explicit and reviewable.
Built-in agents, with your runtime settings
These two changes work together.
When a workspace admin enables a built-in agent, Bitbucket supplies the agent and its required configuration. If a repository defines a default reusable step configuration, the built-in agent uses those repository settings when it runs.
So a workspace admin can enable an agent centrally, while repository owners can continue to control how Pipelines runs that agent in their repository.
Get started
Workspace admins can enable the built-in agents from Workspace settings → AI → Agentic Pipelines.
To learn more:
