Code Review Stopped Living Outside AGX

The awkward thing about code review in AGX was not that GitHub existed.

Of course GitHub existed.

The awkward thing was that AGX still treated pull requests like URLs.

You could do the planning work in AGX. You could do the task work in AGX. You could look at tracker context in AGX. Then the moment a branch turned into something reviewable, the center of gravity jumped somewhere else. A PR became a browser tab, a pasted link, or a thing you vaguely remembered to go check after finishing the “real” work.

That split was getting harder to defend.

Over the last few days, AGX shipped a dense GitHub pass: a dedicated /prs review surface, linked pull requests on ticket detail, stable task identifiers for PR linking, a repo picker after OAuth, and an important structural change that moved GitHub into the same connect flow as Linear and Jira.

The headline is not “AGX added GitHub.”

The headline is that code review stopped living outside the workspace.

The old shape was telling the wrong story

One of the most revealing details in this week’s work is what got deleted.

AGX had a standalone GitHub settings page. That sounds harmless, but it quietly encoded the wrong product model. It said GitHub was a peripheral integration. Something you configured off to the side. Something adjacent to the work, not part of the work.

That is fine if all you want is a credential screen.

It is not fine if the actual workflow is:

1. track a task
2. open or find the PR for that task
3. understand review state
4. decide what to do next
5. continue the conversation from there

That is not “settings.” That is the job.

The repo design doc makes the intended move explicit. The goal was not just to cache PR metadata. The goal was to link pull requests to AGX tasks and tracker issues, give PRs their own two-panel review surface, and make that linkage tracker-agnostic from day one.

That matters because it changes the ownership boundary.

GitHub is no longer just where the code happens to be hosted. It is part of the operating surface where AGX decides what work is open, what is blocked, and what needs follow-up.

GitHub joined at the right layer

The cleanest product move this week was putting GitHub in the tracker picker instead of leaving it stranded behind a special settings route.

The connect page now literally treats it as a first-class sibling:

const TRACKER_TYPES = [
  { type: "linear", label: "Linear" },
  { type: "jira", label: "Jira Cloud" },
  { type: "github", label: "GitHub" },
] as const;

It does not mean AGX is pretending GitHub is an issue tracker. The adapter code is blunt about that. GitHub joins the same connection flow, but its issue-board methods intentionally return empty or throw. Post-connect, the UI swaps in repo management instead of trying to fake a board.

GitHub belongs in the same setup flow because it participates in the same working loop. But AGX does not need to lie and say a pull request is the same thing as a ticket just to get that ergonomic win.

This is one of those design choices that saves a lot of future drift. The connection model is shared. The runtime meaning is still specific.

Pull requests needed human identifiers, not database secrets

The next problem was linkage.

If you want a PR to resolve back to real work, you need a durable public identifier. Not a hidden UUID. Not a row ID from SQLite. Something a person will actually put in a branch name or a title.

So this week AGX added stable task identifiers and wired the resolver to look for them in the places people naturally put them: branch names first, then titles, then bodies.

The resolver pattern is simple:

export const ID_PATTERN = /(?<![A-Za-z0-9])[A-Z]+-\d+(?![A-Za-z0-9])/;

That one line tells you a lot about the intended workflow.

AGX is no longer waiting for someone to manually stitch together “this PR probably belongs to that task.” It can extract something like AGX-12 or TSK-42, resolve it against the task store, and create a link that survives outside one person’s memory.

That may sound like implementation detail, but it changes how the product feels. A task is no longer just a place where work starts. It becomes the thing review can reliably come back to.

Review is becoming a workspace, not a tab

The part users will feel immediately is the new PR surface itself.

AGX now has a dedicated /prs page with quick filters like All, My PRs, and Awaiting my review, plus a repo filter over attached repositories. Ticket detail views can show a compact “Pull Requests” section with linked rows that carry state, CI signal, and review decision instead of forcing you to go spelunking.

That alone would already be useful. But the more interesting cut is on the right-hand side of the PR detail.

The PR detail panel is not just metadata. It has its own ongoing conversation scope.

The composer code creates a deterministic thread ID from the PR identity itself and injects PR context into the first message:

const prContextPrefix = firstSendRef.current
  ? `Regarding PR ${pr.repoId}#${pr.number} (${pr.title}). URL: ${pr.url}\n\n`
  : "";

That is the moment the feature stopped looking like “some GitHub screens” and started looking like a real workflow change.

A pull request is now something AGX can keep context around.

Not just display. Not just link out to. Not just summarize once and forget.

Keep context around.

That is a big distinction.

It means a review conversation can belong to the PR instead of being awkwardly shoved into the task that spawned it or disappearing into browser history. It means reopening the same PR brings you back to the same thread instead of starting from scratch.

That is what “native” means here.

The repo picker is more important than it sounds

The most modest-looking change this week might be the most practical one.

After GitHub auth, AGX now asks which repositories you actually want to track.

That is a better default than “give me your whole account and we’ll figure it out later.”

It fits the rest of the local-first model too. AGX does not need universal GitHub awareness. It needs the right repos attached to the right project so it can sync pull requests, comments, and review state where they matter.

That creates a much sharper boundary:

• connect GitHub once
• select the repos that belong in this workspace
• sync those repos
• filter PRs over that explicit set

The repo manager in the tracker setup pane reinforces the same point. Attached repositories are visible. Removable. Syncable. Named.

Nothing ambient. Nothing magical. Nothing “it probably knows what you meant.”

That kind of explicit scope is boring in the best possible way.

What this changes from the inside

The deeper story here is not that AGX wants to clone GitHub.

In fact, the design doc is smart about what it is not trying to do yet. No inline diff viewer. No giant unified inbox. No pretending every tracker concept collapses into one generic blob.

That restraint is the right move.

AGX does not need to replace GitHub to make review work feel local.

It only needs to own the parts that were previously falling through the cracks:

• how a PR attaches to real work
• how review state shows up next to tasks
• how repo scope is configured
• how a review conversation persists
• how the next action gets decided without leaving the workspace

That is enough to change the feel of the product.

Before this week, code review in AGX was something you navigated away from the workspace to do.

After this week, it is starting to look like just another place the workspace already understands.

That is a much more truthful model of how software work actually happens.

What’s next

I think this is one of those changes that will matter more over the next two weeks than it does in a single screenshot.

Once pull requests have stable links, scoped sessions, and an actual home in the product, a lot of follow-up work gets simpler: better recap generation, stronger review-state summaries, tighter task-to-PR transitions, cleaner “what should I do next?” prompts, and less context loss between implementation and review.

The important part is that the boundary is finally in the right place.

Tasks are not the whole story. GitHub tabs are not a sufficient story.

The work loop includes both.

AGX is starting to admit that in the product surface, and the product is better for it.