Why I built this
I built SentryLoop to solve a real problem for my own production applications. It investigates my actual logs, and the incidents shown elsewhere on this site are real, not sample data.
When an alert fires, I need to know what broke and why, but digging through traces and codebase history manually takes too long. This agent is a direct solution to that friction: it does the legwork of exploring the codebase and drafting a fix, so I only have to review its work.
How the investigation loop works
Architecture & guardrails
LangGraph & pgvector
LangGraph state machine, not a fixed pipeline — the number of investigation steps varies per incident. Postgres with pgvector stores every past investigation, so the agent checks its own history before starting a new one.
Read-only tools
No tool the agent can call is able to modify, restart, or deploy anything. Every tool is strictly read-only, limited to querying logs, checking metrics, and reading code.
Drafts, not deploys
Every proposed fix is just a draft. It sits behind a human approval step and is never applied automatically. You have the final say on every code change.
What this is (and isn't)
This is a personal showcase of real harness, loop, and context-engineering work. It is not a multi-tenant SaaS product.
There is no account isolation, and anyone who signs in sees the same real data that I do. It's an open window into how I handle my own production incidents, built to demonstrate autonomous investigation capabilities.