SlothOps Engine
- Role
- Lead — engine, agents, dashboard
- Period
- Mar — May 2026
- Stack
- Python 3.13, FastAPI, PostgreSQL 16, React 18, Docker, Sentry API
The problem
The gap between a production exception and a merged fix is mostly waiting. Someone has to notice the Sentry alert, find the source, understand it, write a patch, and get it reviewed — and the first three steps are mechanical.
What I did
Built a closed loop that turns live crashes into reviewed pull requests. It fingerprints and deduplicates the incoming issue, pulls the exact source from GitHub, generates a targeted fix through a configurable provider chain, and opens a PR with its reasoning attached.
What happened
Six QA agents run against every fix PR before a human sees it — static analysis, functionality, regression, performance, stress and VAPT. Failed deploys trigger a governed rollback that is auto or approval-gated depending on policy, and an operator dashboard shows every issue, PR, report and rollback event live.
Human oversight is a policy, not a prompt
The easy version of this ships fixes straight to main and calls it autonomy. That is not something anyone would run against a production system.
The rollback path was the part that needed the most care. Planning a rollback and executing one are separate operations with separate permissions, because the failure mode of getting this wrong is worse than the crash it was responding to.
Why six agents rather than one
A single reviewing model marks its own homework. Splitting review into six narrow agents with different objectives means a fix that passes functionality can still fail regression or stress, and each verdict is legible on its own.