Everyone talks about giving agents memory as if remembering were harmless.

It is not.

The moment a remembered fact can satisfy a precondition, lower the cost of an action, suppress a verification step, unlock a tool, or change the plan, memory is no longer just context. It has become part of the application’s control plane.

That means the important question is not simply:

What can the agent remember?

It is:

What is a memory allowed to change?

That question became concrete for me during the Embabel workshop. The incident worker I built kept a requiresApproval flag inside the runbook’s Java, deliberately outside the model’s output type, so that nothing the model produced could flip it. I wrote about that setup in From Prompting to Planning: What Embabel Taught Me About Agents , where the blackboard is typed working memory. Actions consume domain objects from it, produce new objects, and the planner reevaluates what is possible after every result.

I was pleased with that boundary. Then I started thinking about memory and realized I had only closed one door. The model cannot set requiresApproval. But if a remembered fact can place an object on the blackboard, it does not need to.

I still believe the typed blackboard is one of Embabel’s most important ideas. But it also exposes something deeper: state is not passive when its presence changes what the system can do next.

The blackboard makes memory consequential

The blackboard pattern did not begin with LLMs. The Hearsay-II speech-understanding system used a global working memory so that independent knowledge sources could contribute partial results to a shared problem. Lesser and Erman’s 1977 retrospective on the architecture put it plainly: “it is not necessary for a KS to know the names of the other KSs involved.” Those specialists did not call one another. They coordinated through the evolving state of the blackboard.

The same paper is honest about what that cost. The authors concluded that complete independence among knowledge sources “resulted in a significant amount of overhead, and thus seems not to be worth the cost.” Decoupling has never been free. It is worth knowing that the people who invented this pattern said so first.

Embabel brings that classical AI pattern into a modern, typed application model. According to the Embabel 1.0 documentation , an action’s inputs are resolved from the blackboard, its output is added automatically, and the contents help determine the next plan.

Consider a simplified code-review agent:

ChangedCode loadChange(ReviewRequest request)

RepositoryPolicy loadPolicy(ReviewRequest request)

ReviewFindings review(
    ChangedCode change,
    RepositoryPolicy policy)

MergeRecommendation recommend(
    ReviewFindings findings,
    VerificationResults verification)

The presence of ChangedCode and RepositoryPolicy makes the review action possible. ReviewFindings may make verification possible. Only after VerificationResults exists can the agent produce a MergeRecommendation.

Nobody has to put the entire state into a prompt and ask a model what to do next. The Java types define the world. The blackboard represents what is currently known about that world. The planner uses those facts to determine which declared capabilities are available.

Now imagine the agent remembers this statement from an earlier conversation:

This team usually skips integration tests for small changes.

What exactly is that statement?

Is it an observation? A developer preference? A temporary exception? An approved repository policy? Or an instruction that should suppress the verification action in every future review?

Those are not different storage formats for the same memory. They represent different levels of authority.

Memory needs a promotion path

Most discussions about agent memory jump directly from something being said to something being stored. That skips the most important architectural decisions.

Let me narrow the claim before I make it, because parts of this already exist. DICE ships an admission pipeline whose gates can persist a proposition, reject it, demote it, or hold it for human review, and it resolves a source into an AuthorityTier before scoring how much to trust what came from it. That is more than I expected to find when I went looking.

What it does not do is connect any of that to the planner. DICE gates how strongly a fact should be believed. Nothing gates what the agent is allowed to do once it believes it.

That gap is the only thing I am really claiming: if a remembered fact can satisfy a precondition, the step where it becomes that fact belongs in your application as an explicit, testable capability rather than an emergent property of a retrieval pipeline. What follows is what I would build in that gap. I have not yet run it in production.

A safer path looks more like this:

Observed → Retrieved → Remembered
                            ↓
                    [ promotion gate ]   rule or human decision
                            ↓
                   approved domain object
                            ↓
              may satisfy a planning condition

The first three steps are cheap and mostly automatic. Observed records what happened or what was said, along with its source. Retrieved may put that observation in front of a model when it looks relevant. Remembered keeps it as a proposition carrying confidence, scope, and an expiration. None of that is dangerous, because none of it has changed what the agent can do.

The gate is the design. Promotion converts a proposition into an approved domain object, and it happens because a rule fired or a person decided. Authorization is what promotion buys: only the approved type may satisfy a planning condition or permit an action with a side effect.

Most memories should never reach the bottom of that diagram. A memory system that promotes everything has not been designed. It has been switched on.

This is where strong typing can do more than structure an LLM response. It can encode the authority boundary:

record RememberedPreference(
    String statement,
    EvidenceReference evidence,
    double confidence,
    MemoryScope scope,
    Instant expiresAt) {}

record ApprovedRepositoryPolicy(
    RepositoryId repository,
    VerificationRequirements requirements,
    ApprovalReference approvedBy) {}

An action requiring ApprovedRepositoryPolicy cannot accidentally consume a RememberedPreference. The compiler, domain model, and planner all understand that these objects mean different things.

The model cannot promote one into the other merely because the wording sounds confident. Promotion must be a declared application capability with its own rules, evidence requirements, authorization, and audit trail.

That is the difference between remembering something and trusting it enough to act on it.

Not every memory should have the same effect

Memory does not arrive with a single blast radius. Treating it as though it does is how governance quietly disappears.

At the harmless end, a remembered preference changes how an answer is explained or formatted. Get it wrong and someone receives a bulleted list they did not ask for. The consequence never leaves the response.

One step up, memory shapes a recommendation. It ranks one option above another or surfaces the likely answer, while the agent still runs the required checks and shows its evidence. Being wrong here costs a little attention. It does not cost correctness.

Then the ground shifts. When a remembered object satisfies a precondition, removes an action from the plan, or makes one path cheaper than another, memory has stopped describing the work and started selecting it. Nothing in the transcript announces that transition. The plan simply comes out shorter.

At the far end, a memory unlocks a write, approves a deployment, waives a test, or exposes data to someone who was never cleared to see it. We are still calling this memory, and that is the problem. It is policy wearing a friendlier word.

The requirements have to climb with the effect. Provenance, confidence, scope, validation, approval, and revocation should all tighten as a memory moves along that line, and the temptation to apply one standard everywhere is really the temptation to apply the first one everywhere.

An agent should never remember something with more authority than the evidence that produced it.

I believed that was an architectural preference. While writing this I learned it is measurable. When Memory Becomes Authority , published in August by researchers at Tsinghua and East China Normal University, names the failure authority collapse: consolidation “preserves a claim while erasing the source constraints governing its authorized use, causing the stored memory to imply greater authority than its source permits.” That is the sentence above, stated more precisely than I stated it.

Their benchmark holds the claim and the downstream task fixed and varies only the authority of whoever supplied it. Across seven memory consolidators and seven models, authority collapse appeared in 48 of 49 configurations. Memories stripped of their source constraints produced unauthorized actions 50.3% of the time. Persisting an authority label alongside the fact took that to zero, and ordinary task success barely moved.

The fix was not a better model. It was carrying the authority with the fact.

Embabel does not make memory one giant bag of text

One reason I find Embabel useful for thinking about this problem is that it separates several concerns that are often collapsed into a single feature called memory.

These mechanisms can work together, but they are not interchangeable.

A conversation is evidence of what someone said. It is not automatically proof that the statement is true or that the person was authorized to establish policy.

A Context can carry objects across processes — the default ContextRepository keeps them in memory only, so durability is a deployment choice — but carrying an object forward does not make it authoritative. In fact, because context can seed a new blackboard before planning begins, it can change which actions run at all. That makes writes to cross-process context a security and governance boundary, not merely a caching decision.

The blackboard is working state for a process. It is also not automatically the model’s context window. Application code decides which typed inputs are given to an LLM, unless the application deliberately exposes broader blackboard access through tools. That is a valuable separation: the planner may know an object exists without blindly placing every object into every prompt.

A transcript is not a source of truth

Persisting conversation history is useful. It lets someone continue where they left off, refer to earlier messages, and avoid repeating information.

But a transcript contains uncertainty, corrections, misunderstandings, sarcasm, outdated preferences, and instructions that may have been valid only once. I have contributed my share of all six to a work channel.

Suppose a release manager says:

We can skip the extended test suite this time because production is down and this is the approved rollback.

A conversation store should preserve that statement. A memory system might extract that the team skipped an extended test. Neither should silently transform it into:

This repository does not require the extended test suite.

The first is an event with a specific incident, speaker, time, and approval context. The second is an organizational policy. Converting one into the other is an act of interpretation and promotion. It must not happen invisibly inside an embedding pipeline.

Enterprise systems already understand this distinction. An audit event is not a configuration value. A support note is not a customer entitlement. A developer comment is not an approved security exception. Agent memory should preserve those boundaries rather than flatten them.

Where DICE becomes exciting

Rod Johnson has argued that agent memory is not a greenfield problem . His point is that enterprises already have structured domain models, repositories, services, validation, and years of accumulated knowledge. Memory should connect to those assets rather than create a disconnected text-and-vector copy of the business.

I agree with that argument.

My question begins one step later:

Once memory is connected to the domain, what authority is it allowed to have inside that domain?

A word on the name, because I have used it twice now to mean two things. In my earlier post I used DICE the way the workshop used it: Domain-Integrated Context Engineering, the discipline of encoding organizational knowledge as executable Java first and handing the model only the facts it needs. Embabel DICE is that idea with a build file — the project attempting to carry the philosophy into a durable knowledge layer.

That is why I cannot wait to add it to this architecture once it reaches a stable release. Embabel’s blackboard gives an agent typed working state for the process in front of it. DICE models a Proposition as the system of record, with confidence, importance, decay, and grounding as first-class properties rather than metadata bolted on afterward, and it promotes those propositions into typed graph relationships instead of leaving them as free text.

As I write this, DICE is a separate, evolving open source project rather than a stable release. Its main branch is versioned 0.2.0-SNAPSHOT, carries an incubating badge, has never cut a tagged release, and builds against embabel-agent 1.5.0-SNAPSHOT rather than the 1.0 release I have been citing throughout this post. That makes it exciting to explore. It also means I would not yet present it as a production-ready feature of Embabel Agent 1.0.

Govern memory like code and policy

If memory can influence future execution, an enterprise memory design has to answer the same questions we already ask of any privileged input.

Start with where the fact came from. Every remembered proposition should trace back to a conversation, document, database record, tool result, person, or system event, and it should carry the identity of whoever made the statement along with the authority they held at the time. Someone saying “we always deploy on Fridays” in a chat thread is not the same class of fact as a release policy signed off by the team that owns the pipeline.

Both arrive as English sentences. Only one of them is a decision.

Alongside provenance sits scope. A memory that is true for one user, one conversation, or one repository is not automatically true for the team, the tenant, or the organization. Quietly widening that boundary is one of the easier ways to turn a helpful system into a confidently wrong one.

Then ask how strongly the system believes it, and for how long. A fact that was directly observed is different from one inferred once, which is different again from one reinforced across many interactions, contradicted later, or explicitly approved by a human. Confidence has to be represented, not assumed. So does lifetime. Something has to say when a memory expires, which source change invalidates it, and whether a new policy version supersedes it the moment it lands rather than whenever the cache happens to turn over.

Promotion is the moment memory stops being context and starts being permission. It is the moment most worth guarding.

What remains is the ability to undo and to explain. The organization should be able to remove a memory and every promoted decision derived from it, and a user should be able to exercise applicable privacy and deletion rights against it. After the fact, we should be able to reconstruct which remembered facts influenced a plan, which action they enabled, and why the system trusted them at that moment.

That last one is not a reporting feature. It is the difference between an agent you can operate and an agent you can only apologize for.

These are application architecture questions. A vector database, knowledge graph, or conversation store may support the implementation, but none of them answers the questions by itself.

The real memory boundary

In Data Is King , I argued that durable advantage comes from proprietary data plus the context, controls, and auditability surrounding it.

Agent memory makes that argument even more important.

The value is not that an agent can accumulate an unlimited history of everything anyone ever said. The value is that the application can preserve the right knowledge, connect it to the correct domain entities, retrieve it when useful, and control exactly how much authority it has.

Embabel’s blackboard makes the consequence visible because the presence of a typed object can change the plan. Context shows that selected state can cross process boundaries. Conversation persistence preserves what was said. DICE points toward a richer, durable knowledge layer.

But the application must still decide when remembered information becomes executable truth.

That decision should never be hidden inside a prompt.

It should be typed, governed, testable, observable, and auditable.

Because memory is not merely a feature that helps an agent answer the next question.

Memory is a permission to influence what the agent does next.