A project manager asks ChatGPT to remember how her team writes proposals.
That sounds harmless. The assistant can remember the preferred tone, the service tiers, the usual approval path, and the fact that pricing language should stay conservative until finance reviews it. Next time, the draft starts closer to finished.
Then the same assistant starts remembering client names, an unresolved contract dispute, a discount exception, a personal note from a sales call, and a password-reset workaround someone pasted into the chat because it was faster than opening the ticket system.
The feature did not become dangerous because memory is bad. It became risky because no one decided what memory is for.
OpenAI's June 4 RSS item for "Dreaming: Better memory for a more helpful ChatGPT" describes a new memory system meant to remember preferences and keep context fresh and relevant across conversations. On the same day, OpenAI also highlighted how Endava is redesigning software delivery around AI agents, using agents, ChatGPT Enterprise, and Codex across software delivery workflows.
Those two signals belong together. AI assistants are moving from isolated chats into daily work. As soon as that happens, memory stops being a personalization feature and becomes part of the operating model.
The useful version of memory
The best use of assistant memory is not secret storage. It is preference and context continuity.
A useful assistant can remember that your company calls prospects "clients," not "users." It can remember the preferred structure for a project update. It can remember that support summaries should include the customer's desired outcome before the troubleshooting steps. It can remember that a service page should avoid hard ROI promises unless the number came from a named source.
That kind of memory reduces repetitive steering. It makes the assistant less generic. It helps the team avoid re-explaining the same house style, tool stack, and workflow expectations every day.
The problem is that real business conversations do not arrive neatly separated into safe preferences and sensitive facts. People paste whatever is in front of them: customer tickets, meeting notes, account histories, screenshots, vendor terms, internal frustrations, implementation details, and half-formed decisions.
If a tool can remember, a business needs a rule for remembering.
Four buckets before you turn memory loose
Do not start with a 40-page AI policy. Start with four buckets the team can actually use.
Remember. These are durable preferences that make the assistant better without increasing business risk. Examples include writing style, preferred project vocabulary, public service descriptions, internal formatting conventions, non-sensitive tool preferences, and approved reusable explanations.
Review before remembering. These are facts that may be useful later but deserve a human check. Examples include pricing assumptions, workflow exceptions, named account context, implementation constraints, customer-specific preferences, legal interpretations, or anything that could steer future work if it is wrong.
Forget after the task. These are details that help the current answer but should not become durable memory. Examples include one-off meeting notes, temporary campaign details, draft strategy debates, unapproved roadmap ideas, incident notes, and internal critique.
Never remember. These are facts the assistant should not retain as durable context. Examples include credentials, secrets, payment details, private health or financial information, HR issues, security vulnerabilities before disclosure, customer records beyond approved policy, and anything copied from a system with stricter access controls.

This is a simple model, but it changes the conversation. The question becomes less "Should we use memory?" and more "Which facts deserve continuity, which facts need expiration, and who approves the boundary?"
Memory freshness matters as much as memory safety
Stale memory is a quiet failure mode.
A sales assistant that remembers last quarter's packaging can keep writing the wrong offer. A support assistant that remembers a workaround after engineering fixes the bug can keep recommending a dead path. A delivery assistant that remembers an old approval chain can route work to the wrong person. A hiring assistant that remembers an old role description can keep filtering candidates against the wrong expectations.
Freshness needs its own rule.
For stable preferences, review quarterly. For pricing, packaging, regulatory, support, and implementation facts, use shorter review windows. For account-specific details, tie memory to the account record rather than leaving it buried inside a personal assistant. For temporary projects, expire memory when the project closes.
This is where the phrase "keeping context fresh and relevant" becomes operational. Freshness is not a vibe. It is an owner, a review date, and a path to correct or delete the remembered fact.
Individual memory and shared memory are different products
A personal assistant remembering a writing preference is one thing. A company assistant remembering operational context is another.
Small teams blur this line quickly. The founder has the most context, so their assistant becomes the unofficial memory of the business. A delivery lead pastes customer constraints into chat, so the assistant becomes the unofficial account file. A support lead asks for better macros, so the assistant becomes the unofficial knowledge base.
That may work for a week. It does not scale.
Shared business memory should live closer to governed systems: documentation, CRM records, ticket histories, approved knowledge bases, policy pages, and project files with permissions. The assistant can retrieve from those sources, summarize them, and help maintain them. But durable company memory should not depend on whatever one person happened to tell a chatbot three months ago.
This is the same reason our data security work starts with access boundaries. Useful automation still needs to respect where the source of truth lives, who can see it, and how corrections happen.
What to put in the policy
A practical AI memory policy can fit on one page.
Start with the approved memory types:
- writing and formatting preferences
- public company positioning
- approved service descriptions
- non-sensitive workflow preferences
- team vocabulary and naming conventions
- reusable checklists that have an owner
Then list the blocked memory types:
- secrets, credentials, tokens, and access instructions
- customer records unless explicitly approved
- personal employee information
- regulated data
- unresolved legal, HR, or security matters
- private financial or payment details
- temporary decisions that have not been approved
Add review rules:
- who can approve a remembered fact
- how long different memory types last
- where the source of truth lives
- how a person can inspect, correct, or delete memory
- what must be logged when memory influences customer-facing work
Finally, add a fallback rule: if the assistant is not sure whether something should be remembered, it should ask or treat the fact as task-only context.
That one rule prevents a lot of accidental retention.
The better workflow
The better workflow is not "turn memory off forever."
It is also not "let the assistant remember everything because it feels smarter."
The better workflow is controlled continuity. Give the assistant enough context to reduce repetitive steering. Keep sensitive facts in governed systems. Review memories that affect decisions. Expire temporary context. Log memory use when it shapes customer-facing work.
If your team is already using ChatGPT, Claude, Gemini, Copilot, or internal agents every day, memory is probably happening informally even if no one calls it that. People are copying old examples into new chats. They are keeping prompt libraries. They are storing snippets in docs. They are teaching assistants the same preferences over and over.
A formal memory feature simply makes the boundary visible.
That is the moment to tighten the operating model.
The strategic point
AI memory is useful because businesses repeat themselves.
The danger is that businesses also forget to clean up what they repeated.
Treat memory as a small governance surface. Decide what the assistant may remember, what expires, what needs review, and what never belongs there. Then connect those rules to the same systems you already use for customer data, knowledge management, and approval.
A smarter assistant is helpful. A smarter assistant with clear memory boundaries is usable.
If you want help turning that into a practical policy for one workflow, map your AI memory boundaries with BaristaLabs.
Review your data security posture
Review your data security posture
Start with the boundaries around customer data, credentials, internal notes, and approval paths before expanding AI memory.
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.
Share this post
