Operational Memory

Operational Memory is the tenant brain. As records reach a terminal state, the platform deterministically distills each one into a memory document and files it in a per-tenant index. Agents and chat then recall those documents by meaning of words, so a problem solved once does not stay novel. This is the difference between a system that logs resolutions and one that learns from them.

Note

This page describes recall (the read side). Capture (the write side) runs automatically at terminal-state seams with no configuration. There is nothing to switch on.

When you’d reach for it

An agent investigating an incident, or a person triaging one, wants to know whether the same symptom has been seen before and how it was closed. Instead of scanning tickets by hand, the agent calls one tool with the symptom in a few words and gets back the closest past resolutions, each with a link, a highlighted snippet, and the date it was resolved.

How recall works

The recall_operational_memory tool takes a query (usually the record’s short description) and returns the best matches. Up to three arms run and are fused:

• A full text search over the memory index (title weighted above body), matching keywords and their word stems.
• A fuzzy title match, so a misspelled or slightly reworded title still surfaces the right document.
• A semantic match over document embeddings, so a paraphrase still surfaces the right precedent: “SSO login failing” can recall a document titled “Entra token validation failure”. This arm runs when an embedding model is configured for the tenant.

Each result carries structured provenance: the source table and record id, a relevance score, which arms matched it, a highlighted snippet, a relative link to the source record, and the date it was resolved. Results are ranked by combined relevance, with a mild preference for more recent resolutions only when scores are close. Old precedent for a rare problem is still precedent.

Optional inputs narrow the search: scope restricts recall to one source table, k sets how many results to return (up to 10), and doc_kinds filters by document kind.

Attachments are part of the memory

Documents uploaded to records join the index automatically. Every hour, the platform extracts text from new attachments (PDF, Word, Excel, and plain-text formats) and files one memory document per attachment, so an invoice or purchase order attached to a record becomes searchable by its content: recall “PO-4711” and the result links to the record the invoice is attached to. Extraction is deterministic. Each attachment yields one memory document, and its text is stored in parts of about a page each, so a match on page 30 of a runbook finds the file just as a match on page 1 does. Very long files keep their first 120 parts, and the document says when the rest is not indexed. When an agent asks a question about a file, it is answered from the parts that match the question. Infected or unscannable files are never indexed, and deleting an attachment removes its memory document. Admins can turn the behavior off per tenant with the memory.attachments_enabled setting.

Opening a document

Recall tells you a document exists and shows a snippet of it. To read the rest, an agent calls read_knowledge_document with the doc_id from a recall result. Long documents come back in parts: each response says how much of the document it carries and gives the offset to ask for the next part, so nothing is silently cut short. Document content arrives labelled as data, never as an instruction to the agent.

Two kinds of document behave differently, on purpose.

A skill body is prompt source. Reading one needs the “view AI skill prompt bodies” capability on top of read access to the skills table, which agent service accounts do not hold: an agent reading another agent’s instructions is a way to steer it. Recall still surfaces a skill’s purpose, name, and activation rules to anyone who can read skills; the body stays behind its own gate.

An uploaded file is text a third party wrote, so its text is never handed to the agent. Instead the agent states what it needs to know, and a separate reader answers from the file. That reader has no tools of its own, so instructions hidden inside a document have nothing to act with, and its answer is checked before it reaches the agent: an answer that comes back shaped like an instruction is refused, and the refusal says a person should look at the file. There is no fallback that shows the raw text, because a quarantine with a way around it is not a quarantine.

The index comes to the agent

An agent does not have to remember to look. At dispatch, the platform builds a small index of what the archive holds about the matter at hand and places it in front of the agent beside its case file: titles and short previews of relevant past resolutions and findings, files attached to the triggering record, and open work by other agents on the same record. The index is bounded, and when entries are dropped for length it says how many. When the agent holds read_knowledge_document, each entry carries the document id, so a promising title is one call from its full content.

The index is a table of contents, not the content: no document body enters the agent’s context unasked, and previews from uploaded files are validated the same way the quarantined reader validates its answers. If building the index fails for any reason, the run proceeds without it.

The platform also keeps score. Every document surfaced to an agent, whether by the dispatch index or by an explicit recall call, is recorded, and opening one marks it as read. Over time this answers a question no log answers on its own: does the archive earn its place in every dispatch, and which of its documents actually get used.

Browsing and curating the archive

Admins can see the archive directly under Administration. The memory browser searches with the same engine agents use and shows each document’s kind, source record, and content, so “what does the platform actually know?” has a screen. What an admin sees there is still filtered by their own read permission on each document’s source record. Reading the archive needs the “browse operational memory” capability; changing it needs the “curate operational memory” capability, and every change is audited.

Three gestures keep the archive honest:

• Correct: edit a document’s title or body when it is wrong or stale. The document is re-embedded so semantic recall reflects the corrected text.
• Retire: take a document out of circulation. A retired document stops appearing in recall, in the dispatch index, and to agents, but it is not silently deleted: the row keeps who retired it, when, and why.
• Endorse: promote a document that keeps proving useful into a draft skill, through the same promotion path agents use. Endorsement is a gesture, not a second system.

Access follows the record

Recall is filtered per query to the caller’s read permission on each result’s source table, and it fails closed: if a permission check cannot be evaluated, that document is dropped, never shown. Secret and control-plane tables are never indexed in the first place, so they can never be recalled. An agent recalls exactly what its service account could already read. An attachment document follows the record it is attached to: it appears only to callers who can read the parent record’s table, and its link opens the parent record.

Deleting a record

Deleting a record removes its memory document the same way deleting an attachment removes that attachment’s document: nothing of its text is left for recall, or for read_knowledge_document, to return. It also closes any open or held agent pursuit on that record (the same move a record reaching a terminal state already makes), so a pursuit’s working notes stop being shown to a later run on that record, even though the row itself is kept as an audit trail. The archive copy of the deleted record is separate and unaffected: restoring a record from the archive does not restore its memory document or reopen its pursuit.

What the agent looked at, on the record

Under a finished run on a record, one grey line says what that run had in front of it: how many documents, of which kinds, how many were in the index it was handed at the start, how many it went looking for mid-run, and how many it opened. Expanding the line lists the titles.

That line shows counts, categories and titles. It never shows a document body, a source record id, or a link into the archive, because it is read by whoever can read the record, which is a wider audience than the archive itself. Each title is checked against the person reading it, at the moment they read it, using the same per-document rule recall uses. A document you may not read is not quietly left out of the list: the line says how many were withheld and why, and it counts a retired or deleted document separately, so “you do not have access to this” never reads the same as “this no longer exists”.

When the platform has no record of what a run was shown, the line does not appear at all. An archive that had nothing to offer and a run that predates this bookkeeping look identical from here, so the surface says neither rather than claiming the agent looked at nothing.

An empty result is an answer

When nothing matches, recall returns an empty result with a single hint to proceed with live probes. That is data, not an error: no precedent exists, and an investigator should note the absence of precedent in its finding rather than treat the search as failed.

When the semantic arm is unavailable

A tenant without a configured embedding model keeps working lexically: recall answers from the keyword and fuzzy arms, and nothing is flagged, because lexical-only is a valid configuration. When an embedding model is configured but the semantic arm fails (provider outage, timeout), recall still answers from the lexical arms and the response carries a degraded marker naming the reason, so a caller knows the semantic arm was down rather than assuming it searched everything.

For agent designers

Grant read_knowledge_document alongside recall_operational_memory so an agent that finds a precedent can actually open it, and so it can question an uploaded file on the record it is working.

Grant recall_operational_memory to an investigate or operator agent and it is told, through a seeded guidance skill, to recall first with the record’s short description before running live probes, to cite recalled records as evidence rather than assert unrecalled knowledge, and to pivot a promising hit into the record neighborhood before concluding. Recall finds the precedent; the Data Map shows its context.