Forty thousand series, and three that matter
An investigating agent does not lack data. It lacks a way of deciding which of an enormous, mostly irrelevant signal surface is about the thing that just broke.
High cardinality is a selection problem
The dashboards are fine. The failure is in what an agent pulls into a finite window when it is asked why something moved.
Everything correlates with everything
At sufficient cardinality, dozens of series move together during an incident. Ranked by correlation they are all strong candidates; as explanation almost all of them are noise, and nothing distinguishes the two.
The last investigation of this anomaly is gone
The same spike was investigated in March and found benign. The conclusion lives in a thread, unattached to the signal that produced it, so it is investigated again from scratch.
The threshold that fired is not the threshold that matters
SLOs and alert rules change. An agent reasoning about a past incident applies today's definition to yesterday's data and reaches a confident wrong conclusion.
Mostly decision context. 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.
Selection weighs state, validity and relationships — not similarity alone
What gets into the window is chosen on how a candidate relates to the service, the change and the material already selected — not on how strongly it happens to correlate.
- Fewer, better signals in the window.
- The strongest correlation stops winning by default.
- Evidence travels with the conclusion.
What this anomaly turned out to be last time
Investigation, conclusion and outcome held together, so a known-benign spike is recognised as one.
Which SLO was in force
Definitions change. A past incident is judged against the threshold that actually applied.
One picture across the fleet
Parallel agents contribute to one investigation instead of four overlapping ones.
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 explanation is never in the telemetry
The signal says what moved. What it meant was worked out in a thread, a ticket and a change record.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,jira]'02 Write the conclusion against the signal
An investigation that ends in a thread is an investigation that will be repeated. Attach the finding to the thing that triggered it.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:obs/platform",
"modality": "observation",
"content": {
"kind": "text",
"text": "The nightly p99 spike on checkout is the batch reconciliation job, not a regression. Benign, recurring, third time investigated — do not page on it."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "obs:checkout-p99:investigation-03"
}'03 Recall before investigating
The pack returns what has already been concluded about this signal, on a budget that leaves room for the current data.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:investigator")
pack = client.recall(
scope="ws:obs/platform",
query=anomaly_summary,
view="holistic",
include=["episodes", "facts", "beliefs"],
budgets={"max_tokens": 900},
)
reply = llm.respond(anomaly_summary, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
Telemetry is a live map of how your platform is built
Service topology, dependency structure, traffic shape and every way the system has failed. Aggregated in one memory it is more revealing than any architecture document you have.
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. All of them, by job.
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.