# The PR Hound: how we fixed PR review assignment with a daily agent

We leaned into agentic coding and started shipping far more code than our review process could keep up with, so PRs piled up unreviewed. Six days after we put a daily agent in charge of review assignment, every open PR on our main repo, back to March, has exactly one owner and one reviewer.

*By Andrew Joia · July 9, 2026*

Canonical: https://langwatch.ai/blog/pr-hound

![The PR Hound: how we fixed PR review assignment with a daily agent](https://langwatch.ai/blog/pr-hound.webp)

By May we had shipped more code in two months than in the entire year before it: 184,200 lines added across our repos in March through May 2026, against 121,400 in the preceding twelve months. The driver was Claude Code, which we rolled out across the team.

![Code shipped over the last 14 months across LangWatch repos: 184,200 lines added in March through May 2026 against 121,400 in the prior twelve months, with a commit-per-day heatmap that jumps once Claude Code rolled out](https://langwatch.ai/static/img/pr-hound-code-shipped.webp)

Our PR review process was not built for that volume, and it showed. PRs piled up waiting on a review, and some sat long enough to grow merge conflicts. Six days ago I put a daily agent in charge of the part that was actually broken, review assignment. Now every open PR on our main repo, including one that had been sitting since March, has exactly one owner and one reviewer, and human merges have gone from about 10 a workday to 18.5. Here is the setup that failed, what the agent does, and what moved, caveats included.

We had a bad PR situation. You would put a PR up, drop it in the dev channel on Slack, ping a couple of engineers directly to ask for a review, and maybe add them as reviewers on GitHub so they got a notification. If everyone was busy, nobody looked. So you escalated: bump the thread, say this one is important. The important stuff eventually moved. Everything else fell by the wayside, and some of it sat long enough to develop merge conflicts. Getting your own PR merged meant chasing people and nagging them one by one.

Part of the problem was that the whole team was listed as reviewer on everything. That sounds thorough, but it means the review is nobody's job: someone else will probably get to it, and I am busy right now. That mindset was the blocker.

So on July 3rd I built an agent for it. We run an always-on AWS box with a set of Claude instances on it, a fleet we lean on for a lot of things now: a post-deploy reviewer, a PR reviewer, a handful of others. Rogerio wrote most of them up in [Background Agents on Slack](https://langwatch.ai/blog/background-agents-before-claude-tag). The Hound is not in that post, and it works differently from the pr-reviewer that is. The pr-reviewer reads diffs. The Hound barely looks at the code.

```mermaid
flowchart TD
    PR["A pull request goes up"]
    PR --> CR["CodeRabbit reviews automatically"]
    PR --> CI["CI runs automatically"]
    PR --> SAST["GitHub code scanning checks for security issues, automatically"]
    PR --> TRIGGER["Someone asks pr-reviewer to look at the diff"]
    TRIGGER --> REV["pr-reviewer reads the diff and comments"]
    PR --> HOUND_AM["The Hound's morning sweep: checks readiness, cross-references the linked issue, assigns one owner and one reviewer, posts its brief as a PR comment"]
    HOUND_AM --> HOUND_PM["The Hound's afternoon check: sees what moved, celebrates wins, nudges stalled queues, posts the Slack digest"]
    CR --> HUMAN["The assigned reviewer reads it, using the bots output and the brief"]
    CI --> HUMAN
    SAST --> HUMAN
    REV --> HUMAN
    HOUND_AM --> HUMAN
    HOUND_PM --> HUMAN
    HUMAN --> MERGE["A human clicks merge; nothing merges on its own"]
    classDef bot fill:#eef2fb,stroke:#6b83c9,color:#1f2a44;
    classDef hound fill:#fbf6e9,stroke:#c9a86b,color:#5a4a1f;
    classDef human fill:#eef7ee,stroke:#7ab97a,color:#204a20;
    classDef done fill:#fdeeee,stroke:#c96b6b,color:#5a2020;
    class CR,CI,SAST,REV,TRIGGER bot;
    class HOUND_AM,HOUND_PM hound;
    class HUMAN human;
    class MERGE done;
```

## Every PR becomes exactly one person's problem

Twice a day it walks every open PR. In the morning it does a full sweep: it checks readiness, so a PR with CI failing or unresolved review comments gets marked as needing cleanup instead of assigned; it cross-references the PR's linked issue, pulling over priority labels and adding the `Closes #N` link itself; and it assigns exactly one owner, defaulting to the author, so you always know who is responsible for pushing a thing through, and exactly one human reviewer, so that person owns the review and nobody gets a request that is really addressed to five people.

A review request sent to everyone is a request owned by no one: each person assumes someone else will pick it up, and the PR sits until it grows a merge conflict. As the saying goes, a dog with two owners dies of hunger. Put a single name on the review and it stops being a shared good intention and becomes a task on one person's list.

In the afternoon it checks what has moved since morning and posts a per-person digest in Slack: PRs you own that got cleaned up, reviews still waiting on you, and anything approved that you can go merge. At three in the afternoon it follows up if you have not moved your queue. It runs every day, so new PRs get assigned as they come in, and it keeps working the stack until things move, which is where the name comes from.

![The Hound's afternoon Slack digest: 10 PRs merged since morning, seven ready-to-merge PRs each assigned to one named person, and per-person review queues.](https://langwatch.ai/static/img/pr-hound-slack-digest.webp)

Nothing merges automatically. The Hound surfaces what is approved and a human says go. We have agents that review the code itself, layered above this one. The Hound's whole job is the assignment side, making sure every PR is somebody's problem.

## Six days in, even the March backlog has an owner

One caveat up front: it has been live six days, it went live alongside other agents in the fleet, and the rates below come from just four complete workdays, so read these as what moved in that window while other things were changing too.

Across the three active repos it has touched 87 open and 46 merged PRs. On the main repo, the assignment number is the one I would stand behind: 44 out of 44 hound-checked open PRs have an assignee, against 49 out of 121, about 40%, of the ones it has not reached. On the review side, zero hound-checked PRs have more than one requested reviewer, and a good chunk of the requests it made have already cleared into completed reviews.

Throughput moved too. Human merges went from about 10 a workday in the three weeks before to 18.5 after, roughly 1.85x, with both dependabot and the fleet's own agent account excluded. It swept the existing backlog along with the new work: the oldest hound-checked open PR dates to March 4th, and it sits there labeled and assigned now like everything else. PRs more than two weeks stale merged at a somewhat higher rate after than before, but the counts are small enough that I would not hang anything on it yet.

## The labels get used, and so does the brief

The Hound also tags every PR with how hard the review will be. The main repo right now has 22 `review: targeted`, 20 `review: deep`, 5 `review: fast-skim`, 3 `review: questionable-premise`, and 1 `review: reject-shape`. That label is step one: before you open the PR, you can answer whether you have time for it right now, a quick skim or a real sit-down.

Step two is the brief, a short write-up of why the PR landed in that tier: whether it could break production, whether there are architecture decisions in it worth challenging back to the author. It posts as a comment on the PR itself, which is faster and smoother than pulling it up separately. The other bots read the code line by line. The brief is about the decisions in the PR and how they land on the codebase and on us as a team.

For a while I did not think anybody was really reading the briefs. The labels got used, the brief mostly did not, so far. I checked in with the team this week and that has changed: people told me they do read the brief now, and the Slack digest gets read too, so the tagging matters more than I was giving it credit for.

What is working is the assignment itself: every PR has one name on it, and something checks every single day whether you have moved.

## Where to go next

The Hound is one agent in the always-on fleet we run at LangWatch, alongside the post-deploy reviewer, the pr-reviewer that actually reads diffs, and a handful of others. For the build story on the rest of that fleet, Rogerio covered it in [Background Agents on Slack](https://langwatch.ai/blog/background-agents-before-claude-tag).

## Frequently asked questions

### What does the PR Hound do for PR review assignment?

Every day it goes through all open PRs, assigns each one to a specific person (defaulting to the author), picks exactly one human reviewer per PR, and marks not-ready PRs, CI failing or unresolved comments, as needing cleanup. It posts a per-person digest in Slack every morning and follows up at three in the afternoon if your queue hasn't moved.

### Does the PR Hound merge or review the code itself?

No. Nothing merges automatically; the Hound surfaces what is approved and a human says go. Separate agents review the code. The Hound barely looks at it, and it is a different agent from the pr-reviewer covered in the background-agents post.

### Did it actually change anything?

Six days in, 44 of 44 hound-checked open PRs on the main repo have an assignee, against about 40% of the PRs it has not reached, and human merges went from about 10 a workday to 18.5, roughly 1.85x, with dependabot and the fleet's agent account excluded. Caveat: that is a four-workday rate window and other fleet agents went live at the same time.

### What are the review-effort labels for?

The Hound tags every PR with a review-effort tier (currently on the main repo: 22 targeted, 20 deep, 5 fast-skim, 3 questionable-premise, 1 reject-shape) so you can decide whether you have time for a PR before you open it.

### Why not just list the whole team as reviewers?

That was the old setup, and it meant review was nobody's job: everyone assumed someone else would get to it, and PRs sat long enough to grow merge conflicts. One named reviewer per PR is the fix.