Reported operating use · Software operations and reliability engineering
AI incident investigation: InEight example
InEight uses Microsoft Azure SRE Agent to investigate incidents across operational signals, source code, deployment history and documented expertise, and to prepare remediation guidance. Microsoft reports review mode and engineer-controlled actions. The account comes from the provider.
Investigate incidents across telemetry, code and deployment records
InEight
Reported production use with review mode and engineer-controlled actions.
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Connect incident evidence to engineer-reviewed guidance
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Evidence
Telemetry, code and deployments
InEight combines operational signals, repository context, history and documented expertise.
- Investigation
Guidance and developer work items
Agents prepare findings, remediation guidance and proposed changes.
- Engineers
Sandbox validation and retained approval
Engineers validate investigations; disruptive operations are blocked within geographic and permission boundaries.
What the source reports
Microsoft reports that InEight connects operational signals, source code, deployment history and documented expertise to investigate incidents and prepare remediation guidance. Engineers validate investigations in sandboxes; some resulting improvements are in production. Findings become developer work items and proposed changes. Production agents operate within geographic and permission boundaries, with disruptive operations blocked and engineers retaining approval.
Reported technology: Microsoft Azure SRE Agent. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Test an incident hypothesis before accepting mitigation
Illustrative project design to scope with your enterprise.
- 1 · Set up the environment
Fictional incident evidence
Pin telemetry, repository commits, deployments and runbooks in a disposable environment.
- 2 · Preparation and agent contributions
Agent builds a timeline and hypotheses
Link each claim to deployment and code versions; prepare a mitigation proposal.
- 3 · Independent checks
Independent engineer reproduces the failure
Test competing causes, affected instances, mitigation and rollback evidence.
- 4 · People decide acceptance
On-call owner accepts or escalates
Accept only the reviewed version; any operational action needs separate approval.
A reviewable evidence package
An incident evidence packet and sandbox-tested mitigation recommendation.
If a check fails → withhold acceptance.
A deployment follows an unrelated infrastructure alert. Test both explanations instead of inferring causality from sequence.
Failure or owner rejection returns to review
- Hold
- → 2 · Revise work
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. No production access; rejected or altered proposals cannot use an old approval.
- Systems and evidence
- Proposed: provide fictional telemetry, repository commits, deployment records and versioned runbooks for one incident in a disposable environment.
- People and agents
- Proposed: an investigation agent assembles a timeline and competing hypotheses; an on-call engineer checks the evidence and chooses escalation or a mitigation proposal.
- State and permissions
- Proposed: bind findings to exact deployment and code versions. Keep production access absent and approvals specific to the reviewed proposal.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Proposed: prepare a traceable incident investigation and a sandbox-tested mitigation proposal.
Review gate: An independent engineer reproduces the failure and checks the mitigation and rollback evidence before separately approving any operational change.
Challenge the result: A deployment follows an unrelated infrastructure alert. The agent must test both explanations rather than infer causality from timing.
What needs checking
- Proposed: reproduce a seeded failure and test whether the proposed cause explains every relevant signal.
- Proposed: check scope across deployment instances without assuming all similar alerts share a cause.
- Proposed: verify a rejected or revised proposal cannot execute through an earlier approval.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
Questions about this example
- What does InEight use AI for in incident response?
- Microsoft reports that InEight connects operational signals, source code, deployment history and documented expertise to investigate incidents and prepare remediation guidance. Findings become developer work items and proposed changes.
- Who keeps control of actions at InEight?
- The source says engineers validate investigations in sandboxes and retain approval. Production agents operate within geographic and permission boundaries, and disruptive operations are blocked. Review mode and engineer-controlled actions are part of the reported setup.
- How strong is the evidence for InEight's use?
- It is reported production use, in a provider-published customer account rather than an independent evaluation. The reported effort reductions have no published evaluation dataset or controlled comparison, and broader planned automation is not treated as deployed.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design, not InEight's. It would need fictional telemetry, commits, deployment records and versioned runbooks for one incident in a disposable environment, with no production access. A seeded failure would test whether the proposed cause explains every signal.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- This is a provider-published customer account, not an independent evaluation.
- Reported effort reductions lack a published evaluation dataset or controlled comparison. No percentage is adopted as an acceptance target.
- Broader planned automation is not treated as deployed, and the case does not establish autonomous production repair.
- The proposed environment and checks are illustrative designs, not executed Nuvepro work or replicas of customer systems.
- InEight cuts incident investigation effort 60% with Azure SRE AgentSource publication: 2026-10-28
More it operations examples
- AI cloud incident investigation: Eon exampleEon
- AI IT service requests: Redpanda exampleUnnamed enterprise customer reported by Redpanda
- AI network config review: Microsoft Digital exampleMicrosoft Digital
- AI service investigation dashboards: Grafana Labs exampleGrafana Labs