An on-call agent that remembers the runbook, and which step still works

The senior engineer who never sleeps

Want to build an on-call agent that remembers the runbook? Here is how

Think about the one senior engineer on your team who has been there five years. At 3am when the payments service falls over, you do not page the runbook wiki, you page her. Not because she is smarter than everyone else, but because she remembers.

She knows the dashboard that actually shows the problem. She knows that the documented restart trick stopped working after the March migration. She knows which on-call rotation owns the database now. None of that is written down anywhere current, it lives in her head, carried forward from one incident to the next.

An SRE agent without memory is the brand new hire on their first night shift, reading the wiki out loud and hoping it is current. An SRE agent with Korely is that senior engineer, except she never sleeps and never quits. You want the second one answering the page.

Korely is the memory that turns the new hire into the veteran.

How you build it

Six steps, and only the last one is hard

1. Wire the agent to your signals

   Give it read access to your alerting (PagerDuty, Opsgenie, Grafana, Datadog) so when an alert fires the agent gets the service name, the severity, and the firing metric. This part you already know how to do in Claude Code or Cursor.

2. Give it hands

   Let it run the safe diagnostics it is allowed to run: pull recent logs, check the deploy history, hit a health endpoint, read the last three incidents for this service. Read-only first, write actions behind approval.

3. Write down what the team knows

   Every incident teaches something: this alert is usually a noisy neighbor, the real fix for the queue backup is to scale the consumer not restart the broker, the payments service is owned by the Orders squad now. Save those as memories the moment they are learned, do not leave them in a Slack thread that scrolls away.

4. Pull the right runbook at the right moment

   When an alert fires, the agent searches its memory for this exact service and this exact symptom, and gets back the steps that actually worked last time plus who owns it now, not the generic wiki page that has not been touched since 2024.

5. Let it learn during the incident

   When the responder finds the real cause and the real fix, the agent records it against the service so the next 3am page starts from what you just learned, not from zero.

6. The part you skip, which is Korely

   All of the above only works if the memory underneath is a bi-temporal graph-RAG store: typed facts about services and owners, a graph that links an alert to its service to its on-call team, ranking by relevance with a weight for recency, and contradiction handling so a new fix or a changed owner closes the old one, which stays in the history. Korely is that layer, hosted in the EU, with no generative model on reads, starting at 19 euro a month + VAT. You build the agent, we are the memory it runs on.

The shape of the fix

The incident teaches the memory, the next page reads it back

How Korely fits

The memory infrastructure your demo hides and production exposes

Anyone can wire an agent to PagerDuty in an afternoon. The hard, slow, expensive part is building a store that holds typed facts about your services and owners, a graph that knows alert to service to on-call team, that closes a fix you retired last quarter and keeps it as history, and that resolves contradictions so when ownership moves from Team A to Team B the agent serves the new owner as current and the old one as history.

It has to do all of that on a read that adds a vector query and a fact lookup, with no generative model turn, while a responder is staring at a red dashboard. That is a bi-temporal graph-RAG system, and building it well is a multi-month project that has nothing to do with your actual agent. The retrieval is a pgvector search plus a lookup of the typed facts, Postgres only, so the right runbook surfaces whether the agent matched the exact service name or a loose paraphrase of the symptom.

The block the agent reads stays under a token budget you set, 800 tokens by default, so a year of incident history does not crowd the prompt during the next page. Reads run no generative model, so the lookup adds a database query to your incident loop, not another model turn. Its store is Postgres, hosted in the EU, which matters because your incident data is some of the most sensitive operational data you have. To extract facts, the text of each write, with up to ten earlier memories of the same end user (300 characters each) and the earlier facts it is compared with, goes to the model of your project's region, Google's Gemini API by default or Scaleway in Paris if you choose the EU region.

You skip the multi-month infra build and ship the agent, starting at 19 euro a month + VAT after the free tier.

Show me the code

A minimal write-then-page flow

# ── During the incident: the responder finds the real fix ───────
from korely_memory import Korely

korely = Korely(api_key="kor_live_...")

# orders-db failover at 3am, old manual-promote step now causes harm
korely.add(
    "orders-db failover: do NOT manually promote the replica. After "
    "the March managed-Postgres migration, wait for managed failover "
    "to complete, then clear stale connections in the pooler.",
    agent_id="sre-orders-db",
)

# ── Next page: a fresh session recalls the current runbook ──────
ctx = korely.get_context(
    "orders-db failover fix",
    agent_id="sre-orders-db",
)
# ctx → a block that includes the current step (wait for managed failover)
#   and can still include older notes; the agent prefers the later date.

# The agent prepends this before proposing a step to the responder.