Automated Incident Diagnosis

I built the diagnosis harness, the Unified path and its migration, plus the Studio adapters that use it. The default flow selects context and calls bounded read-only tools before it assembles a response for REST, streaming, and Studio.

The earlier parallel-investigator design remains available for cases that need it, but it is now a fallback rather than the standard route. Shared clients and the wider operational platform remain team context.

Requests from REST, streaming, and Studio enter the same default loop. It chooses incident context, reads the relevant operational tools within their allowed scope, and assembles a response around the results returned by those tools.

Streaming can show progress while the investigation is still running; the final verdict is a different state. That distinction lets a responder tell what has been checked from what the completed investigation concludes.

Indexed operational knowledge is useful for understanding a service and choosing where to look. It is not the same as current proof. A prompt-only or retrieval-only diagnosis would have been simpler to demonstrate, but it would blur historical context with live service state.

The response therefore keeps evidence references alongside the claim and preserves the difference between streamed work and the final verdict. That adds interfaces and tests, but it prevents a fluent answer from being mistaken for an operational decision.

The loop only reads from bounded tools. If a result is stale, missing, or contradictory, the response keeps that gap visible and can ask for the next piece of evidence instead of smoothing it into a confident story.

A recommendation can still make the next investigation step clear, but an engineer decides whether any production change is appropriate. The system stops at a review boundary rather than turning a diagnosis into an automatic action.