The core loop

Everything ISE does follows one loop:

Monitor — sync state and signals from connected systems → Analyse — evaluate them, with evidence → Evaluate — triage into owned incidents → Configure — change things, through approvals, with an audit trail.

The loop is not strict. Operators jump about it, run steps again, and go back a stage when a diagnosis turns out to be wrong. What is strict is the gate between proposing a change and making one.

Monitor

Each connected system contributes what it is good at. Sources with their own detection layer (DataDog, the cloud providers, Microsoft 365) hand ISE their alerts and ISE forwards them rather than second-guessing them. Sources without one — Kubernetes above all — get ISE’s own deterministic detectors, running on a slow loop over synced state and producing observations.

Alongside signals, discovery keeps the estate current: entities, their tags, and how they relate — joined across sources, so one host is one entity no matter how many systems report it.

Analyse

Analysis is where AI enters, and it is deliberately bounded: models read, reason, and write records — they never touch infrastructure.

Evidence is fetched on demand, when an investigation asks for it, rather than polled speculatively: metrics for the window that matters, logs for the failing pod, the audit log for who changed what. Everything an analysis used is recorded, so the answer to “why is ISE telling me this?” is always one click away, and every AI run has a full trace on the Agent runs screen.

Evaluate

Signals are transient; incidents are durable and human-owned. A signal above the severity and confidence thresholds opens an incident, which carries ownership, the canonical severity, its evidence, and the whole remediation conversation. Related incidents can be grouped; recovery at the source resolves them.

Incident detail is a conversation, not a stack of panels: a timeline where operator messages, AI replies with their tool traces, diagnoses, proposals, approvals, and execution results all appear in time order. See signals & incidents for the full model.

Configure

This is the governed part, and the boundary is structural rather than a matter of prompting or good behaviour:

1. Propose. A proposal can come from AI diagnosis, from you clicking an action, or from typing “propose scaling that deployment” — all three reach the same governed entry point. A proposal is a record, not a change: it names the target, the exact operation and parameters, its risk tier, and the expected effect.
2. Approve. A human opens the gate. Higher tiers require an approver who is not the proposer, so an AI-drafted change can never satisfy its own approval — the AI has no approve capability at all.
3. Execute. Deterministic connector code applies the approved parameters, with no model in the loop. Long-running operations are polled to completion and reported truthfully — success means the system said it finished.
4. Verify. The result lands on the incident timeline and the audit trail. If the condition clears, the signal recovers and the incident resolves; if not, the loop goes round again with what you just learned.

See actions & approvals for tiers and policy, and proposals for the workflow as you meet it on screen.

A worked example

A Kubernetes deployment starts crash-looping after a release.

• Monitor — Kubernetes has no alert for this, so ISE’s crashloop detector raises a high-confidence observation against the workload entity.
• Evaluate — it clears the threshold, and an incident opens carrying the workload’s namespace, cluster, tags, and the services it belongs to.
• Analyse — investigation pulls pod logs and recent events on demand, and notices a deploy event on the timeline from eight minutes earlier. The diagnosis: the new image fails its readiness probe.
• Configure — a proposal is drafted to revert the image. It is edit_resource, a T2 operation, so it waits for an approver; you read the exact parameters, approve, and ISE executes it deterministically.
• Verify — pods go healthy, the observation stops firing, the incident resolves, and the whole sequence — proposal, approver, parameters, outcome — is on the audit trail.

Round the loop once more if the revert hadn’t worked. Nothing about the model changes when the answer is wrong; only the evidence does.

Where the loop gets faster

Two things shorten it over time. Playbooks turn a known fix into pre-approved response: approval is spent once, at publish, so a responder can execute it from a guided incident page without a fresh approval each time. And the estate itself gets better — identity resolution, relationships, and operator context all make the next investigation more directed than the last.