What is Semantic Memory in AI SRE?

Every investigation begins with orientation. What service is this, what depends on it, what changed recently, and where should the search start?

Semantic memory is our term for the part of the system that carries that environment context into the investigation. In Cleric’s architecture, it is the environment model behind the agent. The label is not standard SRE terminology, but the need is familiar: production investigation gets slower and less reliable when the system has to rediscover the environment on every alert.

What Lives in the Model

Semantic memory typically includes things like:

• what services exist
• how they depend on each other
• what infrastructure they run on
• which teams own them
• what changed recently
• what tools and dashboards are relevant

This is orientation data. It does not solve the incident by itself, but without it, the investigation starts blind.

Why Orientation Matters

An experienced engineer does this almost subconsciously.

They see an alert and immediately ask:

• is this service critical or noisy
• what sits upstream and downstream
• did something deploy recently
• is this one of those systems with weird expected behavior

That orientation step is work. It takes time. In large environments, no single person can do it well for every service.

Semantic memory reduces the amount of investigation time spent on basic orientation.

Where It Comes From

There is no single canonical source.

Useful semantic memory often comes from a mix of:

• Kubernetes and cloud inventory
• deployment systems
• code repositories
• observability configuration
• service catalogs and internal docs
• prior investigations that revealed hidden relationships

The goal is not to build a perfect map. The goal is to build one that is good enough to guide investigation and that can be corrected as reality changes.

Why Runtime Reality Beats Static Diagrams

Architecture diagrams are useful, but they age quickly.

Runtime systems accumulate all kinds of undocumented behavior:

• temporary services that became permanent
• shared databases nobody wants to admit are shared
• routing rules that only matter under specific traffic patterns
• background jobs that change what “normal” means at certain times

Semantic memory has to deal with that mess. If it only reflects intended design, it will mislead the agent.

Where the Environment Model Fails

This layer is useful, but it still has clear limits.

It can be wrong because:

• integrations are incomplete
• ownership metadata is stale
• runtime topology diverged from declared topology
• recent changes were not captured yet
• the system inferred a dependency that is merely correlated

That is why semantic memory should guide the search, not close the case.

How It Works With the Other Layers

Semantic memory tells the system what the environment looks like.

Episodic memory tells it what happened before.

Procedural memory tells it how the team tends to investigate.

You need all three. Orientation without history is slow. History without topology is dangerous. Procedure without context is just a script.

How Cleric Frames It

When we say semantic memory, we mean the continuously refreshed operational context the agent uses to orient:

• topology
• dependencies
• owners
• recent changes
• relevant sources of evidence

The value is simple. The agent should spend less time asking “where am I?” and more time answering “what changed and does it explain the symptom?”