Industrial agent memory as infrastructure

Context

Industrial and operational agents do not live in a chat window. They sit next to assets, alarms, maintenance records, and human interventions. The useful question is not “can the model answer?” It is “can the system remember the operational history that makes an answer responsible?”

This write-up is a public technical treatment of that problem: memory architecture, retrieval, provenance, and evaluation. It is not a dump of a private deployment.

Problem

Chat history is not memory. Logs are not memory. A vector store of undifferentiated chunks is usually not memory either.

What the agent needs is a structured record of: what the asset was, what happened, what failed, what a human did, what the agent decided, and which evidence supported that decision. Those records have different lifetimes, different access patterns, and different costs of being wrong.

Constraints

Provenance is non-negotiable. A retrieved “fact” without a source is a liability in an operational setting.

Memory writes must survive process restarts and be inspectable by humans.

Retrieval must degrade gracefully: missing memory should be visible, not silently filled by the model.

Evaluation has to include retrieval correctness, not only final-answer fluency.

Architecture

Asset and operational data produce events. Events are written into a memory layer that distinguishes operational history, failure records, and intervention records. Retrieval is a query against that layer with explicit filters (asset, time, failure class), not a single similarity search over a blob of text. Reasoning consumes retrieved items plus their provenance. Decisions are written back as new memory.

Engineering decisions

Separate event log from derived memory. The log is append-only evidence. Memory is a queryable projection.

Store provenance with every memory item: source system, timestamp, record id, and the transform that produced it.

Prefer typed memory objects (failure, intervention, observation, decision) over a single embedding namespace.

Make “I don’t know / I don’t have the record” a first-class agent result.

Tradeoffs

A single vector index is fast to stand up and weak at time, identity, and negation (“this repair was already tried”).

A relational or document store with optional embeddings is more operationally honest: you can ask precise questions, then rank.

Summarization compresses context and destroys the ability to audit. Use summaries as indexes, not as the only copy of the truth.

Failure modes

Silent overwrite of a failure record by a later summary.

Retrieval that returns similar-but-wrong assets.

Clock and timezone errors in maintenance history.

Feedback loops where the agent’s own decisions pollute future retrieval without being labeled as such.

Validation

Golden queries: given a known operational history, retrieval must surface the relevant failure and intervention, with provenance intact.

Negative tests: the agent must refuse to invent a maintenance event that is not in memory.

Replay: the same event log should rebuild the same memory projection.

Lessons

Agent memory is an infrastructure problem: schemas, durability, retrieval contracts, and evaluation.

If you cannot point to the evidence, you do not have a memory system. You have a prompt with souvenirs.