Use case · DevOps / SRE agent
An on-call agent that remembers the runbook, and which step still works
Service owners, on-call rotations, the fix that actually worked last time. Recorded once during the incident, read back at 3am on the next page. When a step is retired, the agent stops serving it and gives you the current one.
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, recency so a superseded fix stops surfacing, and contradiction handling so a changed owner overwrites the old one. Korely is that layer, running in the EU, reads under 50ms, starting at 19 euro a month. 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
Incident, March
The responder finds the real fix
- orders-db failover at 3am
- Manual promote is wrong now, record the new step
Korely memory
Agents/SRE/orders-db
- Typed facts: service owners, on-call rotation
- Old fix marked superseded, new fix current
Next page
The agent answers from what is true now
- Reads the current step before proposing it
- Wait for managed failover, not manual promote
One loop per service. The fix recorded during the last incident is the fix the agent serves on the next one, with the retired step kept on the timeline for the audit, not handed back at 3am.
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 ranks by recency so a fix you retired last quarter stops surfacing, and that resolves contradictions so when ownership moves from Team A to Team B the agent serves the new owner and not both.
It has to do all of that fast enough to be useful 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 hybrid: FTS plus pgvector plus RRF plus a reranker, Postgres only, so the right runbook surfaces whether the agent matched the exact service name or a loose paraphrase of the symptom.
We measured it. At the same token budget an agent answers 76 percent of questions correctly reading from Korely selected memory versus 42 percent from a same-size recent-history window, a 34 point gap that is reproducible. Reads come back in under 50ms with no LLM on the read path, so the lookup does not add latency to your incident loop. It runs in the EU on Postgres, which matters because your incident data is some of the most sensitive operational data you have.
You skip the multi-month infra build and ship the agent, starting at 19 euro a month 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 ──────
context = korely.search(
"orders-db failover fix",
agent_id="sre-orders-db",
)
# context → "Wait for managed failover, clear stale connections."
# The agent prepends this before proposing a step to the responder.
# The retired manual-promote step is superseded, so it never surfaces.
The same memory is reachable from any agent, Claude Code, Continue,
n8n, a LangGraph runbook, or a plain HTTP client. Scope memories with
different
agent_id
values so each service or team stays separate and auditable.
When a fix goes stale
The step that was right in February is wrong after the migration
A database failover alert fires at 3am for the orders-db cluster.
Six months ago the runbook said the fix was to manually promote the
replica and restart the connection pooler. After the March migration
to managed Postgres that step became wrong, it actually causes a
longer outage now, and the responder that night recorded the real
fix: just wait for the managed failover to complete and clear the
stale connections.
With a plain wiki or a naive memory dump, both versions sit in the
context and the agent surfaces the old manual-promote step, the one
that now makes things worse. Because Korely is time-aware, the
moment the new fix was recorded the old one was marked superseded. So
at 3am the agent answers from what is true now: do not manually
promote, wait for managed failover, clear stale connections.
The half-asleep on-call engineer gets the current step, not the one
that was retired in March, and the outage is two minutes instead of
forty. The old step is not gone, it sits on the timeline with its
dates, so when someone reviews the incident later they can see
exactly when and why the procedure changed.
timeline.py python korely.add(
"orders-db failover fix: manually promote the replica.",
agent_id="sre-orders-db",
metadata={"effective_from": "2025-09-01"},
)
# After the March migration to managed Postgres, the step changes
korely.add(
"orders-db failover fix: wait for managed failover, clear pooler.",
agent_id="sre-orders-db",
metadata={"effective_from": "2026-03-15"},
)
korely.search("failover fix", agent_id="sre-orders-db")
# → "Wait for managed failover" (current). Manual-promote superseded.
# Audit why the procedure changed via the REST API:
# GET /v1/memories/{id}/history -> full timeline with effective_from
Frequently asked
On-call agent memory, common questions
How is this different from just pointing my agent at our runbook wiki? +−
A wiki is a flat pile of pages that someone has to keep current by hand, and at 3am nobody knows which page is still true. Korely stores the runbook as memory the agent itself writes and updates, scoped to the exact service, and ranked by recency. When a fix is retired the old step stops surfacing automatically, so the agent serves what worked last time, not the page that has not been edited since 2024.
What happens when a fix that used to work becomes wrong? +−
That is the case Korely is built for. Facts are time-aware. When the responder records a new fix, the old one is marked superseded, not deleted. The agent answers from what is true now, so it stops suggesting the manual-promote step that caused a longer outage after your migration. The full history is still there if you need to audit why a procedure changed, you just do not get the stale step served back to you during the next page.
How does it know who owns a service when teams reorganize? +−
Ownership lives as a typed fact in the graph, alert to service to on-call team. When ownership moves from one squad to another you record the change once, and Korely contradiction handling overwrites the old owner instead of keeping both. So the agent escalates to the team that owns it today, not the one that owned it last quarter. No more paging the wrong rotation at 3am.
Will adding memory slow down my incident response? +−
No. Reads come back in under 50ms and there is no LLM on the read path, it is a direct lookup into the indexed store. Memory is not in the critical path the way another model call would be. In our reproducible test an agent answered 76 percent of questions correctly from Korely selected memory versus 42 percent from a same-size window of recent history, so you get a large accuracy gain without paying a latency cost.
Where does our incident data live, and can we delete it? +−
In a managed store in the EU, Postgres with a vector and graph index. Incident data is some of the most sensitive operational data you have, so it stays in the EU and you never host anything yourself. You can export everything or erase it with one call, scoped per agent so each service or team stays separate and auditable.
What do I actually have to build versus what comes from Korely? +−
You build the agent: wire it to PagerDuty or Grafana, give it the safe diagnostics it is allowed to run, decide what it proposes versus what it executes. You already have Claude Code or Cursor to do that. What you do not build is the memory layer underneath: the bi-temporal facts, the entity graph, recency ranking, and contradiction handling. That is the multi-month infrastructure project, and it is exactly what Korely hands you, starting at 19 euro a month.
Wire your on-call agent to a memory that already knows your services
The Hobby tier is free, Developer starts at 19 euro a month. Sign up,
get an API key, and run your first memory write in minutes, then let
the next page read it back.
Looking for a different shape?
See the other nine use cases →