kubernetes/kubernetes

When you pick an open issue on kubernetes/kubernetes, Operate starts with the issue itself: the title, the description, the reproduction steps, any stack traces or log excerpts pasted by the reporter, and the discussion that followed. Those details become the starting evidence. From there the agents search the kubernetes codebase for the functions, modules, and configuration that the report points at, rather than guessing from the issue text alone.

Next, Operate looks at how that code got to its current state. It walks the git history and blame for the suspect files, so a regression introduced by a recent commit can be told apart from a long-standing limitation. A good root cause analysis answers three questions: what is failing, why it fails, and when the behaviour started. Git history is often the fastest way to answer the third question.

Each hypothesis is then checked by a separate Verification agent running on a second model. If the evidence does not support the claimed cause, the investigation says so instead of presenting a confident guess. The aim is an explanation a kubernetes maintainer can confirm in minutes by following the cited files and line numbers.

A finished investigation links to the specific files and lines most likely responsible, summarises the reasoning that connects the reported symptom to that code, and notes how confident the agents are. Where it makes sense, the Resolution agent drafts a suggested fix as a patch. Operate never commits, opens pull requests, or pushes anything to kubernetes/kubernetes. Results are published on this site so people can judge them.

Maintainers can use an investigation to triage faster, deciding whether an issue is a real bug, a configuration problem, or a duplicate. Contributors can use it as a map of where to start reading before writing a fix. Reporters can use it to add the missing detail that makes an issue actionable.

Treat every investigation as a well-argued lead, not a verdict. Start with the cited code and check that it does what the analysis says. Then compare the suggested trigger with the reproduction steps in the issue. If both line up, the analysis has probably found the cause. If they don't, the evidence section usually shows where the reasoning went wrong. That is useful too, because it rules out one explanation.

Issues that depend on a specific environment, such as an operating system version, a hardware quirk, or a third-party service, are harder to diagnose from code alone. In those cases, Operate says what it could not verify instead of filling the gap.

Operate is a self-hosted AI platform that teams run inside their own infrastructure to investigate production issues. Its production adapters are read-only, and an engineer reviews and applies any proposed change. Running the same pipeline in public on projects like kubernetes/kubernetes shows how it reasons on real code that anyone can inspect. It also gives back something useful to the maintainers whose work much of the industry depends on.