What should workplace Super Intelligence remember? It should remember only information that creates durable workflow value, under a clear scope, owner, retention rule and source-precedence model. It should not use persistent memory as a substitute for current policy, live operational state or authoritative records.
This eduKateSG article owns the memory and personalisation layer of workplace Super Intelligence. Earlier articles explain context engineering, knowledge bases, documents, enterprise search, data architecture, freshness and access. This page answers what happens across interactions: which context should persist, which should remain temporary, how personalisation should work, and when memory must yield to newer authoritative information.
In this series, Super Intelligence is the practical machine-intelligence layer commonly described as artificial intelligence, generative AI, assistants, copilots, agents and connected automation. Memory can make SI dramatically more useful because the system no longer starts from zero. It can also make errors persistent, permissions harder to reason about and stale assumptions feel like current truth. Memory therefore needs governance, not just convenience.
The Core Distinction: Memory Is Not Truth
Memory is a retained representation of prior context. A source of truth is an authoritative system or document. The two can overlap, but they are not interchangeable.
A remembered preference such as “use concise executive summaries” may be safe and useful. A remembered fact such as “customer entitlement is Gold tier” may become stale and should refresh from the CRM before consequential action.
The Seven Memory Types
- Session context: temporary information needed for the current interaction.
- Task memory: state retained while one task or workflow is active.
- Project memory: durable context about an ongoing project.
- User preference memory: stable preferences such as format, style or working conventions.
- Relationship memory: context about customers, teams or recurring collaborators.
- Workflow memory: recurring instructions, exceptions and operational patterns.
- Organisational memory: durable knowledge shared across authorised users.
Each type deserves different retention, ownership and refresh rules. Treating every remembered item the same is one of the fastest ways to create stale or over-broad context.
Session Context
Session context is short-lived. It includes the current documents, question, recent messages and temporary working assumptions. Much of it should disappear when the task ends.
Temporary context is valuable because it reduces the need for long-term retention. Not everything useful now should become memory later.
Task Memory
Task memory persists long enough to finish a bounded unit of work. An agent investigating a support case may need facts gathered across several tool calls, actions already attempted and open questions.
Task memory should close or archive with the task. It should not silently become a permanent customer profile unless another workflow has a legitimate need.
Project Memory
Project memory preserves state across days or months: objective, decisions, milestones, current owners, constraints, unresolved questions and important sources.
Project memory is particularly useful for reducing context-reconstruction cost. It should distinguish stable decisions from live project state that must refresh from current systems.
Preference Memory
Preferences can include writing style, preferred output structure, recurring meeting format, coding conventions, units, working hours or communication choices.
These memories often have low volatility and high convenience value. They should still be reviewable because preferences can change.
Relationship Memory
A salesperson may benefit from remembered customer preferences, a manager from recurring team working patterns and an assistant from collaborator roles. Relationship memory can improve continuity, but it is sensitive because it can persist interpretations about people.
Separate observed facts from impressions, avoid unnecessary sensitive inferences and refresh current state from authoritative systems.
Workflow Memory
Workflow memory includes recurring instructions, accepted formats, common exception categories and lessons from previous runs. This is often better stored as maintained configuration, templates or rules rather than opaque model memory.
The more operationally important the instruction, the more explicit and versioned it should become.
Organisational Memory
Shared knowledge bases, runbooks, SOPs, decision logs and approved examples are organisational memory. They should have owners, versions and permissions.
The strongest SI workplaces convert valuable private memory into maintained organisational knowledge when the information should survive individual employees.
Memory vs Retrieval
Retrieval asks a maintained source for context when needed. Memory recalls information retained from prior interactions. Retrieval is usually stronger for facts that change, while memory is useful for stable preferences and continuity.
A good design often uses memory to know what to retrieve, then retrieves the current source before acting.
Memory vs System of Record
A CRM, finance system, HRIS, project tracker or version-control repository may own current state. Memory can summarise or index that state, but it should not silently replace it.
The next article develops source-of-truth architecture in detail.
Memory vs Knowledge Base
A knowledge base contains maintained shared knowledge. Memory may contain personal or task-specific context that does not belong in the shared corpus.
When a remembered item becomes broadly useful and stable, consider promoting it into the knowledge base with ownership and validation.
Memory vs Prompt
A prompt is an instruction supplied now. Memory can prefill recurring context automatically. Durable operating rules should not rely entirely on hidden memory if their presence is essential to safety or correctness.
Memory vs Personalisation
Personalisation is the behaviour that results from retained preferences and context. Memory is one mechanism for personalisation. Other mechanisms include explicit profiles, role settings, templates, project configuration and user-selected defaults.
The Memory Promotion Rule
Information should become persistent only when its future value exceeds the cost of staleness, privacy exposure and maintenance.
- Will this matter in future interactions?
- Is it stable enough to persist?
- Is the user or organisation allowed to retain it?
- Can it be corrected or deleted?
- Does it have an owner?
- Should it be personal, project, team or organisational?
- What current source overrides it if the world changes?
The Memory Expiry Rule
Not all memories deserve indefinite retention. Use time-to-live or review periods for information likely to age: project roles, temporary preferences, customer status, incident context and current priorities.
Expiry is a design feature, not a failure. It prevents yesterday’s assumptions from becoming permanent context.
The Memory Refresh Rule
Some memories should refresh from live systems before use. If the memory says a project deadline is Friday but the project system says Monday, the current system should win.
Refresh can happen on access, on schedule or after a relevant event.
The Memory Precedence Rule
- Live authoritative state overrides remembered summaries.
- Current approved policy overrides remembered procedure.
- Explicit user correction overrides older preference memory.
- Current project decision log overrides outdated working assumptions.
- Role and permission state overrides memories created under previous access.
A precedence model prevents memory from becoming a competing source of truth.
The Memory Provenance Rule
For material memories, know where the information came from: user statement, observed workflow, source document, business system or model inference.
Provenance matters because an inferred preference deserves less authority than an explicit instruction, and a remembered summary deserves less authority than the current source.
The Memory Confidence Rule
Some retained information is certain; some is an inference. Do not store inferred beliefs about people as if they were verified facts.
Where uncertainty matters, preserve the distinction or avoid persistence entirely.
The Memory Ownership Rule
Who owns the memory? The user, project, team, department or organisation? Ownership determines who may review, correct, share or delete it.
Private user preferences should not automatically become team memory. Team knowledge should not depend on one user’s private profile.
The Memory Scope Rule
Memory should be available only where its scope is relevant. Project memory should not leak into unrelated projects. Customer memory should not appear in another customer case. Personal preferences should not override organisational policy.
The Memory Permission Rule
A memory created from restricted information should not bypass later access controls. If the user loses access to the source, the system should not continue surfacing the remembered restricted fact as though permission no longer matters.
The Memory Data-Minimisation Rule
Store the smallest useful representation. The system may need “prefers concise weekly updates” rather than full historical conversations that established the preference.
Minimal memory reduces exposure and maintenance burden.
The Memory Sensitivity Rule
Sensitive personal, legal, health, security or employment information deserves stronger retention and access controls. Some information may be inappropriate for persistent model memory altogether and should remain in governed systems of record.
The Memory Explainability Rule
Users should be able to understand why the system is behaving differently because of memory. Hidden personalisation can be confusing when output changes without visible context.
The interface need not show every implementation detail, but important persistent assumptions should be inspectable.
The Memory Correction Rule
Users and owners need a way to correct inaccurate retained information. A memory system that can learn but cannot be corrected becomes increasingly unreliable.
Corrections should propagate to dependent workflow configuration where appropriate.
The Memory Deletion Rule
When retention is no longer justified, delete or expire the memory according to organisational and legal requirements. Deletion should include secondary stores or derived profiles where applicable.
The Memory Transfer Rule
Do not automatically transfer personal memory when a workflow moves to another person. Decide which context belongs to the project or organisation and which belongs to the previous user’s private working profile.
The Memory Handoff Rule
When work is handed off, create an explicit packet of state and evidence rather than relying on hidden memory in the sender’s assistant.
This keeps the organisational interface legible to the receiver.
The Memory Version Rule
Important workflow memory—templates, accepted instructions, exception definitions—should be versioned when changes can materially affect output.
Opaque persistent behaviour is harder to test than explicit configuration.
The Memory Learning Loop
Repeated user corrections can indicate a stable preference or workflow improvement. Promote only after the pattern is meaningful; do not turn every one-off correction into permanent memory.
The Memory Noise Problem
Too much memory can make the system less useful. Old preferences, obsolete projects and irrelevant history compete for context.
Memory systems need curation, expiry and relevance just like knowledge bases.
The Memory Bias Problem
Persistent impressions can anchor future interpretation. If the system remembers that a customer is “difficult” or an employee is “weak at detail”, future outputs may be biased by an unverified label.
Prefer observable facts, role-relevant state and explicit preferences over broad character judgments.
The Memory Drift Problem
The world changes while memory remains. Roles change, priorities change, products change and relationships change. Refresh or expire memories whose truth depends on current state.
The Memory Conflict Problem
Two memories may disagree, or memory may disagree with retrieval. The workflow should surface conflict rather than silently choose the most convenient answer.
The Memory Contamination Problem
A fact from one project or case can leak into another. Scope memory keys and context boundaries carefully, especially in multi-customer or multi-project environments.
The Memory Persistence Problem
Users may assume a temporary conversation disappears while the system retains useful preferences. Workplace deployments should be clear about what persists and why.
The Memory-to-Knowledge Promotion
If a private memory repeatedly helps many users, consider promoting it to a maintained team or organisational source. Examples include a new process note, accepted report format or recurring exception rule.
Promotion should add ownership and validation rather than simply copying private context into a shared store.
The Knowledge-to-Memory Demotion
Sometimes a shared rule stops being organisationally valid but remains useful as personal working preference. Retire the shared authority and, if appropriate, retain only the personal convention.
Worked Example: Personal Writing Preference
A manager prefers decision briefs with a one-paragraph summary followed by risks and actions. This is stable, low-sensitivity preference memory. It can persist until the manager changes it.
Worked Example: Project Deadline
A project deadline should not rely on memory if the project system owns current schedule. Memory may remember the project identity and retrieve the live deadline when needed.
Worked Example: Customer Preference
A customer prefers email rather than phone for routine updates. This can be useful relationship memory if legitimate and current. Customer entitlement or contract status should still refresh from the source of record.
Worked Example: Employee Working Style
A manager’s assistant might remember that a colleague prefers written agendas. Avoid storing speculative personality judgments that could bias performance or employment decisions.
Worked Example: Coding Convention
A team agent can remember formatting and testing conventions, but production-critical rules should live in versioned repository configuration or documentation rather than hidden model memory.
Worked Example: Incident Context
An incident agent can retain temporary investigative state across tool calls. When the incident closes, the durable outcome belongs in the incident record and runbook; transient hypotheses can expire.
Worked Example: Research Project
Project memory can retain scope, accepted sources, definitions and unresolved questions. Individual findings should remain traceable to evidence, and current literature may require fresh retrieval.
Worked Example: Legal Matter
Matter-specific memory should remain within the matter’s confidentiality boundary. Legal conclusions should be anchored to current sources and professional review rather than treated as permanent general memory.
The Memory Metrics
- Memories by scope
- Memories past review date
- Correction rate
- Stale-memory incidents
- Permission conflicts
- Memories promoted to shared knowledge
- Memories expired or deleted
- Retrieval refresh rate before action
- Cross-case contamination incidents
- User override frequency
The Memory Audit
- Purpose is clear.
- Scope is clear.
- Owner is clear.
- Provenance is known.
- Retention is justified.
- Expiry or review exists.
- Current source precedence is defined.
- Permission is preserved.
- Sensitive inference is limited.
- Correction is possible.
- Deletion is possible.
- Project/case boundaries are tested.
- Memory does not replace systems of record.
What This Article Owns
This page owns memory and personalisation: what workplace SI should retain, how long it should persist, who owns it, how it refreshes and how it remains subordinate to current authoritative state.
The previous article owns permissions. The next article owns source-of-truth architecture—the final authority model when memory, retrieval and business systems disagree.
The Core Memory Rule
Remember what improves continuity; retrieve what must be current; store authoritative truth where the organisation can govern it.
Memory should make workplace SI more useful without turning past context into permanent authority.
A Memory Architecture for Workplace SI
A practical memory architecture separates temporary working state from durable remembered context. This reduces the temptation to treat one giant persistent store as the answer to every continuity problem.
- Working memory: current interaction and temporary tool state.
- Case memory: one ticket, customer case, incident or matter.
- Project memory: longer-running work with milestones and decisions.
- User profile: stable preferences and working conventions.
- Team memory: shared methods and accepted practices.
- Organisational knowledge: maintained authoritative information.
- Systems of record: live operational truth.
The architecture should define how information moves between these layers and which layer wins when they disagree.
Working Memory Should Be Cheap to Forget
Most conversational state has value only while the current task is active. Letting temporary ideas, drafts and hypotheses expire reduces noise and privacy exposure.
Working memory can be rich because it is short-lived. Persistent memory should be more selective.
Case Memory Should Close With the Case
A support case or incident may need continuity across hours or shifts. The system can remember evidence gathered, actions attempted and unresolved questions.
When the case closes, durable facts should move to the appropriate case record or knowledge system while transient investigative detail can expire according to policy.
Project Memory Should Preserve Decisions and Dependencies
Project memory is most valuable when it stores why the project is in its current state: objective, decisions, constraints, owners, dependencies and open risks.
Live dates, status and resource assignments should refresh from project systems rather than rely on remembered snapshots.
User Profile Should Prefer Explicit Preferences
Personalisation works best when stable preferences are explicit: preferred report structure, default units, writing conventions, working hours or recurring review style.
Inferred preferences should have lower authority. One terse message should not permanently teach the system that the user always wants terse communication.
Team Memory Should Be Shared Deliberately
A useful team pattern belongs in shared configuration, documentation or templates, not hidden inside one user’s memory. Examples include accepted handoff format, report structure, code-review checklist or meeting closure packet.
Shared memory needs owners and versioning because it influences more people.
Organisational Knowledge Should Be Maintained
Policies, procedures, approved product information and formal decisions belong in governed knowledge repositories. They should not exist only as remembered summaries inside assistants.
Memory can point to them and help retrieve them, but authority comes from the maintained source.
The Memory Write Decision
Before storing a new memory, classify it. Is it stable? Is it future-relevant? Is persistence permitted? Is there a better system of record? Could retention bias later work?
The default for uncertain or sensitive context should often be temporary rather than permanent.
The Memory Read Decision
Before using a memory, ask whether the task still matches the memory’s scope, whether the user or workflow remains authorised and whether the information may have become stale.
Memory retrieval itself can include filters for project, case, role, date and sensitivity.
The Memory Update Decision
Some memories should be replaced; others should retain history. A user’s current preference can overwrite an old preference. A project decision may need an audit trail showing both the old and new state.
The update rule depends on whether the memory is a convenience preference or part of organisational accountability.
The Memory Forget Decision
Forgetting can be triggered by expiry, project closure, role change, user request, policy, data retention rule or evidence that the memory is wrong.
Forgetting should be considered a normal lifecycle operation rather than an exceptional failure.
Memory TTLs
Time-to-live rules are useful for volatile context. A temporary project priority may expire after a week; an incident hypothesis after closure; a stable formatting preference may have no automatic expiry but still receive periodic review.
TTL should match expected volatility and consequence.
Event-Driven Memory Invalidation
Some memories should be invalidated when a known event occurs: customer contract changes, employee changes role, project closes, policy is superseded or permission is revoked.
Event-driven invalidation is stronger than waiting for a user to notice stale memory.
Memory and Role Changes
A user’s new role can make old context inappropriate. Review personal and workflow memories when employees transfer departments, especially where the memory came from restricted sources.
Memory and Project Closure
Project closure should trigger a deliberate transition: archive durable decisions and deliverables, move reusable lessons into shared knowledge, expire temporary working context and revoke project-specific access.
Memory and Customer Lifecycle
Customer preferences and history can persist across interactions, but current entitlement, contract, risk and account status should refresh from live systems.
A customer relationship memory should not become a hidden parallel CRM.
Memory and Employee Lifecycle
Workplace personalisation involving employees deserves special care. Preferences such as pronouncing a name correctly or preferred meeting format may be useful. Sensitive performance, health or disciplinary context should remain in appropriate governed systems rather than broad personalisation memory.
Memory and Compliance
Retention obligations vary by data class and domain. The system should support policies that define what may persist, for how long, who may access it and how it is deleted.
Do not assume that because a model can remember, the organisation should allow it to remember everything.
Memory and Privacy
Personalisation can create privacy value by reducing repeated disclosure, but it can also create persistent profiles. Data minimisation, scope and user visibility help balance convenience and control.
Memory and Security
Sensitive remembered information becomes another asset to protect. Apply access control and incident response to memory stores, not only source systems.
Memory and Prompt Injection
Untrusted content should not become durable memory merely because it appeared in a document, email or website. Memory-write rules should distinguish trusted user or workflow input from external content.
Otherwise, an attacker could attempt to plant persistent instructions or false facts that influence later sessions.
Memory and Model Updates
A memory store can persist while the underlying model changes. Re-test important personalised workflows after material model updates because the same memories may be interpreted differently.
Memory and Agent Planning
Agents benefit from memory of prior steps, tool results and failed approaches. This task memory should remain bounded to the objective and should not leak into unrelated goals.
Long-running agents may also need checkpoints that refresh external state rather than trusting old memory indefinitely.
Memory and Multi-Agent Systems
Several agents may need shared working state. Use explicit shared state or a governed memory layer rather than assuming each agent’s private context will remain consistent.
Agent-to-agent memory should preserve provenance and ownership so one agent does not promote another agent’s hypothesis into accepted fact.
Memory and Human Handoffs
When a human takes over from an agent, the handoff should include explicit state, evidence and uncertainty. Do not require the human to depend on hidden agent memory.
Memory and User Agency
Users should be able to influence personalisation by correcting preferences, overriding remembered context and understanding why the system behaves a certain way.
Personalisation becomes more trustworthy when it is inspectable and reversible.
Memory and Team Agency
Teams should decide which recurring patterns deserve shared memory. One person’s preference should not become the team’s default without agreement.
Memory and Organisational Agency
The organisation should be able to retire a memory source, change precedence or disable personalisation in a workflow when policy or risk changes.
The Memory Store Schema
- Memory item
- Scope
- Owner
- Provenance
- Created date
- Last confirmed date
- Expiry or review date
- Sensitivity
- Permission context
- Source precedence
- Confidence or status
- Deletion rule
Not every implementation needs every field, but the schema illustrates what makes persistent context governable.
The Memory Status Model
- Active: currently eligible for use.
- Needs refresh: useful but potentially stale.
- Disputed: conflicting evidence or user correction exists.
- Superseded: newer information replaces it.
- Expired: retention period ended.
- Restricted: current user or workflow may not access it.
- Archived: retained for history but not active personalisation.
The Memory Review Queue
Important memories can enter a review queue when they approach expiry, conflict with sources, trigger repeated corrections or come from a user whose role changed.
This is more scalable than manually reviewing every persistent item.
The Personalisation Contract
For recurring workplace assistants, define what may be personalised: format, language, project focus, role context, preferred tools, recurring meetings or communication style.
Also define what should not be personalised automatically: sensitive judgments, policy interpretation, authority thresholds or facts owned by live systems.
Preference Conflict
Personal preference can conflict with organisational standards. A user may prefer a short report, but a regulated workflow may require specific fields. Organisational requirements should win.
Role Conflict
A user’s personal workflow preference may conflict with their current role. When role changes, role-specific configuration should refresh and old role memory may need deactivation.
Project Conflict
A preference or assumption valid for Project A should not silently shape Project B. Scope memories to the relevant project when context is local.
Source Conflict
When memory conflicts with a current source of truth, the system should retrieve and prefer the current source, and possibly mark the memory for update or retirement.
The Memory Incident
A memory incident occurs when persistent context causes material wrong behaviour: stale customer status, restricted information surfaced after permission change, cross-project contamination, or an incorrect preference shaping a sensitive decision.
Preserve the memory item, provenance, workflow, affected output and current source so the root cause can be repaired.
Memory Incident Review
- Contain the affected workflow.
- Identify the memory used.
- Check provenance and scope.
- Check current permissions.
- Compare with authoritative state.
- Correct, restrict or delete the memory.
- Check other workflows using the same memory mechanism.
- Add a regression case.
- Update retention or write rules.
The Memory Regression Set
For important personalised workflows, keep cases that test preference use, stale-memory refresh, permission change, project boundaries and user correction.
Re-run after material model, memory-store or policy changes.
Memory Metrics for Personal Assistants
- Preference reuse rate
- User correction rate
- Stale-memory rate
- Memories past review date
- Cross-project retrieval incidents
- Percentage of volatile facts refreshed before use
- User override frequency
- Memory deletion or expiry volume
Memory Metrics for Team Systems
- Shared memories with owners
- Unowned persistent items
- Versioned workflow memories
- Conflicts with current policy
- Private memories promoted to shared knowledge
- Expired project memories
- Permission-related memory incidents
Memory Metrics for Agents
- Average task-memory lifetime
- State refresh frequency
- Agent-to-agent memory conflicts
- Retries caused by stale state
- Long-running tasks exceeding memory TTL
- Cases requiring human correction of remembered context
The Memory Maturity Ladder
Stage 1 — Session Only
The system uses only current conversation context. Simple and privacy-friendly but repetitive.
Stage 2 — Explicit Preferences
Stable user preferences persist with user control.
Stage 3 — Project Memory
Projects retain decisions, open questions and working state.
Stage 4 — Workflow Memory
Recurring tasks reuse maintained instructions, exception patterns and accepted formats.
Stage 5 — Governed Shared Memory
Teams and agents share scoped, permission-aware memory with review, expiry and provenance.
Not every workflow needs to climb the ladder. Session-only operation can be appropriate for sensitive or rare work.
The Memory Deletion Test
For every persistent item, ask what future workflow would break if the memory disappeared. If the answer is none, retention may be unnecessary.
The Memory Promotion Test
Ask whether a repeated memory should move into explicit profile, project configuration, knowledge base, system of record or policy. Important context becomes easier to govern when promoted to the right layer.
The Memory Demotion Test
If a shared item no longer has organisational authority but remains useful personally, remove shared status and retain only the appropriate personal preference if permitted.
The Memory Simplification Rule
A smaller clean memory often outperforms a large noisy one. Periodically prune outdated projects, duplicated preferences and one-off observations.
The Memory Security Rule
Protect memory stores according to the sensitivity of their contents and make sure logs, exports and backups do not create uncontrolled secondary copies.
The Memory Final Architecture Rule
Persistent memory should be a curated continuity layer sitting between temporary context and authoritative systems—not a hidden replacement for either.
When that architecture is clear, personalisation can become more useful without becoming more mysterious.
Personalisation by Role
Different roles benefit from different memory. A universal memory profile can create irrelevant or inappropriate carryover. Personalisation should follow the work rather than the generic identity of the user.
Executive
Useful memory includes preferred briefing structure, recurring strategic themes, standing meeting formats and communication conventions. Current financials, project state and sensitive people matters should refresh from authoritative sources.
Manager
Useful memory includes one-on-one structure, team operating rhythms and preferred report formats. Employee performance or welfare facts should remain in appropriate governed systems rather than broad assistant memory.
Sales
Useful memory includes account-preparation preferences, proposal structure and customer communication conventions. Current opportunity stage, pricing and contract status should refresh from CRM and approved commercial systems.
Customer Support
Useful memory includes support workflow conventions, common troubleshooting paths and communication style. Customer entitlement, open case state and refund authority should remain live.
Engineer
Useful memory includes coding conventions, preferred testing patterns and repository-specific workflow. Current branch state, dependencies and production configuration should come from the repository and engineering systems.
Finance
Useful memory includes reporting preferences and recurring commentary structure. Current figures, approvals and accounting state remain in finance systems.
Legal
Useful memory includes drafting conventions and matter-workflow preferences. Legal authority, matter-specific facts and current law or contract state require governed sources and professional review.
Educator
Useful memory can include lesson-format preferences, curriculum structure and recurring instructional conventions. Current learner performance, welfare or sensitive student information should remain appropriately governed.
Researcher
Useful memory includes project scope, source-screening criteria and preferred evidence tables. Current literature and study facts should remain traceable to retrieved sources.
Personalisation by Workflow
Some memories should attach to the workflow rather than the person. A report workflow may always use a particular structure regardless of who runs it. A customer-escalation workflow may require a specific handoff packet.
Workflow memory reduces inconsistency and makes the system transferable when staff change.
Personalisation by Project
Projects need local context: vocabulary, milestones, stakeholders, constraints, decisions and accepted artefacts. Keeping this memory project-scoped prevents unrelated projects from contaminating one another.
Personalisation by Customer or Case
Case-scoped memory can preserve continuity without creating a universal customer profile. When the case closes, durable facts should move to the official customer system and temporary hypotheses should expire.
Personalisation by Team
Team memory can include templates, naming conventions, meeting rhythms, escalation paths and shared decision rules. It should be explicit enough for team members to inspect and improve.
Personalisation by Organisation
Organisation-wide personalisation may include brand tone, standard terminology, security rules and shared workflow conventions. High-level organisational defaults should not override domain-specific controls.
The Preference Hierarchy
- Policy: mandatory organisational requirement.
- Role standard: default for a function or responsibility.
- Workflow standard: accepted structure for a recurring task.
- Project convention: local project-specific preference.
- User preference: individual style or convenience.
- Session choice: temporary instruction for the current interaction.
Higher-level mandatory requirements should override lower-level convenience preferences when they conflict.
The Memory Conflict Resolution Process
- Identify the conflicting memories or sources.
- Classify each by authority, scope and currentness.
- Prefer the higher-authority current source.
- Mark obsolete or disputed memory.
- Correct downstream personalised behaviour.
- Record a regression case if the conflict caused material failure.
Conflict should produce repair rather than silent selection.
The User Correction Loop
A user may say, “I no longer want weekly summaries in this format,” or “That project owner changed.” The system should distinguish preference correction from factual update. Preference can update memory; factual state may require the authoritative system to change.
This distinction prevents a conversational correction from silently rewriting organisational truth.
The Memory Consent and Expectation Problem
Workplace users should understand which context is temporary and which may persist. Surprise persistence can reduce trust, while surprise forgetting creates repeated work.
The interface or policy should make important retention categories understandable without overwhelming users with implementation detail.
The Memory Visibility Interface
A useful memory interface can show active preferences, project contexts, recently refreshed items, expired items and the source or owner of important memories.
The goal is not to expose every vector or database row. It is to make material personalisation legible.
The Memory Correction Interface
Users should be able to correct a preference, request refresh, mark a memory obsolete or route a factual correction to the source owner.
This makes personalisation collaborative rather than opaque.
The Memory Expiry Interface
For temporary memories, show or enforce expiry. Project and case memories can expire or archive automatically when closure events occur.
The Memory Promotion Interface
When a private remembered insight should become shared knowledge, provide a path to propose it for validation and publication. Do not copy personal memory directly into an authoritative knowledge base without review.
The Memory Archive
Some memory needs historical preservation but should not influence current personalisation. Archive status allows later inspection while removing the item from active context.
The Memory Compression Problem
Long project histories can become too large. Periodically compress memory into durable decisions, current state and open questions while retaining links to detailed evidence.
Compression should preserve what changes future action, not every conversation.
The Memory Summary Problem
A summary can harden one interpretation of ambiguous history. Important project memory should distinguish confirmed decisions from working summaries and unresolved disagreement.
The Memory Granularity Problem
Memory that is too broad becomes vague; memory that is too granular becomes noisy. The right unit is usually one stable preference, one decision, one project fact or one workflow rule.
The Memory Recency Problem
Recent events can dominate personalisation even when older stable preferences matter more. Weight memory by authority and relevance, not only recency.
The Memory Frequency Problem
A repeated event does not automatically deserve persistence. The system should ask whether the repetition represents a stable preference or merely a temporary period.
The Memory Popularity Problem
A team pattern used by many people may deserve promotion into shared workflow memory, but popularity alone does not make it correct. Validate against outcome and policy.
The Memory Staleness Test
- Does this memory describe a fact that can change?
- How long since it was confirmed?
- Is there a live source available?
- Has the owner or role changed?
- Has a related policy or project changed?
- Would a stale version materially affect action?
If the answer suggests risk, refresh before use.
The Memory Sensitivity Test
- Does the item concern personal data?
- Does it contain confidential business information?
- Could it affect employment, legal, financial or safety decisions?
- Would the user reasonably expect it to persist?
- Is a governed source a better storage location?
The Memory Bias Test
Ask whether the memory describes observable state or a broad judgment about a person or situation. Replace labels such as “difficult client” with specific facts such as “requested written confirmation for previous three changes” where retention is legitimate.
The Memory Scope Test
Ask whether the memory belongs to user, case, project, team or organisation. The narrowest correct scope reduces leakage and conflict.
The Memory Authority Test
Ask whether the memory can legitimately drive action. A personal preference can guide format; a remembered financial figure should not drive payment without current source verification.
The Memory Durability Test
Ask whether the item is likely to matter after the current week, project or role. If not, keep it temporary.
The Memory Explainability Test
If the system used this memory in an important output, could the user understand what assumption shaped the result? Material hidden assumptions should be inspectable.
Casebook: Twelve Memory Decisions
Preferred Report Format
A director consistently asks for one-page summaries with risks first. This is stable preference memory and can persist until changed. The underlying figures still come from live sources.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Project Owner
The assistant remembers that Priya owns a project. Because ownership can change, the project system should refresh this fact. The memory can store the project identity and preferred retrieval path rather than the owner as permanent truth.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Customer Communication Preference
A customer prefers written updates. This can be useful relationship memory if legitimate and current, but contract terms and service entitlements must refresh from systems of record.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Temporary Crisis Priority
During an incident, the team prioritises one service. This is high-value short-lived memory. It should expire or be archived after the incident rather than shape normal operations indefinitely.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Employee Performance Observation
A manager notes that an employee struggled with one task. This should not become a broad persistent label in general personalisation. Formal performance information belongs in the appropriate HR process.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Coding Style
A repository uses a naming convention and test pattern. This can be retained as workflow or project memory, but critical rules should be explicit in repository configuration or documentation.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Supplier Negotiation Position
A procurement team temporarily accepts a fallback position for one negotiation. Scope it to that supplier and deal rather than remembering it as the organisation’s general commercial policy.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Legal Matter Context
A legal assistant remembers matter-specific facts. The memory must remain inside the matter boundary and defer to current documents and qualified legal review.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Research Inclusion Criteria
A research project uses specific inclusion criteria. These can persist in project memory and later be promoted to a documented protocol if they become authoritative.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Education Learner Preference
A learner responds well to visual examples. This may be useful pedagogical context, but sensitive learner information and formal educational records should remain in governed systems.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Executive Meeting Style
An executive prefers pre-reads 24 hours before decisions. This is stable workflow preference and can be remembered without affecting the underlying decision evidence.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
Expired Pricing Assumption
A salesperson previously used a pricing assumption that has since changed. Memory should be superseded by current approved pricing and ideally marked stale when the new source arrives.
The design question is always the same: should this context persist, at what scope, and what current source overrides it if reality changes?
The Memory Review by Lifecycle
On Creation
Classify scope, source, sensitivity, expected lifetime and authority.
During Use
Check permission, relevance and currentness before material use.
On Correction
Update the memory, route source corrections and consider whether downstream outputs need repair.
On Project or Case Closure
Promote durable knowledge, archive required history and expire temporary state.
On Role Change
Review personal and workflow memories derived from restricted access or role-specific assumptions.
On Retirement
Delete or archive according to retention needs and ensure active personalisation no longer uses the item.
The Personalisation Pilot
Start with low-risk preferences such as format, language, recurring project context or meeting structure. Measure whether users save setup time without seeing surprising or incorrect carryover.
Do not begin by persisting sensitive facts or granting memory broad influence over consequential decisions.
The Project-Memory Pilot
Choose one project and retain objective, decisions, open questions, sources and next action. Refresh live status from the project system. Measure reduction in context-reconstruction time.
The Agent-Memory Pilot
For one bounded agent, retain only task state across steps. Test stale-state refresh, tool failure, restart and human takeover. Promote only the memory required for continuity.
The Team-Memory Pilot
Store one shared workflow preference or template with an owner and version. Test whether different users receive consistent value and whether personal preferences remain separate.
The Memory Review Meeting
For important personalised workflows, periodically review stale items, corrections, permission conflicts, promoted knowledge and memories with no owner.
The meeting should focus on unusual or high-impact items rather than manually inspecting every preference.
The Memory Portfolio
Once many SI workflows use memory, maintain a portfolio view of memory stores, scopes, owners, data classes, retention and source precedence.
This reveals shared risk such as one memory service holding sensitive information from several departments.
The Memory Failure Catalogue
- Stale fact used as current truth
- Restricted information resurfaced after access change
- Cross-project contamination
- Cross-customer contamination
- Inferred preference treated as explicit
- One-off behaviour made permanent
- Sensitive judgment persisted unnecessarily
- Project memory not closed
- Memory conflicts with current policy
- User correction not propagated
- Deleted source still represented in memory
- Agent remembers failed plan as valid state
The Memory Repair Sequence
- Stop or contain affected personalised behaviour.
- Identify memory item and provenance.
- Check current source and permission.
- Correct, restrict, supersede or delete.
- Review similar memories in the same store.
- Add a regression case.
- Update memory-write or refresh rules.
- Restore workflow after validation.
The Memory Final Review Questions
- What future work does this memory improve?
- Why should it persist?
- Who owns it?
- Where did it come from?
- How current is it?
- What source overrides it?
- Who is allowed to use it?
- How can it be corrected?
- When should it expire?
- How is it deleted?
- Could it bias a sensitive decision?
- Would explicit configuration be better than hidden memory?
The Personalisation Final Standard
A mature personalised SI system remembers stable preferences and useful continuity while refreshing volatile facts, respecting permissions and making material assumptions correctable.
The goal is not maximum memory. The goal is minimum repeated context with maximum currentness and control.
The Practical Memory Contract
A workplace memory layer should be designed as a contract rather than a vague promise that the system will remember. For every persistent item, record what it is for, who supplied it, how long it should remain valid, which source can override it and how a user can correct it.
This keeps memory inspectable. The organisation can explain why a system remembers a formatting preference indefinitely while refreshing a project deadline every day.
The Four Memory Questions
- Should this be remembered? Does persistence create real continuity value?
- At what scope? Session, task, project, user, team or organisation?
- For how long? Until task end, project closure, role change or explicit replacement?
- What overrides it? Which source of truth wins when state changes?
If the team cannot answer these questions, the information may not belong in persistent memory yet.
Memory Should Be Cheap to Forget
A healthy workplace memory system treats forgetting as a design feature. Closed projects, obsolete roles, outdated customer assumptions and old working preferences should be removable without damaging the system.
Memory that is easy to add but hard to remove becomes an accumulation problem. Over time, the system begins to carry invisible historical baggage into current work.
Memory Should Be Explicitly Scoped
A preference that applies to one client should not automatically shape another client. A project-specific abbreviation should not become organisation-wide vocabulary. A manager’s personal style should not become a team policy.
Scope reduces accidental leakage. The narrower the context, the safer the memory usually becomes.
Memory Should Preserve Provenance
Persistent context should record where it came from: explicit user instruction, confirmed project decision, system event, imported profile or inferred pattern. Provenance helps the system decide how strongly to trust the memory and helps humans challenge it later.
An explicit confirmed instruction generally deserves more weight than an inferred preference from one prior interaction.
The Difference Between Explicit and Inferred Memory
Explicit memory
The user or organisation directly states the preference, role, rule or project fact. This is usually the strongest form of personalisation context, though it can still become outdated.
Inferred memory
The system notices a pattern and infers a preference or relationship. This can improve convenience, but important inferred memory should be treated cautiously and ideally confirmed before it shapes consequential work.
The more sensitive or operationally important the memory, the stronger the case for explicit confirmation.
The Memory Confidence Model
Memory confidence should reflect provenance and currentness, not the fluency with which the system recalls it. A recent explicit preference may have high confidence. An old inferred preference should have much lower confidence.
This model prevents the system from treating all remembered context as equally reliable.
The Memory Precedence Model
- Current authoritative state overrides remembered state.
- Explicit user correction overrides prior inferred preference.
- Current role assignment overrides historic role memory.
- Current project plan overrides previous project decision unless the decision is still relevant as history.
- Organisation policy overrides local preference where the two conflict.
Precedence rules are how memory remains useful without becoming an alternate reality.
The Memory Freshness Model
Different memory classes need different freshness rules. Style preference may be stable for years. Project priority may need weekly confirmation. Operational state may need minute-level refresh. Access permissions may need immediate verification before action.
Freshness should therefore be attached to the data class rather than implemented as one global expiry period.
Time-to-Live for Memory
A time-to-live or TTL is the period after which memory should be refreshed, reviewed or retired. TTLs can be fixed or event-driven.
- Presentation preference: long TTL; review only after explicit change.
- Project state: shorter TTL; refresh from the project system.
- Customer preference: moderate TTL; refresh after significant interaction.
- Access state: very short TTL; verify immediately before use.
- Temporary incident context: expire after closure unless promoted into a postmortem or durable knowledge item.
Event-Driven Invalidation
Some memory should expire because an event occurs rather than because a timer runs out. Role change, project closure, customer offboarding, policy update, manager change or system migration can invalidate many related memories immediately.
Event-driven invalidation is stronger than waiting for stale context to cause a visible error.
Memory and Role Changes
When an employee changes role, old responsibilities, approval rights and project context should not silently continue. Role memory must refresh from the authoritative organisational source.
Personal preferences may remain; decision rights usually should not.
Memory and Project Closure
Project memory should move from active to archived state when the project closes. Open actions should be resolved or transferred. Historical decisions can remain available for later learning but should not appear as current work.
Memory and Customer Lifecycle
A customer relationship moves through prospect, active, paused, renewed or closed states. Personalisation should follow current account state rather than preserve every old assumption indefinitely.
Sensitive notes should have clear purpose and access controls.
Memory and Employee Lifecycle
Onboarding, role changes, leave and offboarding can all alter the context an SI system should use. Personalisation should not outlive legitimate access or purpose.
Memory and Compliance
Retention rules can differ by data type and jurisdiction. Workplace memory should inherit the organisation’s relevant retention, access and deletion obligations rather than create a separate informal data store.
Memory and Privacy
Personalisation should use the minimum personal information required for the workplace purpose. The fact that a detail is useful does not automatically justify indefinite persistence.
Sensitive personal memory deserves stronger access control and a clearer purpose than simple formatting preferences.
Memory and Security
Persistent memory can become a target because it may contain project context, customer information or operating assumptions. Apply least privilege, encryption and logging according to the sensitivity of the store.
Do not put secrets such as passwords or private keys into general conversational memory.
Memory and Prompt Injection
An external document or message should not be able to write durable memory simply because it contains an instruction. Memory-write permissions need trusted rules.
This matters especially for agents that read untrusted websites, email or documents. External content is data, not authority over long-term memory.
Memory and Model Updates
A model upgrade can change how the system interprets remembered context. Important memory-driven workflows should be regression-tested when the model or retrieval layer changes materially.
Memory and Agent Planning
Agents benefit from persistent objective, task state and completed actions. But critical live state—permissions, prices, account status, deadlines—should be refreshed before action.
The safest agent memory remembers the plan and history while re-checking the world.
Memory and Multi-Agent Systems
Multiple agents should not each maintain opaque private versions of project truth. Shared operational state belongs in a common store, while local agent memory can retain task-specific reasoning or preferences.
This separation reduces contradictory actions caused by divergent memories.
Memory and Human Handoffs
When work moves between people, required state should be transferred explicitly rather than assuming the next person has access to the first person’s personal AI memory.
See the workplace handoff article for the state-transfer method.
Memory and User Agency
Users should be able to see or understand the persistent context shaping their work, correct it and prevent inappropriate memory from being applied.
Personalisation that cannot be challenged reduces agency because the system quietly decides who the user is.
Memory and Team Agency
Teams should be able to define shared conventions deliberately. One employee’s private preference should not silently become a team rule.
Memory and Organisational Agency
The organisation should know where persistent SI context exists, what data classes it contains and which workflows depend on it. Memory becomes infrastructure once many people rely on it.
The Memory Store Schema
A practical memory record can contain more than raw text.
- Memory text or structured value
- Scope
- Source
- Created date
- Last confirmed date
- Expiry or review date
- Owner
- Sensitivity level
- Confidence or confirmation status
- Override source
- Status: active, stale, archived or deleted
A schema makes memory governable and machine-readable rather than a hidden bag of text fragments.
The Memory Status Model
Active
Current enough for use within its intended scope.
Needs refresh
Potentially useful but past its freshness threshold or affected by a relevant event.
Superseded
Replaced by a newer confirmed value.
Archived
Retained for historical context but not used as current state.
Deleted
No longer retained for active or historical use according to the applicable process.
The Memory Review Queue
Important memory that becomes uncertain should enter a review queue rather than remain silently active. Examples include changed role, conflicting project state, disputed customer preference or uncertain source provenance.
This gives humans a way to repair the context before it contaminates future work.
The Personalisation Contract
For every personalised workflow, define which aspects may adapt and which must remain governed.
- May personalise: style, order, emphasis, recurring format.
- May adapt with confirmation: project workflow, stakeholder preferences, task defaults.
- Must refresh: live state, permissions, prices, deadlines and current policy.
- Must remain authoritative elsewhere: financial records, contracts, HR records, security state and other systems of record.
Preference Conflict
A user prefers concise email but a regulated notice requires complete wording. The organisational requirement wins. Personalisation should never erase mandatory content.
Role Conflict
A system remembers that a user once approved expenses, but the user changed role. Current access and role state override memory.
Project Conflict
A past decision says launch in March; the current plan says April. The memory should preserve March as historical context only if relevant, not treat it as the current deadline.
Source Conflict
A remembered process differs from the current SOP. The current approved SOP wins. The conflict should be surfaced so the memory can be corrected or retired.
The Memory Incident
A memory incident occurs when persistent context causes or materially contributes to an inappropriate outcome: confidential information appears in the wrong context, stale project state drives an action, or an outdated role memory grants misleading authority.
The incident should be investigated like any other workflow failure: source, write event, scope, read path, override logic and downstream action.
Memory Incident Review
- What memory was used?
- Where did it originate?
- Why was it still active?
- What source should have overridden it?
- Which user or agent read it?
- What action followed?
- Could the conflict have been detected earlier?
- What lifecycle rule should change?
The Memory Regression Set
Keep a small set of tests for important persistent-context workflows. Include outdated preference, changed role, closed project, conflicting source and sensitive-memory cases.
Run these tests after material system changes.
Memory Metrics for Personal Assistants
- Repeated instruction reduction
- Time to resume project work
- User correction rate
- Preference satisfaction
- Stale-memory incidents
- Percentage of current-state facts refreshed from source
Memory Metrics for Team Systems
- Consistency across users
- Shared-template adoption
- Memory conflict rate
- Team-context update latency
- Number of private-workflow facts promoted to shared knowledge
- Number of obsolete shared memories retired
Memory Metrics for Agents
- Task-state continuity
- Incorrect repeated action rate
- World-state refresh rate
- Memory-triggered exception rate
- Permission refresh before action
- Recovery from stale state
The Memory Maturity Ladder
Stage 1 — Session Only
The system remembers only the current interaction. Simple, low-risk and easy to understand.
Stage 2 — Explicit Preferences
Users store stable formatting and workflow preferences.
Stage 3 — Project Memory
The system maintains active project continuity with clear sources and closure rules.
Stage 4 — Workflow Memory
Recurring tasks use maintained state, examples, exception rules and user context.
Stage 5 — Governed Shared Memory
Teams and agents share scoped persistent context with lifecycle, permissions, provenance and auditability.
Not every workplace needs Stage 5. The correct maturity level depends on the benefit of persistence.
Worked Example: Personal Writing Preference
A user consistently asks for concise executive summaries with a one-line recommendation at the top. This is a strong memory candidate because it changes presentation but not underlying truth.
If a specific document requires a regulatory format, that requirement overrides the preference.
Worked Example: Project Deadline
The system remembers that a launch was planned for 15 March. The project tool later moves the date to 22 March. The next brief should retrieve 22 March from the system of record and may mention the previous date only if history matters.
Worked Example: Customer Preference
A customer once preferred morning meetings. This can be useful soft context, but the calendar and current customer communication should determine actual scheduling.
Worked Example: Employee Working Style
A manager records that an employee prefers written preparation before one-on-ones. This can improve collaboration, but it should not become a permanent psychological label or be applied outside the relevant management purpose.
Worked Example: Coding Convention
A team prefers a specific testing pattern and naming convention. This is shared team context and may belong in repository guidance or team instructions rather than one developer’s personal memory.
Worked Example: Incident Context
During an incident, the system remembers current hypotheses and actions tried. When the incident closes, those facts should move into the postmortem or archive rather than remain active operational memory.
Worked Example: Research Project
A research workflow remembers included sources, exclusion criteria and open questions. New evidence is retrieved and compared against that project memory. The memory supports continuity without replacing the source corpus.
Worked Example: Legal Matter
A system can remember working notes and preferred structure, but legal status, contract version and authoritative advice should come from the maintained matter files and qualified professionals.
Worked Example: Sales Account
A sales assistant may remember relationship history and preferred communication style, but opportunity amount, pipeline stage, pricing and next meeting should refresh from CRM and calendar.
Worked Example: Education
An educator’s SI workspace may remember preferred lesson format and current teaching unit, while student performance and curriculum state should come from current records and teacher judgment.
The Memory Audit
- Inventory persistent memory classes.
- Classify scope and sensitivity.
- Identify the source of each class.
- Identify the authoritative override.
- Set freshness or expiry.
- Confirm correction path.
- Review closed-project memory.
- Review role and permission memory.
- Test conflict handling.
- Remove memory with no continuing purpose.
The Memory Deletion Test
Ask whether removing a memory would materially worsen continuity. If not, do not persist it. This keeps the memory layer selective.
The Memory Promotion Test
When the same local context becomes useful to many people, consider promoting it into maintained shared knowledge rather than copying it into more personal memories.
The Memory Demotion Test
When shared knowledge becomes project-specific or obsolete, remove it from broad context and keep it only where needed.
The Memory Simplification Rule
Prefer a few high-value persistent facts over a large uncurated memory. More memory can make answers worse when old and new context compete.
The Memory Security Rule
Persistent context deserves controls proportional to its sensitivity and downstream power. Memory that can influence tool-using agents is more consequential than memory used only for text formatting.
The Memory Final Architecture Rule
Persist preferences and continuity; retrieve current facts; preserve authority in systems of record; expire what no longer belongs.
When workplace memory follows that rule, personalisation becomes a real productivity layer rather than a hidden source of stale assumptions.
Private Memory vs Shared Memory
Private memory belongs to one user or one bounded personal workspace. Shared memory belongs to a team, project or organisation. The difference matters because sharing changes authority, privacy and maintenance.
A personal preference such as “use bullet points for my morning brief” should remain private. A team rule such as “all incident handoffs include severity, owner and rollback state” belongs in shared workflow memory.
The Promotion Gate From Private to Shared
Promote a private memory only when it is useful beyond the original user, validated by the relevant owner and appropriate for the wider audience.
- Is the item stable?
- Is it correct for more than one user?
- Does it conflict with policy or role standards?
- Who will own updates?
- Should it become documentation, configuration or a knowledge-base entry instead of memory?
The promotion gate prevents one person’s habits from silently becoming organisational defaults.
Shared Memory Needs Versioning
When shared memory influences workflow behaviour, changes should be visible. Teams should know when a report structure, escalation rule or agent instruction changed and why.
Versioning can be lightweight, but important workflow memory should not mutate invisibly.
Shared Memory Needs an Owner
Every shared memory set should have an owner who can approve changes, retire outdated items and resolve conflicts. Unowned shared memory becomes a new source of institutional ambiguity.
Shared Memory Needs a Review Cadence
Stable conventions may need only infrequent review. Fast-changing operational rules may need event-driven updates. The cadence should follow volatility and consequence.
Memory and Permissions After Role Change
When users change role, permissions change immediately but memory can lag behind. Review memories derived from restricted sources and disable role-specific personalisation that no longer applies.
The system should not keep surfacing former-department knowledge merely because it remembers it.
Memory and Permissions After Project Closure
Project access may expire while project memory remains. Archive or restrict the memory at closure and promote only durable organisational lessons to shared knowledge.
Memory and Permissions After Customer Reassignment
When account ownership changes, personal memory should not give the former owner continuing access to current customer context. Durable customer state belongs in the CRM or other governed customer system.
Memory and Permissions After Incident
An incident may expose sensitive temporary context. Once resolved, move durable findings into the incident record or runbook and expire investigative memory that no longer needs active access.
The Memory Retention Matrix
- Stable user preference: retain until changed or reviewed.
- Temporary task state: expire when task closes.
- Project state: retain while active, archive on closure.
- Current business fact: retrieve live rather than persist as authority.
- Historical decision: preserve in decision log with date and provenance.
- Sensitive inference: avoid persistence unless explicitly justified.
- Workflow rule: store in versioned configuration or documentation.
- Organisational policy: keep in authoritative knowledge source, not hidden memory.
The Memory Readiness Checklist
- Memory purpose is defined.
- Scope is defined.
- Owner is defined.
- Provenance is known.
- Retention is justified.
- Review or expiry exists.
- Current source precedence is explicit.
- Access follows current permissions.
- Correction is available.
- Deletion is available.
- Cross-case and cross-project leakage are tested.
- Sensitive inferences are limited.
- Shared memory is versioned when material.
The Memory Deployment Sequence
- Start with session context.
- Add explicit low-risk preferences.
- Add project memory for continuity.
- Separate live facts from retained summaries.
- Add user correction and expiry.
- Add permission-aware recall.
- Promote repeated shared patterns into governed memory.
- Add portfolio monitoring only after several workflows use memory.
The sequence keeps memory useful while the organisation learns what persistence actually creates value.
The Memory Access Interface
Users should be able to see the broad categories shaping personalisation: role, active project, preferred format, recurring meetings or chosen source sets.
This visibility improves trust because users can understand why two otherwise identical requests produce different outputs.
The Memory Update Interface
Users should be able to say a preference changed, a project closed or a remembered assumption is wrong. The system should route factual changes to the correct source rather than merely overwrite memory when the source of truth lives elsewhere.
The Memory Forget Interface
For user-owned preferences and context, provide a practical way to remove or expire items where the product and organisational policy permit it. Workplace deployments should also support centrally required retention or deletion rules for governed data.
The Memory Audit Interface
Owners may need a report of active shared memories, items nearing expiry, memories with no owner, permission conflicts and recent corrections.
The goal is exception-based governance, not manual review of every remembered phrase.
The Memory and Search Interaction
Memory can improve enterprise search by remembering the user’s role, current project and preferred source types. Search should still apply current access control and return current source evidence.
Personalisation should improve relevance without becoming a hidden permission override.
The Memory and Email Interaction
An email assistant can remember tone preferences and recurring signature conventions. It should refresh customer state, deadlines and commitments from the live thread or business system rather than relying on an old remembered summary.
The Memory and Meeting Interaction
A meeting assistant can remember preferred agenda structure and recurring decision format. Current agenda items, participants and project state should refresh each meeting.
The Memory and Writing Interaction
Writing SI can remember document style, audience conventions and accepted structures. Facts, evidence and current policy should still be supplied or retrieved for each document.
The Memory and Research Interaction
Research SI can remember project scope, terminology and inclusion criteria. Current evidence and literature should remain source-grounded and re-retrieved when needed.
The Memory and Planning Interaction
Planning assistants can remember strategic priorities and preferred planning cadence, but live resources, deadlines and dependencies should refresh from authoritative planning systems.
The Memory and Data Analysis Interaction
Data-analysis SI can remember preferred charts, units and reporting conventions. Dataset values, schema and refresh status remain authoritative in the data system.
The Memory and Documentation Interaction
Documentation SI can remember preferred structure and vocabulary. Published documentation should become maintained shared knowledge, not remain a memory-only artefact.
The Memory and Agent Interaction
Agents need state memory to avoid repeating steps. That memory should record what was attempted, tool returns, current objective and unresolved conditions.
Agents should re-check external state before consequential action because remembered tool results can age.
The Long-Running Agent Problem
An agent operating for hours or days can accumulate stale memory. Insert checkpoints that refresh permissions, deadlines, prices, customer state or other volatile information.
Time itself should be considered a reason to validate remembered assumptions.
The Restart Problem
When an agent or service restarts, it should reconstruct task state from a durable explicit source rather than rely on invisible in-memory context that disappeared.
Critical workflow continuity should not depend on one process staying alive indefinitely.
The Duplicate Memory Problem
The same preference or fact may be stored in several places. Define which representation is canonical and remove redundant stale copies when practical.
The Memory Export Problem
Users or administrators may export memory for review or migration. Exports should preserve sensitivity and permission boundaries; a convenient export should not become an uncontrolled data copy.
The Memory Backup Problem
Backups can preserve deleted or expired memory according to technical retention. Organisations should understand how memory lifecycle interacts with backup and legal retention requirements.
The Memory Vendor-Migration Problem
If the organisation changes SI providers, decide which memories should migrate. Stable explicit preferences and project configuration may be portable; hidden inferred profiles may be poor candidates.
Migration is an opportunity to reduce noise and remove stale memory.
The Memory Model-Change Problem
A new model may interpret the same retained context differently. Important personalised workflows should be regression-tested after major model changes.
The Memory Overfitting Problem
Excessive personalisation can make the system reproduce the user’s old patterns rather than challenge them. For analytical or creative work, the user may want the system to provide fresh alternatives rather than conform too strongly.
Personalisation should improve relevance without eliminating productive disagreement.
The Memory Convenience–Challenge Balance
Stable preferences can reduce setup, while some tasks benefit from neutral or alternative perspectives. Allow users to request a clean view that ignores personal preferences where useful.
The Memory and Fairness Problem
Persistent profiles about people can influence future decisions. Sensitive workplace decisions should rely on legitimate job- or task-related evidence rather than informal remembered impressions.
The Memory and Explainability Problem
If personalisation materially changes a recommendation, the user should be able to identify the remembered context that influenced it. Hidden memory should not become hidden reasoning authority.
The Memory and Trust Problem
Users trust memory when it is predictably useful and correctable. Surprise recall of sensitive or irrelevant information can reduce trust quickly.
A smaller transparent memory system can be more valuable than one that remembers everything.
The Memory Cost Problem
Persistent context creates storage, retrieval, indexing and review cost. Pruning unused memory can improve both system performance and operating expense.
The Memory Portfolio Dashboard
- Active memory stores
- Personal vs shared memory counts
- Memory stores containing sensitive data
- Items past review or expiry
- Recent corrections
- Permission conflicts
- Cross-scope incidents
- Unowned shared memories
- Model changes awaiting regression test
- Projects closed but memory still active
The Memory Governance Meeting
For large deployments, governance can focus on exceptions: sensitive stores, stale items, incidents, unowned memory and material personalisation changes. Do not turn memory governance into a manual approval process for every benign preference.
The Memory Final Audit
- List the memory types used.
- Identify owners and scopes.
- Classify data sensitivity.
- Define source precedence.
- Define expiry and refresh.
- Test current permissions.
- Test cross-case isolation.
- Test user correction.
- Test deletion or archive.
- Review inferred judgments.
- Check project and role closure triggers.
- Run representative regression cases.
Frequently Asked Questions
Should workplace SI remember everything?
No. Retain only context with durable workflow value. Temporary working material should often expire.
What is the safest memory to start with?
Explicit low-risk preferences such as format, language, units and recurring project context are good starting points.
Should SI remember customer facts?
It can remember stable relationship preferences where legitimate, but current entitlement, contract, price and case status should refresh from authoritative systems.
Should SI remember employee information?
Only where there is a legitimate workplace purpose and appropriate governance. Sensitive performance, health or disciplinary information is generally better kept in dedicated governed systems.
What happens when memory conflicts with current data?
Current authoritative sources should win. The memory should be refreshed, superseded or marked disputed.
Can personalisation override company policy?
No. Organisational requirements, role standards and workflow controls should override lower-level personal preferences.
How long should project memory last?
Long enough to support the active project. On closure, archive required history, promote reusable lessons and expire temporary state.
How do agents use memory safely?
Keep memory scoped to the task, preserve tool results and uncertainty, refresh volatile external state and make human takeover possible without hidden context.
How do we avoid stale memory?
Use expiry, event-driven invalidation, last-confirmed dates and live-source refresh before consequential action.
What comes next?
Continue to How to Create a Reliable Source of Truth for Super Intelligence, which defines the authoritative-state architecture that memory and retrieval must defer to.
The Final Memory Principle
Good memory reduces repeated context without reducing contact with reality. It remembers preferences, decisions and continuity while live systems continue to own volatile truth.
The best personalised workplace SI feels familiar because it knows how to work with you, yet remains trustworthy because it knows when to forget, refresh and ask the source again.
The Memory Write Decision
Before new information becomes persistent, ask whether the system should write it at all. A useful write decision checks scope, sensitivity, confidence and likely future value. Temporary conversation content should remain temporary unless continuity clearly benefits.
The most dangerous memory systems are not those that forget too much; they are those that quietly promote every interaction into durable context.
The Memory Read Decision
A remembered item should be read only when it is relevant to the current task and permitted for the current user. A project preference from one account should not leak into another account simply because the same employee is involved.
Relevance filtering is part of memory quality. The right memory at the wrong moment becomes noise.
The Memory Update Decision
Some memories should be overwritten; others should preserve history. A changed preferred output style can usually replace the old one. A changed project decision may need both the previous state and the new confirmed state so later teams can understand the transition.
The Memory Forget Decision
Forgetting should occur when purpose ends, access ends, the project closes, the information becomes obsolete or retention is no longer justified. A system that can remember but cannot forget is not operationally mature.
The Memory and Source-of-Truth Boundary
A practical way to avoid memory drift is to draw a line: memory may describe who the user is, how they like to work and what the project has been doing; the source of truth determines what is true now.
When the next task depends on current pricing, permissions, account status, financial figures, inventory, policy or schedule, the system should refresh the authoritative source instead of trusting recollection.
The Memory and User-Experience Balance
A memory system should make work feel continuous without becoming intrusive. Too little memory forces repeated setup. Too much memory can feel presumptive, expose sensitive context or make the system cling to an outdated view of the user.
Good personalisation is quiet: the system remembers enough to reduce friction, surfaces important assumptions when they matter, and allows the user to correct or override the context easily.
The Final Memory Checklist
- Every persistent item has a purpose.
- Scope is no broader than necessary.
- Source and provenance are known.
- Freshness or expiry is defined where needed.
- Users can correct inaccurate context.
- Current authoritative sources override memory.
- Sensitive data has appropriate access and retention controls.
- Closed projects and changed roles trigger retirement.
- Agents refresh live state before consequential action.
- Shared organisational knowledge is not trapped in personal memory.
The Memory Standard
Workplace memory is successful when it reduces reconstruction without creating hidden authority. It should help the system remember how to work with the user while still knowing when the real world must be checked again.
That principle creates the bridge to the next article: a reliable source of truth. Memory gives continuity; the source of truth gives authority.