Amaze! Amaze! Amaze! Team Aaroh built an autonomous multi-subagent gatekeeper for safer software releases at the IBM Bob 2.0 Hackathon - 2026.
Team Aaroh · IBM Bob 2.0 Hackathon · September 25–27, 2026
Project Links
Live Application:
https://51.20.84.88.sslip.io
GitHub Repository:
https://github.com/gitinitgit/Release-Readiness-Agent
IBM Bob 2.0 Hackathon:
https://lablab.ai/ai-hackathons/ibm-bob-2-hackathon/dash
The Problem: Deployment Fear
You’re about to release your code to production, and you start wondering:
“What if something goes wrong?”
Even when all the tests pass, a release can still have hidden problems that cause production issues..
Your unit tests pass.
Your CI pipeline is green.
Everything looks fine.
And yet, thirty minutes later, production goes down.
Why?
Because traditional CI/CD pipelines are primarily designed to test code logic. They don't necessarily audit the overall release safety of a deployment.
A release can pass every unit test and still contain problems such as:
- A migration script containing a destructive
DROP TABLEorDROP COLUMN. - A missing production environment variable.
- An accidental test Stripe key such as
sk_test_...committed into.env.prod. - A newly updated dependency containing a high-severity Remote Code Execution vulnerability.
- Commits that don't contain required ticket IDs or governance approvals.
When the IBM Bob 2.0 Hackathon kicked off on LabLab.ai with a 48-hour build window, our team, Aaroh, decided not to build another generic AI chatbot.
Instead, we wanted to build something that could answer a much more practical question:
Is this release actually safe to ship?
And if the answer was no:
What should we do to recover?
That idea became the Release Readiness Agent, powered by five specialized autonomous subagents.
What We Built
We built Rocky 🤖 to find common vulnerabilities and release issues before deployment.
It checks everything in one place, helping catch problems before they reach production.
Deploying the Agent to AWS
We didn't want the project to exist only as a local demo.
So we deployed the application to an AWS EC2 instance so that judges and other users could interact with it.
The stack was containerized using Docker Compose.
The architecture included:
Browser
↓
Caddy
↓
Web Application
↓
Node.js / TypeScript Backend
↓
Release Analysis Agents
We also used Caddy for HTTPS and automatic certificate management.
The result was a live application where users could upload files or audit mock repositories directly through the browser.
What We Learned
Building the project in a 48-hour hackathon taught us several important lessons.
1. Deterministic Rules Matter
Not every part of a release-safety system should depend on an LLM.
For mission-critical checks, deterministic analysis can be much easier to reason about.
For example, destructive SQL operations can be detected through parsing and explicit rules.
AI can then be used where it adds more value, such as:
- Summarizing findings
- Explaining risks
- Generating recommendations
- Producing human-readable reports
The combination is more useful than relying exclusively on either approach.
2. Parallelism Makes a Big Difference
Our five specialized checks can run independently.
Instead of:
Migration → Config → CVE → Policy → Changelog
we can run them more like:
Migration ──────┐
Config ─────────┤
CVE ────────────┤
Policy ─────────┤ → Final Report
Changelog ──────┘
This helped keep the analysis fast enough to potentially run as part of a Git push or pull-request workflow.
Future Development
The project is open for anyone who wants to fork it, improve it, or take the idea further.
CI/CD Integration
The agent could automatically run whenever a pull request is opened or a deployment is triggered.
More Security Checks
Better Rollback Automation
Historical Release Analysis
Conclusion
Rocky, if you are reading this:
You are my friend. 👋
Built with ❤️ by Team Aaroh.
Top comments (0)