Organizational Memory Requires Intentional Design
Updated: Sep 15
In my last article, I explored an idea that has continued to stay with me:
What if one of AI’s greatest contributions to the enterprise isn’t simply automation, but organizational memory?
I started thinking about organizations differently.
Companies already generate extraordinary amounts of information. Emails, contracts, meetings, financial reports, policies, project documentation, customer interactions, risk assessments, system logs, presentations, forecasts; the list is endless.
Yet having information and having memory are not the same thing.
That distinction has become increasingly important to me.
Because if we are going to build AI systems capable of remembering an organization, there is a much harder question we eventually have to answer:
What should the organization remember?
And once we answer that, several more questions immediately follow.
Who decides what becomes memory?
Who owns it?
What happens when two pieces of organizational memory contradict each other?
Should failures be preserved?
Can memory be rewritten?
When does an exception become precedent?
And perhaps most importantly:
How do we prevent organizational memory from becoming nothing more than an enormous collection of everything that has ever happened?
The more I’ve thought about these questions, the more convinced I’ve become that organizational memory isn’t primarily a storage problem.
It is a design problem.
And organizations should probably begin thinking about that design now.
Not Everything Deserves to Become Memory
Imagine a large enterprise operating every day.
Millions of emails.
Thousands of meetings.
Customer transactions.
Chat messages.
Presentations.
Documents.
System events.
AI conversations.
Agent actions.
If we simply capture everything, we haven’t necessarily created organizational intelligence.
We’ve created accumulation.
So there has to be a threshold where information becomes memory.
I don’t believe that threshold will be identical across organizations.
It should reflect what the organization is trying to accomplish.
A company might begin with its strategic priorities.
What has leadership publicly committed to accomplishing?
What objectives has the board established?
Where has capital been allocated?
What risks are leaders managing?
What outcomes matter to customers, employees, shareholders, regulators, and communities?
From there, information could be evaluated against those priorities.
For example:
Does this information materially affect a strategic objective?
Did it influence a significant allocation of capital?
Does it create or reduce risk?
Did it materially influence a customer or employee outcome?
Did it contribute to an important decision?
Could the decision establish precedent?
Did something happen that future leaders could learn from?
Did an action in one part of the organization create consequences somewhere else?
Those questions begin separating information from institutional knowledge.
And I think this distinction matters because importance and permanence aren’t the same thing.
Something can be important enough to remember today without deserving to remain organizational memory forever.
That leads to two separate questions:
Should we remember this?
And:
How should we remember it?
Different Kinds of Memory
As I’ve worked through this idea, I’ve started thinking that organizational memory may need different levels. At the lowest level is transactional information.
Routine emails. System events. Ordinary status updates. Transactions. Conversations. Most of this information may need to exist for operational, regulatory, or legal reasons, but not everything needs to become institutional memory.
Above that is operational memory.
This helps explain how the organization actually functions:
Processes.
Workflows.
Dependencies.
Recurring exceptions.
System relationships.
Operational lessons.
Then there is something I think is even more important:
Decision memory.
Organizations are generally very good at recording what they decided. I’m more interested in preserving why they decided it.
Imagine being able to reconstruct a significant decision years later and understand:
Decision
Evidence
Assumptions
Alternatives considered
Trade-offs
People involved
Risks identified
Exceptions made
Expected outcome
And then, months or years later:
Actual outcome
Lessons learned
That is much richer than storing a PowerPoint presentation showing the final recommendation.
Over time, those individual decision memories could potentially create something even more valuable: Institutional memory.
Patterns begin emerging across decisions.
Maybe leadership repeatedly accepts additional cost to reduce a certain category of risk.
Maybe an assumption used in forecasting has been wrong three years in a row.
Maybe something classified as an “exception” happens in the majority of applicable cases.
Maybe decisions involving certain cross-functional dependencies consistently take longer or produce unexpected consequences.
At that point, AI isn’t simply retrieving documents. It is helping the organization understand how it behaves over time.
What Happens When the Organization Contradicts Itself?
This might be one of the most fascinating parts of the problem.
Imagine the policy says one thing.
An executive says another.
Operational teams have developed a workaround.
And historical decisions show that exceptions have repeatedly been approved.
Which one represents the organization?
My answer is:
Preserve all of it.
I don’t think the AI should be given the authority to simply declare one version the organizational “truth.”
Its role should be different.
The AI’s job is not to declare organizational truth. Its job is to preserve evidence, surface contradictions, reconstruct context, and make the organization’s reasoning visible to the humans accountable for judgment.
If an executive decision contradicts policy, don’t erase the contradiction.
Capture it.
What did the policy say?
What decision was made?
Who made it?
Why?
What circumstances existed?
Was an exception formally approved?
What outcome was expected?
What actually happened?
Did the policy subsequently change?
Now the contradiction itself becomes information. And over time, contradictions may reveal patterns.
Imagine an AI telling leadership:
This policy has been overridden 14 times during the last 18 months. Eleven of those exceptions involved the same business condition. That doesn’t automatically mean the policy is wrong. Maybe leaders are repeatedly making poor decisions. Maybe the policy hasn’t kept pace with reality. Maybe the organization hasn’t clearly defined its exception process. Maybe the operating environment has changed.
AI doesn’t have to determine which explanation is correct to make the contradiction valuable. It can put the evidence on the table. Humans still have to exercise judgment.
Failure Belongs in Organizational Memory
This brings me to another principle I feel strongly about.
Organizational memory should not become a corporate highlight reel.
Failures belong in memory. Bad assumptions belong in memory. Projects that didn’t deliver belong in memory. Wrong forecasts belong in memory. Uncomfortable disagreements may belong in memory. Decisions leadership wishes it had made differently belong in memory. Some of the greatest lessons available to an organization come from things that didn’t work. If AI is going to help future leaders make better decisions, then preserving only successful outcomes would create an incomplete understanding of the organization.
Actually, it may create something worse.
If we teach AI only the history an organization is proud of, we won’t create institutional intelligence. We may create institutional mythology.
There is an enormous difference between the two.
The objective shouldn’t be to preserve a flattering version of organizational history.
The objective should be to preserve enough context for future leaders to learn from it.
When Does an Exception Become a Precedent?
This creates another interesting challenge. Organizations aren’t black and white.
Policies matter.
Standards matter.
Governance matters.
But circumstances also matter.
A crisis may require an organization to behave differently. An important customer situation may require escalation. A market disruption may require an unusual decision. A new technology may create circumstances that weren’t contemplated when a policy was written.
So I don’t think an intelligent system should necessarily respond:
POLICY VIOLATION. ACTION DENIED.
Instead, imagine:
This decision differs from established organizational policy and historical precedent. Please document the circumstances and rationale for the deviation.
Perhaps that decision is classified as:
Approved Exception.
Emergency Exception.
Experimental Decision.
Policy Deviation.
Potential New Precedent.
Then something important happens. The organization learns. One exception may remain an exception. Twenty similar exceptions might reveal something entirely different.
Imagine leadership receiving this observation:
This behavior continues to be classified as an exception, but it occurred in 68% of applicable situations during the past two years.
At that point, the organization has a question worth discussing.
Is this still an exception—or has the organization changed without formally acknowledging it?
Can AI Learn What Kind of Company We Are?
This is where my thinking moves beyond documentation.
Every organization has values.
Most companies publish them.
Integrity.
Customer focus.
Innovation.
Responsibility.
Collaboration.
Excellence.
But organizational values become much more interesting when two good things conflict.
What happens when customer experience conflicts with risk?
What happens when speed conflicts with governance?
What happens when innovation conflicts with regulatory uncertainty?
What happens when an important customer requests an exception?
What happens when the financially attractive decision isn’t necessarily the decision most aligned with the organization’s stated principles?
That’s where values stop being words on a website and start becoming judgment. I wonder whether organizations could eventually develop something resembling an organizational judgment layer for AI.
Instead of merely telling an AI system, “Integrity is one of our values,” organizations could use scenarios.
If this happens, how would we respond?
Now change one variable.
Does the answer change?
Increase the financial impact.
Does the answer change?
Increase the customer impact.
Increase regulatory risk.
Make the customer strategically important.
Introduce an ethical concern.
At what point does the organizational decision change?
This reminds me of scenario-based approaches used in behavioral and social research.
Over time, organizations could begin documenting not only what they say they value, but how they interpret those values when trade-offs become real. And the gap between those two things could itself become valuable organizational intelligence.
The Technology Is Starting to Catch Up
What’s fascinating is that pieces of this future are already emerging.
ServiceNow, for example, is developing AI Control Tower capabilities that centrally inventory and govern AI assets, connect them with business services and technology through its CMDB and data model, and manage areas such as lifecycle, risk, compliance, monitoring, evaluation, and value. Amazon Web Services is addressing another part of the problem through Amazon Bedrock AgentCore Memory. Its architecture distinguishes short-term events from durable long-term knowledge, with strategies including semantic, episodic, summarization and custom memory. AWS has also introduced metadata for long-term memory, allowing memories to be tagged and selectively retrieved rather than treating every memory identically.
Google Cloud is exploring similar territory with Memory Bank. Interestingly, its memory-generation process doesn’t assume everything deserves to persist; Google describes determining whether information is meaningful enough to become memory. Memory Bank also supports retrieval of persistent memories, and newer capabilities include memory revisions and permissions restricting who can read or write particular memory scopes. Salesforce is connecting agents with structured and unstructured enterprise information through Data 360, while its newer Agentic Memory and Context capabilities can preserve past conversations, decisions and actions and provide governed context according to an organization’s existing security model.
And Microsoft is tackling another essential piece: identity and accountability for AI agents. Microsoft Entra Agent ID provides purpose-built identities, authentication, authorization, governance and lifecycle controls for agents. Microsoft also requires human sponsorship in its identity-governance model so responsibility doesn’t disappear simply because an AI system acted. None of these products individually represents the organizational memory I’m describing.
That’s actually what interests me.
The pieces are appearing.
Memory.
Identity.
Permissions.
Governance.
Enterprise data.
Context.
Observability.
Workflows.
AI agents.
The question becomes how organizations intentionally connect these capabilities into something larger.
The Platform Shouldn’t Become the Memory
That leads to another important distinction.
An organization may use ServiceNow, AWS, Microsoft, Google Cloud, Salesforce, Oracle, SAP, Tableau, Power BI, or dozens of specialized platforms.
But I don’t believe any one technology vendor should become the organization’s institutional memory.
Platforms will change. Contracts will end. Architectures will evolve. Companies will merge. Applications will become obsolete. New AI providers will emerge.
The organizational memory must therefore exist conceptually above the individual technology platform.
That doesn’t necessarily mean one giant centralized database.
It means the enterprise needs standards governing portability, interoperability, provenance, retention, deletion, permissions, traceability, and auditability.
The organization should always be able to answer:
Where did this memory originate?
Who had authority to create or modify it?
Which systems contributed to it?
What evidence supported it?
Which version was available when the decision was made?
Who or what accessed it?
How long must it remain?
When should it be reviewed?
When should it be retired?
That’s not simply data governance. That’s memory governance.
Organizational Memory Also Needs a Lifecycle
Memory shouldn’t just accumulate forever. Different information requires different review frequencies.
Some information must be reviewed when an event occurs.
A contract renewal.
A regulatory change.
A significant incident.
A leadership transition.
A material change in utilization.
A strategic shift.
Other memories may benefit from monthly, quarterly, or annual review.
Imagine a quarterly leadership review that doesn’t simply ask:
How did we perform?
It also asks:
Which assumptions did we make last quarter?
Which proved correct?
Which proved incorrect?
Which exceptions are becoming patterns?
What did we learn that should change how we make decisions?
Then imagine an annual review:
What did we believe twelve months ago?
What actually happened?
Which risks did we underestimate?
What did we classify as temporary that became permanent?
Which policies were repeatedly overridden?
Which institutional lessons deserve to survive into next year?
What information no longer deserves to influence future decisions?
I can imagine organizations eventually having something resembling an Organizational Memory Health Report alongside financial, risk, technology, and operational reporting.
Maybe it evaluates:
Memory coverage.
Freshness.
Contradictions.
Decision traceability.
Prediction accuracy.
Exception frequency.
Cross-functional dependencies.
Governance.
Access.
Retention.
Institutional learning.
Conceptual Dashboard View
At that point, we’re no longer measuring only how well the company performed. We’re beginning to measure: How well did the company learn?
And Who Owns the Memory?
This may ultimately become one of the most important governance questions.
When information moves between internal databases, cloud providers, SaaS platforms, AI models, agents, APIs, and external partners, contractual and legal questions around ownership, control, retention, and deletion can become complicated.
But there is a principle I believe enterprises should protect:
An organization’s ability to reconstruct its institutional memory should never depend entirely on one technology provider.
The company needs sufficient control over the information, provenance, and decision records necessary to reconstruct its own history.
Because organizational memory isn’t merely another dataset. Eventually, it may become part of the organization’s intellectual capital.
Maybe the Goal Isn’t Perfect Memory
The more I work through this idea, the less I think the objective should be to create an organization that remembers everything. Humans don’t work that way. And perhaps enterprises shouldn’t either. Some information should remain operational. Some should become memory.
Some memories should become institutional knowledge. Some should be reviewed. Some should be challenged. Some should be superseded. Some may eventually need to be forgotten. And mistakes should remain visible long enough for us to learn from them.
That means organizational memory isn’t simply a technology implementation.
It requires
Executives
Boards
Technology leaders
Risk professionals
Legal teams
Data leaders
Business operators
And eventually AI systems themselves.
All participating in deciding what the organization should carry forward.
Building Beyond the Prompt
My first reflection on organizational memory started with a relatively simple idea:
AI may eventually need to understand not only how an organization operates, but how it has learned over time.
I’m realizing that statement creates a much larger challenge.
Before AI can meaningfully use organizational memory, we have to intentionally design what organizational memory means.
What deserves to become memory?
What remains information?
Who can access it?
Who can change it?
How do we preserve contradictions?
How do we distinguish exceptions from precedent?
How long should something remain influential?
How do we preserve failures without allowing outdated conclusions to contaminate future decisions?
And who remains accountable when AI begins using decades of organizational experience to influence what happens next?
I don’t have all of those answers yet. That’s actually why I find this conversation so interesting. The technology is advancing quickly enough that these questions are moving from theoretical discussions toward practical leadership decisions. And perhaps that’s where organizations should begin.
Not by asking:
“How much can our AI remember?”
But:
“What kind of organization do we want our AI to remember?”
Because the smartest organizational memory may not belong to the company that remembers the most. It may belong to the company that understands what deserves to be remembered, what needs to be reconsidered, and what it is finally time to forget.
Comments