Operational Reality: why AI memory is the wrong problem to solve

"Why did we change the product terms on the website?"
"They were changed by Agent #12 in tool call #32 because Decision #234 was ratified by John on August 12th in response to Regulatory Change Y."

This is the type of conversation we should be able to have.

The internet and academic papers talk endlessly about context drift and agent amnesia, treating it as a semantic problem with a vector database or flat files as a crutch.

I see it differently. It's a systemic problem that must be tackled using established concepts from distributed systems. It requires the right mindset and an infrastructure that actively supports it.

Shift the mindset away from solving AI memory and context drift as an isolated problem.

I am not a sociologist, nor have I read 500 pages of 1970s and 80s theory. But organization theorists have pointed out for decades that, at its core, an organization is simply a network of decisions reacting to inputs (1).

It operates through an internal feedback loop that results in touchpoints with the outside world, followed by an external feedback loop (2), like a product terms page on a website:

Input -> Reasoning -> Decision | <- input from the outside world

I call this total decision surface area the Operational Reality.

Reasoning and decisions, this is precisely where AI has landed, acting as an active catalyst that drastically increases speed and causes the Operational Reality to shift faster than ever before.

Most "memory" theory I see people writing about online focuses either on an automated agent system or a human workflow where AI is just a chat in a side panel. Both models have their place.

However, the decision network in a modern organization is a hybrid graph, because the nodes in the network are driven by humans (who hold authority) and AI agents (who hold execution speed). If we don't bind them together through a shared state, everyone ends up running in opposite directions.

What is needed is a symbiotic model, kept separate from context. And there is a fundamental need to decouple reasoning from decisions for several reasons:

• Decisions have explicit types and transition through deterministic states.
• Human control is preserved without becoming an execution bottleneck.
• Business continuity: humans and AI models get swapped out over time; the underlying decisions remain.
• Auditability.
• Clean separation of technical domains and performance optimization.

Decisions: the Operational Reality, updated in real time, regardless of velocity.

What this looks like as a state machine

What states can decisions exist in? Non-exhaustive, but here is the actual flow from the implementation this essay is grounded in (Smeldr's orchDecisionFlow):

proposed → ratified → superseded
              ↓
   pending-re-evaluation → ratified
              ↓
          archived

Five states, five real transitions, not a metaphor. Every transition carries an actor, a timestamp, and a reason.

What relationships do decisions hold to each other? The graph is fully searchable, queryable, and exportable. In the implementation, a relation is a typed, directional edge between two content items:

addresses    Decision → Decision   (this decision resolves an open question in that one)
supersedes   Decision → Decision   (this decision replaces that one)
contradicts  Decision → Decision   (non-directional, flags a real conflict)
depends_on   Task → Task
derives_from Task → Goal
investigates Task → Decision

Nothing exotic: a source, a target, a kind, an optional confidence score. What makes it useful is that the reverse index is free, given a decision, you can always ask what depends on it.

This layer enables structured reasoning, such as:

• "I want to refactor this section of the codebase, has an architectural decision already been made here?"
• "If I want to modify this decision, which other decisions will it impact?"
• "I am reviewing our entire Operational Reality to identify where we can optimize costs."
• "Which decisions are currently blocked because they are waiting on another upstream decision?"
• "I am starting this task, what is the verified decision base for execution?"

Continuous Structural Sweeping & Cascading Invalidation

Operational Reality emits signals on state transitions, allowing you to plug in your own custom monitoring, automated triggers, or downstream actions.

The structural sweep that exists today, SweepStructural, is real and shipped:

func (*RelationStore) SweepStructural(
    ctx context.Context,
    check TargetChecker,
    onStale func(ctx context.Context, edge RelationEdge),
) (flagged int, skipped int, err error)

It walks every active relation, checks whether the edge's target is still alive, and marks the edge invalid_at the moment it isn't, then calls your callback. That part is real and dogfooded daily.

What it does not do yet is cascade transitively, if A goes stale, that does not yet automatically propagate to everything that depends on A. Full cascade (severity weighting, aggregated "declared tension" across a chain) is designed, not built. Worth knowing if you're evaluating this for a use case that needs the full chain today, not just the one-hop check.

Built-in Auditability

The conversations that are already taking place. But they are hard to answer with authority, because too much lives in interpretation and scattered datapoints.

Here is what an audit record actually carries today:

type AuditRecord struct {
    Timestamp     time.Time      // when the lifecycle signal fired, UTC
    Signal        LifecycleEvent // e.g. AfterPublish, AfterArchive
    ContentType   string         // "Decision", "Post", etc.
    Slug          string         // the item's slug at the time
    ActorID       string         // stable UUID of the authenticated actor
    ActorRole     string         // "guest" / "author" / "editor" / "admin"
    PreviousState string         // state before the transition
}

Worth being precise about what this gives you and what it doesn't. ActorID is a UUID, not a name, Smeldr deliberately does not model people, only credentials. There is no built-in call-sequence numbering across a session. And the causal link from "the terms page changed" to "because Decision #234 was ratified" is not automatic today, it is a relation you assert explicitly. The opening dialogue is the target this architecture is built toward, not a transcript of a query that runs today.

What's real: every state transition on every typed content item gets a durable, queryable audit row, with no gaps and no opt-out.

Human Governance Without Bottlenecks

NOT everything needs manual approval. Classify decisions along three dimensions:

1. Scope / Impact Area (affected department, team, or domain)
2. Authority Rank (foundational vs. granular detail)
3. Reversibility (is the decision truly permanent or destructive?)

All three are real fields in the implementation today, not aspirational: Decision.Scope (existing), a ranked, org-configurable RuleType, and a Reversibility type resolved by InferReversibility/ResolveReversibility.

Ratifying, amending, or archiving decisions happens with full visibility into the consequences, enabling safe delegation with complete clarity over the downstream cascade.

One honest caveat: the three fields exist and are populated today, but the enforcement layer, the check that actually compares a new ratification against the authority graph and flags a conflict before it happens, is designed but not built yet. The classification is real. The automatic safety net on top of it is roadmap.

Does this solve the memory problem?

It doesn't require individual humans to remember every conversation and document.

It doesn't rely solely on stuffing millions of tokens into a context window.

Semantic relationships alone do not provide true confidence for mission-critical decisions.

What is actually needed is a shared, deterministic understanding of reality right now.

What is needed is Operational Reality.

---

This piece first appeared on Smeldr's Thinking page.

1. Niklas Luhmann, Organization and Decision, ed. Dirk Baecker, trans. Rhodes Barrett, Cambridge University Press, 2018.
2. Karl E. Weick, Sensemaking in Organizations, SAGE Publications, 1995.