Use case IT service management

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.

01 What breaks

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.

01

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.

02

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.

03

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.

02 What it’s made of

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.

Dominant · Episodic memory

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.
Shared memory

One history across the rota

What the last responder learned is what the next one starts with, at 3am, without waking anybody.

Valid time

The architecture has changed since

A fix that was correct against last year's topology should not be returned as current advice.

Decision context

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.

03 What feeds it

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.

Install
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.

Store an experience
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.

Recall it
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.

04 Where it runs

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.

Run it
docker run -d --name cortexdb -p 3141:3141 -v cortexdb-data:/data cortexdb/cortexdb:latest

Deployment options, model routing and the enterprise notes are on the download page.

05 The rest

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. All of them, by job.

Assistant agentspersistent memory Commerce agentspersistent memory AdTechpersistent memory Games & multiplayerpersistent memory Data residencypersistent memory Employee supportvalid time Contract & legal opsvalid time Financial opsvalid time Capital marketsvalid time Healthcarevalid time Customer supportepisodic memory Clinical operationsepisodic memory Financial servicesepisodic memory Sales agentsshared memory Customer successshared memory Government & defenceshared memory Research agentsdecision context Coding agentsdecision context Voice AIdecision context Observabilitydecision context

Bring the workflow that gets it wrong.

Not the demo. The one that answered from the wrong version, or asked a question it had already been told the answer to.

Talk to us Download