OpsPilot

The problem worth solving

An alert fires at three in the morning and says a pod is restarting. What the responder actually needs is the next twenty minutes of work compressed: which deployment, what changed recently, what the logs said before it died, whether anything else is failing with it, and which of the plausible causes the evidence supports.

That work is mechanical for the first fifteen minutes and judgement-based after that. The mechanical part is a good target for an agent: it is bounded, the data sources are APIs, and being wrong is cheap as long as a human decides what to do next.

Scope, and what I cut from it

The version worth building is narrow. An alert arrives by webhook, the agent gathers live evidence — deployment and pod state, recent events, container logs, the firing metric and its neighbours — and produces a written root-cause assessment with a proposed remediation. It exposes the same capability as an MCP server, so the investigation can also be driven conversationally from a terminal rather than only by an alert.

Two things that belong in an impressive-sounding description are deliberately out of the first version. Retrieval over past incidents is the obvious one, and it is the part most likely to consume the whole project while producing a corpus too small to retrieve usefully — it needs a year of incidents before it earns its place. The other is having the agent open a merge request with a fix. Writing to the delivery pipeline is a different risk class entirely, and it should not be the second feature of a tool whose first feature is still unproven.

• Read-only credentials, enforced by the cluster's own access control rather than by the agent's good intentions.
• Every remediation is a proposal a human applies — the agent never acts on the cluster.
• Investigation output is evidence-linked, so a wrong conclusion is auditable rather than merely wrong.

Why it is honest to list it unbuilt

An earlier version of this site described OpsPilot as though it existed, with a stack and a feature list. It did not, and presenting a design as a shipped system is the kind of thing that survives a portfolio and fails an interview.

So it stays, marked for what it is. The scoping above is the actual work product: choosing read-only over autonomous, cutting retrieval until there is data to retrieve, and refusing to let the agent write to the pipeline before it has earned trust on reading from the cluster.