Split judgment from computation
Language models are good at reading an alert, choosing what to look at next and adapting when the data is surprising. They are not reliable at parsing thousands of lines of output or doing arithmetic on time series. So each does only what it's good at.
Claude
Judgment and orchestration
- Reads the alert and picks the runbook
- Resolves topology and gathers data through your tools
- Adapts when the evidence points somewhere else
Parsers
Everything that must repeat
- Parsing, time alignment and spike detection
- Classification and root-cause attribution
- Every number that reaches the incident thread
Engineer
Intent and accountability
- Forms the hypothesis that starts the run
- Confirms anything that changes production
- Reviews the write-up before it's posted
How a run works
EngineerHypothesisA short prompt naming the shard, service or time window
ClaudeOrchestrateLoads the runbook, its pitfalls and its notes
ClaudeCollectShell, cloud, metrics and chat through your tools. Every command is logged
ParsersComputeAlign, detect, classify and attribute in tested code
EngineerDecideReviews a draft report, data first, then acts
Every incident feeds back in. Mistakes become runbook pitfalls that later runs treat as hard constraints, and gaps in the data become new parser features.
How this compares
There are good AI SRE products on the market, and for some teams they're the right choice. Here is where HASHJOIN's approach differs.
| Typical AI SRE product | HASHJOIN | |
|---|---|---|
| Repeatability | The model reads raw output and summarizes it; answers can vary between runs | Numbers come from tested code; the same input gives the same answer |
| Unusual infrastructure | Strongest on standard Kubernetes and cloud setups | Runbooks and parsers are written for your stack, including homegrown parts |
| Your data | Telemetry usually goes to the vendor's cloud | Runs in your environment; telemetry stays with you |
| Ownership | Subscription; the logic lives with the vendor | You own the code, the runbooks and the knowledge store |
| Pricing | Per seat, per investigation or per event | Fixed-scope build, then a flat monthly retainer |
Guardrails
- Read-only by default. Anything that changes production stops at a confirmation gate.
- Every command is logged, with recall, so the next incident can start from what the last one learned.
- Write-ups have rules. Data comes first, every figure traces back to a parser, and an engineer posts it.
- No lock-in. The analyzers are plain Go or Python with tests, useful with or without a model.
This is the pattern behind the OPS Framework, which HASHJOIN's principal led at Slack. Read the full case study on mogilevskiy.dev →
See it against your incidents
The readiness assessment includes a working analyzer built from your own data.