One agent. Any question. Evidence-backed answers.
Stop searching dashboards. Ask "why is Tomcat slow?" or "is there anything wrong with this server?" in plain language. A lightweight, read-only agent collects real evidence through a closed set of approved diagnostics, secrets get redacted before anything reaches an LLM, and you get a structured finding back: severity, confidence, evidence, timeline, and a recommendation, never a guess dressed up as a fact.
An investigation engine, not another dashboard
You shouldn't need to know which metric, which log file, or which process to check. You ask the question. Inspector figures out where to look, gathers the evidence itself through a locked-down agent, and hands you a conclusion you can actually check the reasoning behind.
Ask in plain language
"Why is this server slow?" "Did the deployment cause this?" "Find unusual errors in the logs." No query language, no dashboard to learn, no metric name to remember.
The agent can't go rogue
The agent's entire remote-triggerable surface is a fixed, named dispatch table of read-only collector functions. There is no code path from "the control plane says run X" to a shell.
Secrets never reach the model
Every piece of evidence, metrics, process lists, log lines, passes through a redaction pass before it's stored or sent to any LLM. Credentials, API keys, and tokens get scrubbed first.
Real multi-tenant RBAC
Organization → Project → Environment → Agent, isolated by default. Org roles, project roles, and per-agent roles decide exactly who can inspect what, enforced on every single tool call.
Bring your own LLM, or none at all
Anthropic natively, or any OpenAI-compatible endpoint, Ollama, vLLM, LM Studio, a custom gateway. No provider configured yet? Evidence still collects and displays honestly instead of a fabricated finding.
Own your infrastructure, own your data
Self-hosted with Docker Compose, backed by Postgres you control, no public signup. Every organization is provisioned by a platform admin, not a signup form.
Every incident starts with the same question: where do I even look?
None of these are exotic edge cases. They happen every time something breaks at 2am.
You don't know which dashboard to check first
CPU, memory, JVM heap, connection pools, upstream latency, a dozen tabs open, and the actual cause is in none of them until you've checked all of them.
Logs are a haystack, not an answer
Millions of lines, no way to know which pattern actually matters. By the time you've grep'd your way to a lead, the incident's been going for twenty minutes.
A chatbot with no real access is just a guess with better grammar
General-purpose AI assistants can describe what a Tomcat thread pool exhaustion looks like. They can't tell you if this one, right now, actually has one, because they were never given a way to check.
Ask, plan, collect, answer
Every question goes through the same four real stages, never a shortcut straight to a guess.
Ask
Type a question in plain language, anywhere in the app. Pick a scope: one server, several, or the whole environment.
Plan & approve
A planner maps the question to only the relevant diagnostics. Every single one still has to clear user permission, project policy, and agent capability before it runs.
Collect
The agent, polling outbound-only, fulfills the approved requests and reports back. Secrets and PII get redacted before anything is stored.
Answer
Your configured LLM turns the evidence into a structured finding. No provider configured? You still see every piece of evidence collected, plainly.
What's actually built today
No roadmap items, no "coming soon." This is what runs in the app and the agent right now.
Zero-config auto-discovery
Install one agent and it detects what's actually running: OS, JVM, Tomcat, Docker, Kubernetes, plus Postgres, MySQL, Redis, MongoDB, RabbitMQ, and Kafka by process signature. Only the modules that apply turn on. Real Windows Event Log and Linux syslog collection out of the box, no log path to configure.
Investigation engine
A deterministic planner, a policy-gated evidence pipeline, and an LLM synthesis step that has to fail safe and say "insufficient evidence" rather than hallucinate a cause.
Outbound-only agent
The agent polls the control plane, the control plane never opens a connection to it. No inbound firewall port required on the host you're monitoring, ever.
Log intelligence, not log storage
Logs are pattern-grouped and deduplicated evidence for a specific investigation, capped at 48 hours of retention, deliberately not a searchable archive. This isn't a monitoring platform.
Multi-tenant from the ground up
Organization → Project → Environment → Agent, fully isolated. Platform admins provision organizations and their first admin; org admins provision projects and assign users a project role: Developer, DevOps Engineer, SRE, Security Viewer, Read Only. Platform admins can operate across every tenant they provisioned, everyone else stays inside their own.
Follow-up conversation
"When did this start?" "What changed?" "Show me evidence." Follow-ups stay scoped to the investigation's own evidence, never leaking context across projects.
Multi-provider LLM governance
Register several providers per project, scope one to a specific environment, and an org-level allow/block policy still wins even if a project tries to use a blocked one.
Append-only audit log
Logins, agent registration and revocation, permission and governance changes, every investigation run, every provisioning action. Written once, never edited.
The AI plans. It never gets a shell.
The agent's entire remotely-triggerable surface is a fixed dispatch table of named, read-only collector functions, get_cpu_metrics, get_memory_metrics, get_jvm_metrics, and so on. There is no execute_command, no arbitrary SSH, no sudo, anywhere in the codebase. Adding a new capability means shipping a new signed agent release, never something the control plane can inject at runtime.
- Every tool call still has to pass user permission, project policy, and agent capability, in that order
- Log lines and metric values are treated as untrusted data, never instructions, even ones that look like a prompt injection attempt
- Read-only by default. Any future remediation action would need its own separate, explicit permission
A finding always says how sure it is, and why.
Every conclusion is labeled OBSERVED, CORRELATED, INFERRED, PREDICTED, or VERIFIED, and never presented as more certain than the underlying evidence supports. When the evidence is thin, the answer is "insufficient evidence" plus exactly what's missing, not a plausible-sounding guess.
- Every finding cites the specific evidence IDs it's grounded in
- Multi-server questions get a per-server breakdown when servers disagree, not one answer papering over the difference
- No AI provider configured, or the model's response doesn't parse? You still see the raw collected evidence, never a dead end
Your infrastructure. Your data. Your control.
The full stack, Postgres, the control plane, and the agent, deploys directly on infrastructure you own with Docker Compose. There's no public signup: a platform admin provisions the first organization, and every account after that is provisioned top-down, never a self-serve form.
Questions, answered
Stop searching dashboards. Ask your infrastructure.
Self-hosted, evidence-based, and ready to install on your first server today.