MOKS is an AI-assisted investigation portal for production operations. You ask a question such as "Why is checkout returning 502 errors?" or "Show pods restarting in the last 30 minutes." MOKS collects live evidence from Kubernetes, Prometheus and Loki through typed, read-only tools, then reports what it found.
The report keeps five things apart: observed facts with citations, suspected causes with confidence, missing evidence, next steps and proposed remediation. It is designed never to claim a root cause or a recovery it has not verified.
MOKS is a personal project with no customers, so I have no accuracy, latency or incident-resolution figures to share. The code is on GitHub, and the portal needs an account, with no public sign-up.
It is unrelated to the shopping assistant in RoboShop AI, which happens to share the name.
How an investigation runs
Deterministic code does the first part of the work. Triage, log reading, skill selection and skill steps all run before any model sees the question. A model can then add evidence and write the report. If there is no model, or it fails, rule-based detectors still finish the investigation, and the run says which mode produced its report.
Three sources feed an investigation, and MOKS treats them differently:
| Source | Supplies | Trust |
|---|---|---|
| Tools | What is true now, from live systems | Results are untrusted data |
| Skills | How to investigate, in 51 built-in SKILL.md procedures | Reviewed like code |
| RAG | What the team wrote down, with citations | Untrusted data |
How we implemented RAG and skills in MOKS goes through this in detail, including a traced crash-loop investigation and the gaps that trace exposed.
What it includes
- Investigations as conversations, with progress streamed as structured events.
- Knowledge and skills: Git sync, keyword and hybrid retrieval, and skills that declare read-only tool steps.
- Remediation: allowlisted actions for Deployments, Services and HPAs, run by a separate executor after review, with pre-checks, post-checks and recovery.
- Alerts: investigations triggered by webhooks or a poller, with deduplication and cooldowns.
- Incident records: reports and postmortems.
- FinOps: AWS cost, budgets, Kubernetes allocation and LLM spend.
- Web terminal: a separate gateway with isolated pods. This one is built but has not yet run on a cluster.
Built with
| Layer | Technology |
|---|---|
| Backend | Python 3.12, FastAPI, SQLAlchemy, Alembic, LangGraph, langchain-core |
| Frontend | React 19, TypeScript, Vite |
| Data | PostgreSQL, with pgvector, OpenSearch or Pinecone as optional vector backends |
| Models | OpenAI-compatible APIs, Gemini, Amazon Bedrock, Ollama, and a rule-based fallback |
| Delivery | One image, a Helm chart and Argo CD |
| Observability | Prometheus metrics, JSON logs, OpenTelemetry traces, a Grafana dashboard |
Security model
Access runs through five roles: viewer, investigator, operator, approver and admin. Authentication is OIDC or local accounts, and audit records are hash-chained. Every tool call goes through one executor that applies policy, and writes run in a process of their own.
Some limits matter. All users of a Kubernetes connector share one ServiceAccount, so isolation between them depends on MOKS's own permission checks. Redaction works from patterns and cannot recognise every secret. Audit records are tamper-evident, not tamper-proof, against a database superuser.
Current status
The repository keeps a blunt status document, and this table summarises it as of 1 November 2026. Much of it is built and tested, while much less has been proven against real systems.
| Area | State |
|---|---|
| Deployment | Running on Amazon EKS: API, worker and executor |
| Portal, Kubernetes, Prometheus and Loki investigations | Verified live, on the earlier Minikube cluster |
| Git sync and keyword retrieval | Verified live |
| Hybrid and vector retrieval | Not verified end to end |
| Chat model answering a live request | Not yet, per the status document |
| Remediation execution | Tested with fakes. No plan has run against a real API server |
| Alert-triggered investigations | Tested with fakes |
| Web terminal | Image never built, and never run on a cluster |
| Database backups | Not yet run on a cluster |
Discussion comments
No comments yet. Start the discussion.