LoopGuard

• 

Inspiration

Modern websites break in ways that small teams often don’t catch fast enough. A bad deploy, missing checkout content, rising latency, or dependency failure can quietly cost real users and revenue before anyone notices. Most monitoring tools stop at alerting a human. We wanted to build something more useful: an autonomous on-call agent that not only detects incidents, but also investigates them, takes safe actions, verifies whether they worked, and escalates only when a human is truly needed.

We were especially inspired by the gap between “AI can reason” and “production systems need guardrails.” LoopGuard is our answer to that: LLM proposes, policy disposes.

What it does

LoopGuard is an autonomous on-call agent for websites.

It monitors a live website, detects regressions, investigates likely causes, proposes the next action, checks whether that action is allowed by policy, executes safe responses, verifies recovery, and escalates if the action is too risky or fails.

In our demo, LoopGuard can:

• monitor a healthy site
• detect a real broken deployment
• collect evidence from the broken site
• attempt a recovery action
• recognize when restart does not solve the issue
• replan and roll back
• verify that service was actually restored
• deny dangerous actions like deploy_code
• publish or route monitoring signals through Nexla
• surface the full incident timeline in a dashboard

The key idea is that LoopGuard does not assume success just because a tool call returned successfully. It checks the resulting website state before declaring the incident resolved.

How we built it

We split the project into two major pieces.

The first piece is the monitored world: a deterministic but real incident target system. We built a website service with healthy and broken deployment modes, deployment history, operational endpoints, and stable health/metrics APIs. The broken state is visible on the actual request path, not just in synthetic JSON. We also wired this service to publish live events into Nexla so the monitoring story is based on a real sponsor-backed signal path.

The second piece is LoopGuard itself: the agent, policy engine, adapters, and dashboard. We built an incident state machine that moves through monitoring, detection, investigation, planning, authorization, action, verification, replanning, resolution, and escalation. We integrated policy enforcement so risky actions can be denied even if proposed. We also built a frontend dashboard to make the full response loop visible and understandable.

Our architecture centers on:

• a monitored website with real incident behavior
• an agent loop with deterministic fallback logic
• policy-based authorization
• live event publishing to Nexla
• a UI that shows state, reasoning context, actions, and timeline

Challenges we ran into

One major challenge was avoiding a fake-feeling demo. It is easy to simulate incidents by toggling flags, but much harder to make the failure visible on the real request path, keep the system deterministic, and still preserve a stable contract for the agent.

Another challenge was state consistency across the whole system. The website, incident history, metrics, frontend, and agent loop all needed to agree on what had happened. Even small mismatches in timestamps, deployment history shape, or reset behavior created confusing bugs.

We also ran into the classic agent problem: autonomy is impressive only if it is safe. We had to make sure LoopGuard could act usefully without overreaching. That meant building a strong policy boundary and making escalation a first-class feature, not a fallback afterthought.

Finally, sponsor integration had its own learning curve. We wanted the sponsor tools to have real jobs in the product, not just logos on a slide, so we focused on making Nexla part of the actual monitoring flow.

Accomplishments that we're proud of

We’re proud that LoopGuard is not just a chatbot wrapped around a dashboard. It behaves like an actual on-call system.

We’re especially proud of:

• building a website target where incidents are real and repeatable
• preserving a stable API contract while improving truthfulness
• making rollback verification based on observed recovery, not assumed success
• wiring live Nexla event publishing into the Person 1 service
• creating a policy-aware agent flow that can deny dangerous actions
• showing the full incident lifecycle in a way that is easy to demo and understand

The project feels like a real product direction, not just a one-off hack.

What we learned

We learned that “agentic” systems become much more compelling when the world they operate in is truthful. Real breakage, real verification, and real policy checks matter more than fancy language if you want people to trust the result.

We also learned that the boundary between reasoning and authorization is everything. Letting the model propose actions is powerful, but letting deterministic policy decide what is actually allowed makes the system much safer and more credible.

On the engineering side, we learned how important deterministic demos are. Reproducibility, reset behavior, consistent deployment history, and stable interfaces made collaboration between the website and agent sides much easier.

What’s next for LoopGuard

Next, we want to complete the full sponsor-powered loop:

• consume monitoring signals directly from Nexla as the primary source
• move authorization fully into the request path with Pomerium
• integrate real external tools for screenshots, notifications, and verification
• add independent uptime probing so recovery is verified externally
• support continuous autopilot mode instead of button-triggered cycles
• track budget, cooldowns, and dry-run mode for safer autonomous operation
• deploy the service in a more production-like environment

Long term, we see LoopGuard becoming an AI-native incident response layer for small teams: something between monitoring, runbooks, and on-call automation, with real guardrails built in.

Built With

• nextjs