The eight questions, in order
- 01
What leaves the cluster?
Telemetry, prompts, tool outputs, embeddings. Get a concrete list, then the architecture that enforces it. “We do not use it for training” is policy; an in-cluster deployment model is architecture.
- 02
What does it do without asking?
Reads, diagnoses, drafts fixes, or executes them. The four are different products with the same demo reel. Then ask how the chosen level is enforced: a policy you can read, or a setting nobody audits.
- 03
Where is the action boundary?
A fix proposal is safe until it is applied. Which verbs are allowed, on which resources, in which namespaces, under what approval? “It has guardrails” is not an answer; a bounded fixer list with a default-deny is.
- 04
How does it know the fix worked?
An applied action is not an outcome. A real AI SRE re-runs the detection that found the problem and keeps the incident open until the signal says so.
- 05
Can you reconstruct last Tuesday?
Every decision, every approval, every field changed. The record must be yours and tamper-evident — a signed, hash-chained trail beats a vendor UI that can be quietly edited.
- 06
How is it priced when you are worst off?
Per-investigation billing prices your worst night. Ask what one incident costs during an outage wave, and whether you can cap it.
- 07
What happens when it is wrong?
A rollback story, an escalation path, a human override with teeth — and a behaviour you can test. Ask to see a reverted fix, not a rehearsed golden-path demo.
- 08
What is it on day thirty-one?
Beyond the pilot: upgrade path, model-endpoint choice, export of your audit history, what it takes to leave. The demo’s best feature is often the contract’s worst dependency.
Why this order
Questions 1–3 are about the blast radius if the system is confident and wrong. They come first because a yes to autonomy without a bounded answer is the only combination that can take your cluster down on its own.
Questions 4–5 are about whether it can prove — and whether you can audit the proof. An AI SRE that closes incidents on “looks good” converts reliability work into trust work, which is worse than the alert fatigue it replaced.
6–8 are about living with it. Buying mistakes rarely surface in the demo; they surface on the invoice, in the postmortem and at the renewal call.
What good answers sound like
- 1. “Nothing leaves; here is the architecture that makes that true, and here is the model endpoint you choose.”
- 2. A named list of actions, not a slider. “It may restart a pod; it may not touch your data.”
- 3. The boundary is your config, reviewable in your repo.
- 4. “The same detector that opened it closes it,” plus a demo of a fix that got reverted when the re-check failed.
- 5. A signed, exportable record you can verify yourself.
- 6. A flat per-cluster number you can forecast.
- 7. They volunteer the failure story before you finish the question.
- 8. They answer without checking with sales.
These are the questions we structure Srenix around: in-cluster model endpoints, five bounded fixers with default-deny, a re-check after every action, a signed hash-chained audit trail, flat per-cluster pricing. If a demo cannot answer all eight in one call, it is a product for a different buyer.