Skip to main content
Deploy this agent when an investigation has told you what is failing and the next question is where in the code it lives. It searches repositories for the evidence’s own strings, confirms candidates by opening them, and returns a ranked shortlist with the fix that shortlist supports. This page covers what it needs, what makes a good request, and where it stops.

What it does

You give it a characterised problem — an incident, an error message, a failing service. It searches code for the error’s own text, opens every candidate to confirm it rather than trusting the search ranking, and checks what changed there just before the problem started. What comes back is a ranked shortlist of files with the evidence for each, and the durable code change that shortlist points to.
It runs on concrete evidence. Given a vague problem statement with no error text, no service and no timeframe, there is nothing distinctive to search for — so pass it the output of an investigation rather than the original alert.

What it reads

Read access only. It never writes to a repository.

Before you deploy

The GitHub connection is required, and it gates the only path this agent has to GitHub. Without one it cannot search anything at all — it fails closed and says so, rather than returning an empty result that reads like “nothing found”.
This agent is enabled per workspace. If it is not in your catalog, an account administrator can request it for your account.

Ask it for

In chat, or as a run’s prompt:
The more of the investigation you pass through — the exact error text, the service, the window — the narrower its search, and the better the shortlist.

Defaults and limits

The catalog ID and the display name differ: the entry deploys as github-file-finder and presents itself as GitHub Agent once it reports in. Use the ID when calling the deploy API.

In a workflow

It sits downstream of an investigation, not in place of one. A workflow that has localised a failure to a service passes the findings here to turn “this is broken” into “this file is why” — and its shortlist is what a remediation step then acts on. See Orchestration for how a step delivers work to it.

What it will not do

It never modifies a repository. No branch, no commit, no pull request — it reads and recommends. Opening the pull request that applies a fix is Remediation Executor’s job. It also does not tell you what to do right now. Its recommendation is the durable code change that stops a problem recurring, which is a different question from how to restore service during an incident.

Next steps

Code Reviewer

The same repositories, read to review a change before it merges.

Remediation Executor

Turn the recommended change into a pull request.

Built-in integrations

Create the GitHub connection this agent needs.

Agent catalog

Every catalog agent, side by side.