Dev team: AI agents review pull requests and triage GitHub issues

In a development team, code review and issue triage are two tasks everyone agrees are useful and nobody finds the time to do thoroughly. A pull request waits two days for a free person to read it, and the first comments are often about what a quick read would have seen: a missing test, a branch that is too wide, a forgotten secret. An issue arrives with no type, no priority, sometimes without the information to reproduce it, and it waits for a human to qualify it. These are method tasks, with criteria the team knows how to write down, and they suit AI agents as long as their rights are bounded.

The inspiration: a first read before the humans

The starting point is a use reported by Hermes Agent users, summarized in a card about the development team: review the open pull requests and triage the new issues. The idea is not to replace the human reviewer, but to hand over pull requests that have already been read, with the points to check at the top of the list, and issues that have already been qualified.

We keep two separate roles and a principle of caution: the agents comment and label, they decide nothing. Atako applies the idea with two agents whose GitHub access is deliberately restricted to reading, commenting and labeling.

What the two agents do

The scenario deploys two agents, both connected to your GitHub repository.

The PR reviewer reads the open pull requests. For each one, it goes through the title, the description, the changed files and the commits, opens the files that matter and compares them with the conventions you entered: tests, naming, size, commit messages, sensitive areas. It looks for risks of error, missing tests, changes touching authentication, payment or secrets, and changes nothing explains. It leaves a single comment per pull request: one line summarizing the change, what is good, then the points to check in order of importance, each tied to a file and, when possible, a line, and marked as blocking or as a suggestion. It ends with what it could not verify, for example running the tests. It remembers the last commit it read and comments again only when new commits arrive, with a short follow-up.

The issue triager takes care of new issues. It checks that the type labels (bug, feature, question, documentation) and the priority labels (high, medium, low) exist and creates the missing ones. For each issue without a label, it reads the text and the comments, looks for similar issues, decides a type and a priority according to your rules, applies the labels and adds a comment: what it understood, the reason for the priority, the probable duplicates and what is missing to act, for example the steps to reproduce or the version concerned. When the type or the severity is unclear, it says so, picks the lowest priority and asks the question.

Each pass ends with a summary in the chat, starting with what needs a human quickly.

What the agents do not do

The limits are part of the design. Neither agent merges, approves, formally requests changes, closes a pull request, pushes code or creates a branch. Those tools are not granted to them: this is not a promise made in an instruction, it is a missing capability. The triager closes, reopens, locks and deletes no issue, and it changes neither the title, nor the assignee, nor the milestone.

The agents do not guess. The reviewer quotes the file and the line, flags what it could not verify and invents no function and no test result. If it comes across a committed secret or token, it says where it seems to be, without copying it. The triager cites as duplicates only issues it actually found through search. And the decision stays human at every step, which is the principle of a design with human validation.

How to set it up in Atako

From the page of this use case, deployment takes four steps.

1. Connect GitHub. Create a fine-grained token limited to the repository, with read access to code and read and write access to issues and pull requests. The connection is checked before anything is created.
2. Enter your context. Give the repository in the form owner/name, your review conventions if you have any, and what makes an issue urgent for you. Without them, the agents rely on general good practices and on bug severity.
3. Deploy. A single action creates the two agents and the "Dev team" project. The agents are provisioned and receive their first instructions on their own.
4. First results, then a regular rhythm. The reviewer comments on the five most recent pull requests, the triager labels the ten latest issues without a label, and each summarizes its pass in the chat. Then the reviewer schedules its own passes at 9:00 and 14:00 on weekdays, and the triager its pass at 9:30.

If you do not have an account yet, creating one starts your trial and the scenario is set up right after. If your administrator has not allowed you to create agents, the deployment tells you so and stops there.

Where to see the results

The review comments are read in GitHub, on each pull request, and the triage labels and comments on each issue. The summary of each pass is read in each agent's chat. In the Atako project "Dev team" you find the how-it-works page and the follow-up of the work, and on the Atako floor the two agents appear with their current activity.

To adjust the behavior, write to the agent in its chat, for example "add to your conventions that every database migration must mention the rollback plan". It keeps the instruction in its memory for the following passes.

Guardrails

The access is deliberately narrow. The GitHub connection is granted to the agents with a limited list of twelve tools: read pull requests, files and commits, read and update issues, manage labels, add comments. An agent that sees a short list of tools uses them more reliably than an agent lost in a catalog of hundreds, and above all, what is not granted cannot happen, even if a text tries to force it. The agents treat titles, descriptions, comments and code as data to analyze, never as instructions.

The token you create is your first guardrail: limited to one repository and to precise rights, it bounds the possible damage whatever happens. It is stored encrypted, and you can revoke it on the GitHub side or remove the agents' access at any time.

Human validation sits at the decision points. You read the review comments, you decide what to fix, you approve and merge yourself, and you close, assign and schedule the issues.

What to expect

Expect useful comments mostly on pull requests of reasonable size: on a very large change, the reviewer will say so and concentrate on the most sensitive files, instead of pretending to have read everything. It cannot run your tests, and it says so in each comment. The triager is as accurate as your priority rules are precise; without them, it chooses caution and asks questions. The value comes from regularity: every pull request gets a first read within the half day, every issue arrives qualified, and your human reviewers spend their time on judgment and not on spotting.