Incident copilot that has read every postmortem

​

The scenario

​

Step 1 — Load the postmortems, dated

client.upload_file(
    space_id="incidents",
    file="2026-08-08-pgbouncer-exhaustion.md",
    tags=["service:gateway", "severity:sev1"],
)

​

Step 2 — Ask with the symptom, not the cause

print(client.reason(
    space_id="incidents",
    query="Gateway tasks failing to start, connection errors, database connections pinned at 21. Seen before?",
))

​

Step 3 — Narrow to what happened recently

client.retrieve(
    space_id="incidents",
    query="connection pool exhaustion",
    occurred_after="2026-01-01T00:00:00Z",
    tags=["service:gateway"],
)

​

Step 4 — Write the new one back

client.record(
    space_id="incidents",
    content="Recovery order matters: redeploy pgbouncer first, then the gateway. The reverse fails because new tasks cannot boot.",
    timestamp="2026-08-08T04:10:00Z",
    tags=["service:gateway"],
)

​

Evals

1. Take your last five incidents. For each, ask using only the symptoms visible in the first ten minutes.
2. Score whether the matching postmortem surfaced in the top three results.
3. Include one novel symptom. It must return nothing rather than the nearest familiar incident — a confident wrong match at 3am is worse than silence.
4. Re-run monthly. A falling score means the corpus is drifting from production.

​

Guardrails

• Postmortems name people. Write about decisions and systems, not blame — it is retrievable forever and reads worse out of context.
• Set the incident’s own timestamp. A year of postmortems uploaded in one afternoon all happened that afternoon otherwise, and “has this been getting more frequent?” becomes unanswerable.
• Tag by service. Cross-service noise is what makes an incident search useless at the moment you need it.

​

Built from