Agents that remember what the last fix actually did
The runbook says what to try. It does not say that it was tried here in March, that it worked, and that it broke something else two days later.
Every on-call starts from zero
Incident work generates exactly the right material and files it in the one format nothing can use: free text, written in a hurry, at the end of a ticket.
The fix is a sentence, unattached to the symptom
“Restarted the pool, cleared.” Which symptom, on which host, under what load, and whether it held — none of it is captured in a way the next occurrence can retrieve.
The change and the incident live in different systems
The deploy that caused it is in one tool and the incident is in another. The causal link exists only in the head of whoever was on call, and only until they go on holiday.
A fix with a delayed consequence looks like a success
It resolved the page and caused the next one, forty-eight hours later. Nothing connects the two, so the same remedy is recommended again.
Mostly episodic. Then three others.
Every application built on CortexDB is a different mixture of the same five memory jobs. That mixture is what makes this a different piece of software from the one next to it, even though the infrastructure underneath is identical.
Action, reasoning and outcome stay attached to each other
What was tried, why it was tried, and what happened afterwards — including two days afterwards — are one memory. That is the difference between a runbook and experience.
- The why is retrievable with the what.
- Outcomes return as experience, not as ticket text.
- Repeat incidents are recognised as repeats.
One history across the rota
What the last responder learned is what the next one starts with, at 3am, without waking anybody.
The architecture has changed since
A fix that was correct against last year's topology should not be returned as current advice.
A similar alert is not the same fault
Selection weighs service, dependency and recency rather than how closely two alerts read alike.
That is four of the five. The fifth — persistent memory, where an individual's preferences and corrections survive — leads for assistant and commerce agents instead. Same engine, different mixture.
The incident is already fully recorded, in six places
The page, the thread where it was worked, the deploy that preceded it, and the ticket that closed it.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,jira]'02 Write the fix and what followed it
Including the part that happened later. A remedy with a delayed side effect is only learnable if the side effect is attached to it.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:itsm/platform",
"modality": "observation",
"content": {
"kind": "text",
"text": "Connection pool exhaustion on api-3 cleared by raising max_conns to 400. Held for 48h, then triggered replica lag — the real cause was a missing index on the new query path."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "pagerduty:inc-9921:resolution"
}'03 Recall before recommending
The pack returns what has actually been tried against this service, with what happened next attached.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:oncall")
pack = client.recall(
scope="ws:itsm/platform",
query=alert_summary,
view="holistic",
include=["episodes", "facts", "beliefs"],
budgets={"max_tokens": 900},
)
reply = llm.respond(alert_summary, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
Your incident history is a map of your weaknesses
Topology, credentials mentioned in passing, and a chronological record of every way the platform has failed. It is the single most useful corpus an attacker could ask for.
CortexDB is a single container. It runs on your own hardware, inside your VPC, or air-gapped — with the embedding and generation calls pointed at a local model if nothing may leave at all.
docker run -d --name cortexdb -p 3141:3141 -v cortexdb-data:/data cortexdb/cortexdb:latestDeployment options, model routing and the enterprise notes are on the download page.
The same infrastructure, a different mixture
Each of these leads with a different memory job, pulls from a different set of sources, and needs a different call. <a class="ul" href="../index.html">All of them, by job</a>.
Bring the workflow that gets it wrong.
One command starts a local instance with its own volume. The changelog carries every release behind it.