Agents

Answering pull requests

The agent opens a pull request and, when someone answers it, comes back: it revises the code on the same branch and replies in the thread. This guide turns that delivery on for your provider.

How it works

The agent already delivers change as a pull request, never straight to your main branch. What it could not do was hear the answer, and a reviewer's comment usually carries exactly the context the agent lacked: a business rule, a team convention, or simply that the change is wrong.

With events on, that comment becomes another run of the same agent. It checks out its own branch, treats what you wrote as ground truth about your environment, commits the revision to the same pull request, and replies in the thread saying what changed.

Step	What happens
1. You comment	A comment in the pull request conversation, or a review with changes requested.
2. The event arrives	The provider delivers it to the receiver URL, authenticated by the secret.
3. The agent returns	A new run, a checkout of the same branch, your words as context.
4. Commit on the same PR	The revision lands on that branch, so the objection and the answer stay together.
5. Reply in the thread	The agent replies naming you and saying what changed. There is a reply only because there was a commit.

Before you start

What you need

A repository connected on the provider (GitHub, GitLab, Bitbucket or Azure DevOps) with write access.
At least one pull request opened by the agent, since it only replies on its own.
Admin rights on the repository to register the webhook.

Note. The receiver URL and the secret are in the platform, under Agents, in the PR events card.

Note. On Bitbucket, write is granted on the OAuth consumer rather than per repository: a workspace admin has to tick Repositories: Write and Pull requests: Write on the ScaleQuality consumer, and each connection made before that has to be made again to pick them up. Until then agents can read, fix and verify, but the pull request never opens — and the platform says so on the Bitbucket connection instead of failing the run silently.

Install the app (recommended on GitHub)

On GitHub, installing the ScaleQuality app replaces the manual setup: it receives events on its own and agents sign pull requests as ScaleQuality rather than as the account that connected the integration. The permission belongs to the organization, so it keeps working when someone leaves, and it is limited to four accesses: code and pull requests for read and write, issues and checks read-only.

Under Agents, in the PR events card, pick GitHub and click Install on GitHub. Choose the organization and the repositories, confirm the permission screen, and you land back in the platform already connected. On the other providers, follow the manual setup below.

Set it up

Three steps: create the receiver in the platform, register it on the provider, and test it with a real comment.

Create the URL and the secret

Under Agents, in the PR events card, pick the provider. The platform returns a receiver URL and a secret. The secret is shown once; if you lose it, create a new one in the same card.

Register it on the provider

Under Settings → Webhooks → Add webhook. At organization level the webhook covers every repository in it, which is the simplest setup; at repository level it covers only that one.

Field	Value
Payload URL	the receiver URL from the card
Content type	application/json. This field defaults to x-www-form-urlencoded, and in that format the body arrives wrapped and the event is discarded.
Secret	the secret from the card
Which events	Choose "Let me select individual events". The default is "Just the push event", which never delivers a comment.
Events to select	Issue comments and Pull request reviews. Add Pull requests and Pushes only if you also want AI activity attribution.

Test it

On save the provider sends a test delivery (on GitHub it is the ping). A 200 means the URL and the secret are right; a 401 means the secret differs from the one in the platform. Then comment on a pull request the agent opened, something concrete like the business rule the change has to respect. Shortly after, the agent commits the revision to that same pull request and replies in the conversation.

Who signs the agent's work

The identity that shows up in your repository is not the same on every provider, and the difference belongs to the provider rather than to ScaleQuality. On all of them the commit carries the agent's Co-Authored-By trailer, the same trailer the platform reads to attribute AI activity.

Provider	Who opens it	How the commit is signed
GitHub with the app	scalequality-agents[bot]	ScaleQuality Agent
GitHub without the app	the connected account	ScaleQuality Agent
GitLab	the connected account	ScaleQuality Agent
Bitbucket	the connected account	ScaleQuality Agent
Azure DevOps	the connected account	the token's identity, with the Co-Authored-By trailer

Note. Installing the GitHub app is the only path today where the pull request itself stops carrying a person's face. GitLab offers a bot identity through a project or group access token and Azure through a service principal; neither is implemented, and this page will say so when either is.

What the agent never does

These limits are structural, not settings. None of them is optional.

Rule	Why
Only replies on pull requests it opened	Commenting on someone else's pull request would be joining a conversation uninvited.
Ignores bots and its own replies	Its reply arrives as an event too; without this it would talk to itself.
Stops after three rounds	A disagreement that survives three revisions needs a person, not another patch.
Never merges anything	The delivery stays a pull request a human reviews and approves.
Never replies without code	A reply with no commit is noise; if there was no revision, there is no comment.

If nothing fires

Symptom	Likely cause
Nothing happens after the comment	The pull request was not opened by the agent, or the webhook is on a different repository.
The provider gets a 200 and nothing happens	Content type is not application/json, or the selected events do not include pull request comments.
The provider shows an authentication error	The secret differs from the one in the platform. Create a new one in the card and update both sides.
The event arrived and no commit followed	The agent could not produce a change for that request. It does not comment without code; the run history shows what happened.
It worked twice and stopped	The three-round ceiling on the same thread.

Note. The secret is shown once, at creation. If you lose it, create another: the old one stops working the moment you do.

Backstage plugin