Sentinel Action

A GitHub Action that reviews pull requests using specialized AI agents.

Comment

Inspiration

Code reviews are one of the most critical yet most inconsistent parts of modern software development. In fast-moving teams, pull requests are often reviewed under time pressure, and important issues such as security vulnerabilities, unsafe dependencies, or subtle logic regressions can be missed. Existing automated tools tend to focus on static rules or linters, which lack contextual understanding of code changes.

The inspiration behind Sentinel Action was to build an intelligent, context-aware pull request reviewer that behaves more like a human expert than a static tool. We wanted something that could analyze diffs holistically, reason about security risks using up-to-date vulnerability knowledge, comment directly on pull requests, and do all of this automatically.

We also wanted the solution to be practical for real-world use. That meant:

  • No complex setup for users
  • No exposure of sensitive infrastructure details
  • Scalability beyond a single monolithic agent

This led us to combine a GitHub Action for seamless PR integration with a Vultr-hosted multi-agent backend powered by Google’s Agent Development Kit (ADK).

What it does

Sentinel Action is an automated pull request review system that integrates directly into GitHub.

When a pull request is opened or updated:

  1. The GitHub Action collects the PR metadata and file diffs.
  2. It sends the data to a backend hosted on Vultr.
  3. A set of specialized AI agents analyze the changes in parallel.
  4. A synthesis agent produces a structured, actionable review comment.
  5. The action posts the review directly on the pull request.

The system performs multiple types of analysis:

  • Security analysis, including detection of risky patterns and awareness of recent vulnerabilities using live web search.
  • Code review and logic analysis, identifying regressions, unused dependencies, and architectural issues.
  • Style and maintainability review, suggesting naming improvements and documentation gaps.

The final output includes:

  • A concise summary of the PR
  • Clear bullet-point findings
  • Concrete remediation suggestions
  • Optional expandable sections showing detailed agent outputs
  • Clickable citations when external vulnerability references are used

All of this happens automatically with a single line in a GitHub workflow.

How we built it

GitHub Action

The GitHub Action is responsible for:

  • Triggering on pull request events
  • Extracting file diffs and metadata
  • Communicating with the backend
  • Posting review comments back to GitHub

Key design decisions:

  • The action uses GitHub’s built-in GITHUB_TOKEN, so users do not need to create or manage personal access tokens.
  • Infrastructure details such as the backend IP are hidden inside repository secrets.
  • Users only need:

yaml uses: kautilyadevaraj/sentinel-action@v2

  • The action is bundled using @vercel/ncc so it runs as a single compiled file without dependency issues.

Backend on Vultr

The backend is a containerized ADK application deployed on a Vultr VM.

Key components:

  • ADK Python runtime to manage agent orchestration
  • ParallelAgent to execute multiple reviewers concurrently
  • SequentialAgent to merge results deterministically
  • Google Search tool for real-time vulnerability awareness
  • Docker + Docker Compose for reproducible deployment

The backend exposes a minimal HTTP API that:

  • Creates sessions
  • Accepts PR review requests
  • Streams agent results
  • Returns structured responses to the GitHub Action

Vultr was chosen because it provides:

  • Full control over the runtime
  • Predictable networking
  • Simple Docker-based deployment
  • Low latency and low overhead for a hackathon setup

Challenges we ran into

One major challenge was understanding how ADK manages sessions and agent execution. Unlike traditional APIs, ADK requires explicit session creation before interaction, which caused initial confusion and several 404 and session-not-found errors during development.

Another challenge was safely handling large PR diffs and ensuring they conformed to ADK’s strict input schema. This required restructuring how diffs were embedded into prompts rather than passed as arbitrary JSON fields.

On the GitHub side, packaging the action correctly was non-trivial. Missing dependencies, incorrect build paths, and permission issues with GITHUB_TOKEN caused multiple failures before arriving at a stable configuration.

Security was also a concern. Exposing a public backend could easily become unsafe. We addressed this by:

  • Using GitHub’s scoped tokens
  • Avoiding hard-coded secrets
  • Keeping infrastructure details out of user workflows

Accomplishments that we’re proud of

  • Successfully building a multi-agent system where agents operate in parallel and are merged deterministically.
  • Integrating live vulnerability awareness into PR reviews instead of relying on static rules.
  • Deploying a real backend on Vultr, not a mock or local service.

  • Creating a GitHub Action that is:

    • Easy to use
    • Secure by default
    • Publishable to the GitHub Marketplace

  • Producing review comments that are genuinely useful, readable, and actionable.

Most importantly, the system works end-to-end in real repositories.

What we learned

We learned that building reliable developer tooling is as much about infrastructure and ergonomics as it is about AI. Small details like permissions, session lifecycles, and packaging can make or break usability.

We also learned that agent-based architectures are far more powerful when agents are specialized and run in parallel rather than forcing a single model to do everything.

Deploying on Vultr reinforced the importance of containerization and environment parity. Being able to run the exact same Docker setup locally and on the VM eliminated an entire class of deployment bugs.

Finally, we learned how critical clear outputs and good UX are. Even the smartest analysis is useless if it’s not presented in a way developers can act on immediately.

What’s next for Sentinel Action

There are several clear directions for future work:

  • Add language-specific agents for ecosystems like Python, Java, and Go.
  • Introduce policy-based enforcement, where teams can define severity thresholds that block merges.
  • Cache vulnerability research to reduce latency and cost.
  • Add inline PR comments tied to specific lines of code.
  • Support self-hosted backends so teams can run Sentinel entirely within their own infrastructure.

Sentinel Action is designed as a foundation, not a one-off demo. The current system proves that intelligent, agent-driven PR reviews are both feasible and practical.

Built With

Share this project:

Updates