Loading Austin Makasare's portfolio
← Back to work
AI AGENTS · GITHUB APP · 2026 · IN PROGRESS

PR SENTINEL

// PROJECT

PR SENTINEL

An AI pull-request reviewer that runs as a GitHub App. When a pull request opens, a verified webhook queues the review; an orchestrator plans it, runs specialised agents in parallel waves, filters their findings, and posts a structured review with line comments back to the PR.

It's two applications: an Express + BullMQ backend that does the reviewing, and a Next.js 16 dashboard that streams every run live — each agent, its tool calls, and its findings. The work is in progress and documented as it goes, in a running decision log in the repository.

Node.jsTypeScriptExpressBullMQRedisPostgreSQLPrismaNext.jsReactVercel AI SDKOpenRouterTailwind CSS
// THE CHALLENGE

REVIEWS THAT HOLD UP.

An AI reviewer is easy to demo and hard to trust. It has to read real context without burning the GitHub API budget, survive restarts mid-review, and avoid confidently reporting things that aren't there.

BUDGET
A GitHub App installation shares one rate limit across every repository and every concurrent review. Agents that each fetch the same comments, diffs and files independently would exhaust it fast.
RESILIENCE
A review takes minutes and many model and API calls. A worker restart or a rate-limit pause must resume the review, not start it over — and must never look like a silent failure.
TRUST
Findings are only useful if they're right. A false positive costs a developer's attention; a run where every agent failed must never be reported as a clean pass.
// ARCHITECTURE

WEBHOOK TO REVIEW.

Event-driven and decoupled: the webhook only verifies and enqueues; a worker owns the review from there, checkpointing every step.

THE PIPELINE
GitHub webhook → signature verification → BullMQ queue → worker → review orchestrator → PR understanding → planner → wave one → wave two → deduplication against earlier commits → reflection → review writer → GitHub review with line comments. Findings and per-agent executions are persisted to PostgreSQL; the dashboard reads them over REST and a live stream.
AGENT WAVES
A PR-understanding agent establishes intent, scope and risk; a planner schedules the specialists. Wave one — security, architecture, reliability — runs in parallel; wave two — testing, code quality, requirements — follows. A reflection agent then audits every finding for false positives before the writer posts.
PERMISSION-SCOPED TOOLS
Agents gather evidence through a tool registry of 12 tools — file contents, diffs, commits, dependency manifests, directory trees, file history, linked issues, CI status — each agent granted only the tools its role needs, inside a tool loop capped at eight steps.
THREE-TIER MEMORY
Run memory checkpoints each review step to Redis for instant recovery; cross-commit memory tracks findings as open, resolved or reopened across pushes; repository memory stores the detected stack and project-specific engineering rules.
// ENGINEERING DECISIONS

WHAT I BUILT.

01

Never fetch what an agent already has

SHIPPED
PROBLEM

Six agents were each allowed to read the same PR comments and reviews, so a single review could make a dozen near-identical GitHub calls before it had read a single file.

APPROACH

Immutable git data — files, diffs, trees, history — cached by commit SHA and fetched once, ever. Mutable PR data served from tables kept in sync by webhooks. Code search deliberately stays live, because GitHub's search index moves.

OUTCOME

Up to 12× fewer GitHub calls per review. Cache hits are byte-identical to a live call, so review quality isn't traded for budget.

02

Pause and resume instead of finding the ceiling in production

SHIPPED
PROBLEM

Even with caching, a busy installation could run its shared GitHub budget down in the middle of a review.

APPROACH

A Redis-backed budget tracker fed from GitHub's own rate-limit headers. Below a soft floor no new wave starts — the review checkpoints and re-enqueues itself as a delayed job timed to the reset. Below a hard floor, tool calls fail with a structured error the agents already handle.

OUTCOME

The dashboard shows 'paused — resuming in ~12m' instead of a review that looks stuck or failed.

03

A rate-limit floor that could deadlock a review

SHIPPED
PROBLEM

Found in end-to-end testing: a review paused and re-paused forever with 90% of its budget left. A hard-coded minimum floor of 50 was larger than a rate-limit category whose entire limit was 10.

APPROACH

Floors became pure ratios of the reported limit, and the rate-limit category is now logged so the next surprisingly small limit is diagnosable.

OUTCOME

Reviews progress under every rate-limit category GitHub reports, not just the default one.

04

One revoked token took down the whole server

SHIPPED
PROBLEM

Express 4 doesn't forward rejected promises from async route handlers, so a single expired or revoked GitHub OAuth token crashed the entire process.

APPROACH

An async-handler wrapper on every route that lacked error handling, plus a specific 401 that tells the user to sign in again.

OUTCOME

One bad request now fails one request.

05

A circuit breaker — and a dashboard that stopped lying

SHIPPED
PROBLEM

When the model provider degraded, seven agents each burned three retries back to back; and a run where every agent failed was shown as a 'confirmed clean pass'.

APPROACH

A process-wide circuit breaker that opens for 60 seconds after three consecutive full failures. The dashboard's empty state now checks agent executions, not just the number of findings.

OUTCOME

No retry storms during outages, and an inconclusive review is reported as inconclusive.

// RESULTS

WHERE IT STANDS.

11
SPECIALISED AGENTS
12
PERMISSION-SCOPED TOOLS
12×
FEWER GITHUB CALLS / REVIEW
7 → 68
TESTS

Webhooks are verified with HMAC and stored tokens are encrypted with AES-256-GCM. The review pipeline, tool registry, memory layers and live dashboard are working end to end; development continues in the open, with every architectural and product decision written down as it's made.