I Built an Agent That Learns From Confirmed Incidents

Boini chandana — Tue, 29 Sep 2026 04:43:10 +0000

The most dangerous sentence in incident response is "we've seen this before." It's usually true enough to be useful and wrong often enough to hurt, and I wanted to build a tool that helps with the first part without amplifying the second.

RecallOps is an incident-response assistant. An on-call engineer describes what's broken, the system pulls up similar incidents from our history, and it proposes what to check first. The interesting part isn't the retrieval. It's what we decided to let the system remember, and what we decided to make it forget.

What it does and how it hangs together

The whole thing is a small FastAPI service and a static HTML page. No frontend build step, no queue, no database of our own. Everything stateful lives in a memory bank managed by Hindsight, an open-source agent memory system. The service exposes four routes that matter:

POST /api/incidents/analyze takes a title, service, severity, and error description, and returns similar past incidents plus a structured analysis.
POST /api/incidents/resolve takes the engineer's confirmed fix and observed outcome and writes it back to memory.
GET /api/memories lists what the bank currently holds, so anyone can audit it.
GET /api/health reports the bank in use.

Hindsight's Python client gives us three operations, and each one maps to a step in the workflow: recall retrieves similar incidents, reflect reasons over them, and retain stores new experience. If you're new to the concept, Vectorize has a good primer on what agent memory is, and the Hindsight docs cover the client API. I won't rehash either.

The flow for one incident looks like this:

The engineer submits an incident.
We build a query from service, title, and description, and call recall.
We hand the top five results to reflect with a tightly constrained prompt.
The engineer sees the evidence and the analysis side by side.
Later, once a human confirms what fixed it, we call retain.

Step 5 is the one I want to spend most of this article on.

The through-line: memory should hold outcomes, not opinions

The obvious way to build this is to write everything into memory: the incident, the model's analysis, the engineer's follow-up, the chat transcript. More context, better recall, right?

I think that's a trap for incident response specifically. If the model's analysis goes into memory, then next time a similar incident appears, the model retrieves its own earlier guess and treats it as evidence. A wrong hypothesis becomes a "historical incident" that supports itself. You've built a feedback loop that launders speculation into fact, and it does so quietly, because each individual retrieval looks reasonable.

So the rule in RecallOps is that the only thing that ever gets retained is what a human confirmed. Here is the write path in full:

@app.post("/api/incidents/resolve")
def resolve(req: ResolveRequest):
    ensure_bank()
    content = (
        f"Incident #{req.incident_id}: payment-gateway incident. "
        f"Confirmed resolution: {req.resolution} "
        f"Observed outcome: {req.outcome} "
        f"Runbook: {req.runbook}."
    )
    client.retain(
        bank_id=BANK_ID,
        content=content,
        context="Human-confirmed incident resolution. Store as future experience; do not store model reasoning.",
        metadata={"incident_id": str(req.incident_id), "source": "engineer-confirmed"},
    )
    return {"ok": True, "incident_id": req.incident_id, "content": content}

Three things are doing work here. The write is triggered by an explicit button, "Mark as Resolved & Save Memory", not by the analysis finishing. The content is limited to the confirmed resolution, the observed outcome, and the runbook that was used. And the context and metadata fields tag every record with its provenance, so source: engineer-confirmed is something we can filter or audit on later.

The analyze route, by contrast, never calls retain. Reading is free; writing is a decision.

The seed records follow the same shape. Each one has a root cause, a resolution, and an observed outcome, and nothing that reads like a guess:

def memory_text(m: dict) -> str:
    return (
        f"Incident: {m['incident']}\n"
        f"Service: {m['service']}\n"
        f"Root cause: {m['root_cause']}\n"
        f"Successful resolution: {m['resolution']}\n"
        f"Runbook: {m['runbook']}\n"
        f"Observed outcome: {m['outcome']}"
    )

I like this template because it's boring. "Observed outcome" is the field that matters most. A resolution without an outcome is a story someone told; a resolution with one is a data point.

Where Hindsight earns its place

I could have built the retrieval side with a vector store and some glue. I didn't, for a reason that only became obvious once I used it for this: incident history isn't a pile of documents, it's accumulated experience, and the questions you ask of it are different.

An on-call engineer at 3am doesn't type "Payment Gateway Timeout" and want documents containing those words. They want "have we seen something like this, and what happened?" That's why the recall query is built from the service, the title, and the raw error text together:

query = f"{incident.service} {incident.title} {incident.error_description}"
recalled = client.recall(bank_id=BANK_ID, query=query, max_tokens=4096, budget="mid")
memories = [result_to_dict(r) for r in recalled.results[:5]]

I cap it at five memories on purpose. More than that and the reasoning step starts averaging across incidents that only share vocabulary. The budget="mid" setting is a middle position on how hard recall works; I haven't needed to turn it up.

The other piece is the bank itself. ensure_bank() creates it with a mission statement: "Help engineers diagnose production incidents using verified historical experience." That's short, but it gives the memory system a purpose to organize around, and the word "verified" in it is a constraint I wrote for myself as much as for Hindsight.

The practical benefit is that I didn't have to design a retention schema, an embedding pipeline, or a ranking layer. I wrote the discipline about what goes in, and the memory layer handled storage and retrieval. Every new confirmed resolution is available to the next recall call immediately, with no re-indexing step in our code.

The reasoning step, and making it distrust its own evidence

reflect is where the recalled history becomes a recommendation. I spent more time on this prompt than on the rest of the service combined, and most of that time went into rules that make the model less confident:

Rules:
1. Similar symptoms do NOT prove the same root cause.
2. Explicitly explain why the best historical memory is relevant.
3. Explicitly explain what is different or still unknown.
4. Recommend verification checks before risky production changes.
5. Treat previous solutions as references, not commands.
6. Never invent evidence that is not in the incident or memories.
7. Keep the answer concise.

The output schema forces the same posture. Alongside likely_cause and recommended_action, the model must fill in why_relevant, what_different, checks, and warnings. You can't return a recommendation without also stating how the current incident differs from the historical one. Rule 3 is the one I'd keep if I could only keep one.

This was the painful part. reflect returns text, and I'm asking for JSON. Models wrap JSON in markdown fences, add a sentence of preamble, or occasionally trail off. The parser is unglamorous and I'm not proud of it, but it has to exist:

def parse_json(text: str) -> dict:
    text = text.strip()
    text = re.sub(r"^```(?:json)?\s*", "", text, flags=re.I)
    text = re.sub(r"\s*```$", "", text)
    try:
        return json.loads(text)
    except json.JSONDecodeError:
        match = re.search(r"\{.*\}", text, re.S)
        if match:
            return json.loads(match.group(0))
        raise

And when parsing or the call fails entirely, the route doesn't return an error. It falls back to a conservative analysis built from the top recalled memory: the likely cause is lifted from that memory's "Root cause" line, and the recommended action is "Do not make a production change until the immediate checks confirm the historical failure mode." During an incident, a tool that fails closed with useful evidence beats one that fails with a stack trace.

What it does in practice

Say the payment gateway starts timing out and an engineer submits:

Title: Payment Gateway Timeout
Service: Payment Gateway
Description: Requests to the gateway API are timing out and checkout error rates are climbing

Recall returns up to five prior incidents on that service, and the UI shows them in a console panel next to the analysis so the engineer can see exactly what the model was given. In our seed history, a prior "Payment Gateway Timeout" was resolved by restarting the payment service and verifying gateway connectivity. But the same history also holds an expired TLS certificate, connection pool exhaustion from stuck requests, and an upstream provider degradation. All four present as "the gateway is slow or failing."

That's the situation the prompt is built for. The response has to say which memory it thinks is closest and why, then say what's different or unverified, then list checks such as service logs, upstream connectivity, and recent deployments before proposing the restart. The previous fix is shown under "Previous Solution", explicitly labeled as a reference, and the warnings block carries the reminder that historical similarity isn't proof of identical root cause.

When the engineer finishes, they enter what actually fixed it and what they observed, and click the button. That record is what the next person's recall will find. If it turned out the root cause was different from the top match, the new record says so, and the history gets more accurate rather than more self-confident.

The Incident Memory page lists everything in the bank as plain text. I consider that page a feature, not an admin tool: if you can't read what your agent remembers, you can't trust what it recalls.

Lessons learned

Decide what memory is for before deciding what it holds. "Everything" is not a policy. For us the answer was verified outcomes, and that one decision shaped the API, the UI, and the prompt.

Never let a model retrieve its own guesses. If analysis text can flow back into memory, sooner or later it will be recalled as fact. Gate writes behind a human action and record provenance in metadata.

Make the model state the differences. Asking "what's the answer?" gets you confidence. Asking "why is this memory relevant, and what is different?" gets you something an engineer can check. A required what_different field is cheap and effective.

Fail closed and keep the evidence visible. Structured-output parsing will fail sometimes. Design the fallback so the engineer still sees the retrieved incidents and a cautious next step, and show the raw recalled memories alongside the analysis so the model's summary is never the only source.

Let the memory layer do memory work. Most of the code in this repo is validation, prompt text, and glue. I'm glad the retention and retrieval side is something I use through retain, recall, and reflect rather than something I maintain. If you want to look under the hood, the Hindsight repository is the place to start.

The next thing I want to do is use the source metadata to weight or filter recalls, so that records with different levels of verification can coexist in one bank without being treated the same. The write discipline is what makes that possible, and it's the piece I'd copy first into any other agent that has to learn from its own history.