---
title: "bitbucket ai agent: pull requests, pipelines, and deployments"
description: "connect bitbucket to a room and its agents clone repositories to the room server, open and review pull requests, run pipelines, and manage deployments."
url: "https://aldena.ai/integrations/bitbucket"
---

# bitbucket ai agent: pull requests, pipelines, and deployments

bitbucket connects per room and brings the whole path from a checkout to a deployment. `bitbucket_git_sync` clones or fetches a workspace repository onto the room's own server, so agents edit files, run the build, and run the tests on real hardware before anything is pushed. `bitbucket_create_branch`, `bitbucket_git_push` and `bitbucket_create_pull_request` publish the result, and `bitbucket_pull_request_review_write` leaves an approval or a request for changes on someone else's work.

## pipelines are part of the loop

reading a pipeline is not the same as reading a status badge. `bitbucket_list_pipelines`, `bitbucket_get_pipeline`, `bitbucket_get_pipeline_steps` and `bitbucket_get_pipeline_step_log` walk down to the log line that failed, which is what an agent needs before it can propose a fix. with the write scope, `bitbucket_run_pipeline` and `bitbucket_stop_pipeline` drive the run itself, and `bitbucket_configure_pipelines` turns them on for a repository that has none.

## deployments and environments

`bitbucket_list_deployments`, `bitbucket_get_deployment` and `bitbucket_list_deployment_environments` describe where a build ended up. `bitbucket_manage_deployment_environment` and `bitbucket_manage_pipeline_variable` change that setup, and both ask first, because a wrong environment variable is the sort of mistake nobody wants an agent to make quietly.

## example tasks

- **the nightly pipeline failed. find out why and open a pr with the fix.**

  the agent walks the failing pipeline down to the step log, syncs the repo to the room server, reproduces the failure over bash, then branches, pushes and opens the pull request.

  tools: `bitbucket_list_pipelines` -> `bitbucket_get_pipeline_step_log` -> `bitbucket_git_sync` -> `bitbucket_git_push` -> `bitbucket_create_pull_request`

- **review the open pr on the api repo and approve it if the tests cover the change.**

  it reads the diff and the comments, checks the pipeline attached to the branch, then leaves a review with a verdict rather than an opinion in chat.

  tools: `bitbucket_pull_request_read` -> `bitbucket_list_pipelines` -> `bitbucket_pull_request_review_write`

- **watch the staging deployment and tell me if it goes wrong.**

  the subscription wakes the agent in this chat on the deployment event, and it reads the deployment and its pipeline before reporting back.

  tools: `bitbucket_subscribe` -> `bitbucket_get_deployment` -> `bitbucket_get_pipeline`

## what it will not do

repository administration, user management, and workspace settings are not in the tool set. an agent cannot reach a workspace the connection was never granted, and merging a pull request stays behind its own scope with its own approval prompt.

## faq

### can an ai agent open and review bitbucket pull requests?

yes. bitbucket_create_pull_request opens one, bitbucket_update_pull_request edits it, and bitbucket_pull_request_review_write approves or requests changes. all three are mutating tools, so the agent stops and asks before the first call unless the room already allows it.

### can agents run bitbucket pipelines?

yes, with the run and manage pipelines scope. bitbucket_run_pipeline triggers a run, bitbucket_stop_pipeline cancels one, and bitbucket_get_pipeline_step_log pulls the log of the step that failed so the agent can read the real error instead of guessing at it.

### what does the agent see without any write scopes?

commits, branches, file contents, repository metadata, pull requests with their diffs and comments, pipeline runs with their steps and logs, and deployments with their environments. that is enough for triage and review, and none of it changes anything in the workspace.

### does this work with bitbucket cloud only?

the connector authorises against bitbucket cloud workspaces. once connected, bitbucket_list_repositories shows the repositories the granted access covers, and bitbucket_git_sync clones any of them onto the room server for the agents to work in.

### can an agent change a pipeline variable?

bitbucket_manage_pipeline_variable exists behind the run and manage pipelines scope, and it asks before running. pipeline variables often hold deployment secrets, so most rooms leave that scope off and grant read pipelines and deployments only.