/ai-sre

Use when the ask is what happened in production on a resource — a worker, service, endpoint, playbook id, request id, or a reported error phrase — and an observability/logs MCP is connected.

Prefer to delegate: task({ subagent_type: "sre", description, prompt }) runs this ladder in the background; await_subagent before you answer. Follow the ladder yourself only when you are already inside that subagent or no spawn is available.

Ladder

1. Scope — pin the subject and a time window before touching a tool. Default 48h. A window that does not cover the reported time makes every later result meaningless.
2. Resolve — get_mcp_tools({ pattern: "logs" }) to find the query tool, then get_mcp_tools({ server, tool_name }) for its input schema. Read the schema every run: vendors rename tools and reshape query DSLs between releases, and a remembered argument shape fails as a validation error or a silently empty result set.
3. Learn — two strikes and you research. When a second call fails for the same reason, stop adjusting the query shape and spend a turn on websearch / docs / read_url. Search the vendor, the tool name, and the verbatim error string, and include the MCP server's issue tracker (<vendor> mcp server <tool> <error text> github issue). A tool that rejects its own payloads is usually a known upstream bug with a documented workaround — apply it, or report the bug with a link if there is none. Treat an unexpectedly empty result as a failure too: a filter that silently drops every row looks exactly like "nothing is wrong".
4. Signal — query the subject over the window. Ask for a distribution first (count grouped by status / level / endpoint), then an error sample, then individual events. Reversing that order burns the budget on rows you cannot generalise from.
5. Correlate — only when the signal is ambiguous, follow exactly one thread: a suspicious endpoint, a failing dependency, a deploy timestamp, or the owning code via read / grep.
6. Conclude — stop the moment the evidence supports a claim.

Budget

Cap the investigation at 12 MCP calls: ~1–2 discovery, 3–4 primary signal, the rest for one follow-up thread.

Batch: independent calls issued in the same turn run in parallel, up to 8. The signal queries do not depend on each other, so send them together. One call per turn is how these runs get truncated before they reach a conclusion.

Track spend as you go. With two calls left, stop widening and write the answer — a partial answer that names its gap is more useful than a ladder cut off mid-rung.

Evidence discipline

• Claim a cause only when a returned result supports it. Otherwise report the run as inconclusive and name the one query that would settle it.
• 2xx is not health. Absence of errors counts only if you queried for errors and the window covered the reported time. Say which of those two you actually established.
• Quote counts, status distributions, and timestamps. Never round an adjective ("mostly fine") over a number you did not retrieve.
• A malformed or erroring payload is a finding — report it verbatim and do not retry the same shape more than once.
• When an upstream tool bug caps what you can see, name it with a link and say which question stays unanswered because of it. A Gap the reader can act on beats "inconclusive".
• If nothing connected can answer, name the MCP server to connect and stop. Do not substitute a plausible guess.

Output

Four short labelled parts, 3–12 lines total: Root cause · Evidence · Gaps · Next. Never paste raw MCP payloads; aggregate large spills with script and report counts or filtered rows.