Assist & chat

ISE has three places you can ask a question in plain language. They look similar and are bounded very differently, and knowing which is which tells you what each one can do for you.

Surface	Scope	Can it act?
Assist	The whole estate	No — read-only, enforced by the database
Incident chat	One incident	It can drive the loop and pull live evidence, but never change infrastructure
Claude over MCP	One pinned incident, from your own machine	Same governance: ISE stays the system of record and the write gate

Assist

Assist is estate-wide operator Q&A: “which hosts are missing the env tag?”, “what’s open on the payments cluster?”, “when did this service last change?” Answers cite the ISE records they came from, with links, so you can go and read the underlying thing rather than trusting a summary.

Responses stream as they are produced. A chat box that waits fifteen seconds and then dumps a finished answer reads as broken, so assist emits tokens as it goes — and the text is redacted as it flows, accumulated and scrubbed as a whole so a secret split across two fragments can’t slip through.

Assist is structurally read-only: every one of its tools runs inside a read-only database transaction, so it cannot write, whatever it calls. That is a mechanism, not a convention or a prompt instruction — which matters because assist is the widest prompt-injection surface ISE has (it reads the whole estate on your free text). Where an answer suggests a change, assist links you into the proposal flow rather than starting one.

Read-only is not the same as harmless: a poisoned input can still make an answer wrong. It cannot make ISE act.

Incident chat

Every incident’s detail page is a conversation. The timeline merges your messages, streamed AI replies with their tool traces, diagnoses, proposals, approvals, and execution results into one chronological view, and the input box sits under a row of pre-baked actions: analyse, diagnose, propose remediation, resolve, dismiss.

The loop can be driven by button or by prompt — typing “propose scaling the deployment” reaches exactly the same governed entry point the button does. It is a second doorway, not a bypass.

Because you are here to fix this incident, this surface is bounded differently from assist. It can:

• Read anything, including live evidence pulled on demand from the connected systems — the actual metrics, logs, and resource state, not just what ISE already synced.
• Write ISE records through the same governed channels its buttons use — enqueueing analyse/diagnose/propose, and committing a structured diagnosis to the timeline.

It still cannot touch your infrastructure. There is no action catalogue in its toolset, so a change still has to cross a tier, a policy, a human, and a deterministic executor. Evidence it pulls is treated as untrusted information to weigh — never as instructions to follow.

Claude over MCP

For deep investigation, engineers can work an incident from Claude Code on their own machine, over a governed ISE MCP server. You pin a session to an incident, and the interactions are written back to that incident’s timeline so the pane of glass stays honest about what happened.

The governance does not change: ISE remains the system of record and the sole write gate, approvals are surfaced and recorded in ISE, and the same tiers apply. Access is per-user tokens issued in ISE.

Finding things

Alongside chat there is ordinary search: a command palette for jumping straight to an entity, incident, or system, and full-text search across the estate. When you know what you are looking for, that is faster than asking for it.

Next

• Proposals — where a suggested change actually goes.
• Roles & access — the containment model behind these boundaries.
• The core loop — how the conversation fits the wider workflow.