The issue tracker is where a project's first impression lives, and an untriaged tracker reads as neglect. New issues arrive with no labels, half of them missing the version or the steps to reproduce, some of them duplicates of last week's report. A maintainer has to read each one, label it, ask for what is missing, and spot the repeats. It is mechanical, constant, and the first thing to slip when there is real work to do.

An issue-labeling agent does that mechanical pass the moment an issue opens. It labels by type and area, asks for missing reproduction details, surfaces likely duplicates, and flags issues that have gone stale. It never closes an issue or sets a priority on its own, because those are judgment calls a maintainer owns.

What this agent does

On every issue open and edit, the agent reads the title, body, and any issue-form fields, applies type and area labels, checks for missing required information, compares against recent issues for duplicates, and keeps a stale queue updated. Each action is logged with its reason, so a maintainer can see why an issue got the labels it did.

It does not close, lock, assign priority, or edit the reporter's words. Those limits keep the tracker trustworthy. For the general principle behind read-and-suggest agents, see what an AI agent can actually do and how to limit agent actions.

Issue labeling vs PR triage

These two agents share a philosophy and read completely different signals.

Run both on the same repo and each handles its own inbox. The triage discipline is identical; the inputs are not. The same prose-to-label reasoning powers Jira issue grooming.

Labels it applies

Labels the agent can defend with evidence are safe; labels that require taste are not.

An agent that assigns priority by itself produces a queue maintainers quietly ignore, which defeats the point. Keep its labels objective and the triage stays trustworthy. This mirrors the support-side discipline in Zendesk ticket triage.

Duplicate detection

Duplicates are the noise that buries signal in a busy tracker, but they are also where an over-eager agent does the most harm. So the agent suggests and never closes. It compares a new issue against recent and open ones, and when it finds a strong match, it posts a comment linking the candidates: "This looks related to #1421, can a maintainer confirm?"

A maintainer decides whether it is truly a duplicate, because near-identical symptoms regularly trace back to different causes. Auto-closing on a suspected duplicate loses real reports and annoys contributors, which is exactly the goodwill an open-source project cannot spare.

Missing reproduction info

A bug report without a version, steps, or expected behavior cannot be acted on, and chasing that information by hand is tedious. The agent reads the issue form, notices the blank required fields, and posts a friendly request for the specifics, then applies a needs-info label. When the reporter fills the gap, the label clears automatically.

If the issue stays incomplete past a defined window, it joins a stale queue with the history attached. The agent flags it; a maintainer decides whether to close, ping again, or keep it open. The graduated stale handling here is the same shape as the PR-side approach: comment, wait, flag, and leave the final call to a human. For turning a sprint's worth of issues into a digest, the Linear sprint summary pattern composes nicely with this one.

Common mistakes

Frequently asked questions

Is issue labeling the same as PR triage?

No. PR triage routes code changes: area labels from changed paths, reviewers from CODEOWNERS, diff summaries. Issue labeling routes reports and requests: type (bug, feature, question), area from the text, severity hints, and missing-information prompts. The signals are different because an issue has no diff to read. Teams often run both agents on the same repo.

Which labels should an agent apply to issues automatically?

Objective ones: type (bug, feature, docs, question), area inferred from the text and any issue-form fields, and a needs-info flag when a required field is blank. Subjective labels like priority or good-first-issue should wait for a human signal. An agent assigning priority by itself produces a triage queue nobody trusts.

Can the agent detect duplicate issues?

It can surface likely duplicates by comparing the new issue against recent and open ones, then post a comment linking the candidates for a maintainer to confirm. It does not auto-close on a suspected duplicate, because near-identical symptoms can have different causes. Suggesting a duplicate is helpful; closing the wrong one loses a real report.

How does the agent handle issues missing a reproduction?

When an issue form leaves required fields like version, steps, or expected behavior empty, the agent posts a friendly comment asking for the specifics and applies a needs-info label. If the reporter fills the gap, the label clears. If the issue stays incomplete past a window, it joins a stale queue for a maintainer to decide on, not an auto-close.

What should the agent never do with issues?

Auto-close issues, assign priority without a human signal, edit the reporter's text, or lock conversations. Safe actions are labeling, requesting missing information, suggesting duplicates, and flagging stale items. Anything that ends a conversation or makes a roadmap call belongs to a maintainer, with the agent doing the legwork up to that line.

Three takeaways before you close this tab

Sources