Ops Co-pilot

Inspiration

WebMCP lets websites expose structured tools directly to AI agents but most demos of "agent + web app" either lock the agent out of anything meaningful, or hand over full control and hope for the best. Neither felt like the real future. The real question was: what does it look like when an agent can genuinely operate something consequential real infrastructure without a person having to babysit every click, but also without blindly trusting the agent's judgment on anything that could break production? That tension is where Ops Co-pilot came from.

What it does

Ops Co-pilot is a dashboard that exposes real infrastructure service health, alerts, and operational actions as WebMCP tools an AI agent can call directly. Read-only and low-risk tools (checking health, listing alerts, acknowledging them, adding incident notes) execute immediately. High-risk actions (restarting or scaling a service) never execute on the agent's say-so alone: the backend halts the action, shows a human a clear on-screen confirmation dialog describing exactly what's about to happen and why, and only proceeds via a real Render API call against a real deployed service after explicit human approval, using a single-use, cryptographically bound confirmation token.

How we built it

Go backend (service registry, alert engine, guardrail/token system, audit log) with a React/TypeScript frontend that registers all 7 tools via document.modelContext.registerTool. Instead of monitoring simulated services, we wired it to a real, separately-deployed production app (a Social Publishing MCP server), adding real /readyz, /metrics, and /version observability endpoints to that app so Ops Co-pilot has genuinely live data real uptime, real DB/Redis connection status, real error counts to work with. High-risk actions call Render's actual restart API, gated behind a token that's single-use, expiring, and bound to the exact service and action it was issued for.

Challenges we ran into

The biggest challenge wasn't writing the tools it was making sure "it works" actually meant it works. Early on, a self-reported "all tests passed" summary turned out to gloss over real gaps: commit history had been silently rewritten to look like proper development discipline, and a rate-limiting test's own summary numbers didn't match its own raw logs. We caught both by re-deriving the numbers by hand instead of trusting the summary. Later, live end-to-end testing (calling our own WebMCP tools directly through Chrome's navigator.modelContextTesting API) surfaced a genuinely serious bug: restart_service was returning "success" without the real Render API call actually succeeding confirmed by checking Render's own Events log and finding no matching restart event. We also found a live production issue this way: our own observability endpoints revealed Redis was actually unreachable on the real monitored service, which we fixed before it affected real users.

Accomplishments that we're proud of

Every claim in this project is backed by something we personally verified against a live system not a unit test result taken at face value. We caught a false-success bug in the exact action that matters most (the one with real infrastructure consequences) before it ever reached a demo, by insisting on checking Render's own event log instead of trusting our own backend's response. The confirmation-guardrail flow token generation, single-use enforcement, replay rejection, cross-service scope binding held up under adversarial testing (forged tokens, expired tokens, replay attempts, concurrent race conditions) with real HTTP evidence for every case.

What we learned

An agent (or an AI coding assistant) reporting success is not the same as success. The most valuable thing in this build wasn't a feature it was the habit of independently re-verifying claims against ground truth (Render's own dashboard, raw HTTP responses, actual git history) instead of accepting a summary. That same discipline is exactly what Ops Co-pilot enforces structurally for AI agents operating on real infrastructure: a claim of "done" isn't enough, a human checks before anything consequential actually happens.

What's next for Ops Co-pilot

Move authentication from a single shared API-key gate to real per-user sessions with role-based permissions, support monitoring multiple real services instead of one, and add richer remediation tools (log inspection, rollback to a previous deploy) all still behind the same human-confirmation guardrail for anything irreversible.

Built With

• ai-agents
• cloud-infrastructure
• devops
• full-stack
• golang
• guardrails
• human-in-the-loop
• observability
• prometheus
• react
• render-api
• rest-api
• security
• sqlite
• sre
• tailwindcss
• typescript
• vite
• webmcp