When AI Names the Wrong Client, Check Memory Before Continuing

For AI human review, the first decision is whether one small example can be reviewed by a person. An AI draft that names the wrong client needs review before it leaves your workspace. Pause delivery, compare the answer with the intended client’s brief, and inspect which conversations, files, instructions, and memory settings were available. Then use fictional clients with conflicting requirements to check whether information crosses the boundary you intended.

Immediate action: Hold the affected draft and identify every detail that does not belong.

Settings decision: Choose the narrowest documented context scope suitable for the client’s work.

Evidence to keep: Record the visible settings, exact output excerpt, and requirement it contradicts.

This playbook offers a check you can start with fictional material in your existing workspace, without purchasing anything. It does not establish that a particular product leaks information or that changing a setting guarantees separation.

A wrong name is a clue, not a diagnosis

A client-name mistake tells you that the output failed review. It does not, by itself, explain why.

Possible places to investigate include the current conversation, an attached document, a reused brief, shared instructions, and any enabled memory or history features. These are inspection targets, not confirmed causes. An unfamiliar name could also be an unsupported invention.

Start with the actual mismatch. “The draft mentions the wrong customer” is less useful than “The heading names the fictional client Cloud Orchard, but this draft belongs to Amber Lantern.”

Then inspect the surrounding answer. A wrong name may accompany the wrong audience, offer, tone, or delivery format. Correcting the heading alone leaves those other requirements unchecked.

Treat the wrong name as a reason to inspect the whole deliverable.

What is verified here—and what remains untested

Preparation date: 2026-09-05. Tested date: not available.

No verified memory test, settings screenshot, output transcript, or observed failure was supplied for this article. The tables below are reusable test artifacts, not reported results.

Proposed conditions: fictional client material, deliberately conflicting requirements, separate work areas, recorded settings, and human comparison against the source briefs. Actual testing conditions remain unrecorded until someone performs the check.

There is also no supplied original source establishing a recent change to memory or project behavior. Accordingly, this article makes no announcement about new features, changed defaults, or user reactions.

The practical question remains useful: what information is allowed to influence this client’s answer? Any product-specific answer requires documentation for the feature and configuration being used.

Make the difference easy to catch

Use the following invented briefs. Neither represents a real client or an observed engagement.

Fictional client	Required content	Required tone	Content that does not belong
Amber Lantern	Announce an evening pottery workshop for beginners	Calm and reassuring	Grocery pickup, energetic sales language, Cloud Orchard
Cloud Orchard	Announce a grocery pickup service for busy households	Brisk and energetic	Pottery workshops, calming workshop language, Amber Lantern

Artifact caption: Fictional client briefs with conflicting subjects and tones, designed for checking whether an answer imports unrelated requirements.

Keep each brief in its intended work area. Avoid placing the comparison table itself in either client conversation: it contains both clients’ details and would make the result harder to interpret.

Request the same deliverable type for each client, such as a short announcement. Review the name, subject, audience, tone, and any extra claims against that client’s brief.

This is intentionally uncomplicated. A beginner should be able to spot the mismatch without specialist knowledge.

Choose settings by their documented scope

Feature labels alone do not establish what information a conversation can access. Before relying on a setting, check its explanation in the application and its current official documentation.

Use this table to decide what needs verification.

Situation	Conversation or memory choice to investigate	What to verify	Working decision
A conversation already contains unrelated client material	Start a separate conversation with a clean brief	Whether other context remains available	Do not reuse the mixed conversation for the check
Client work needs reusable reference files	Use a dedicated project or equivalent area, if available	Which files and instructions it includes; whether context can cross its boundary	Keep only that client’s references there
Saved preferences contain client-specific details	Review the saved-memory controls, if available	What disabling, editing, or removing an entry actually changes	Remove client-specific material from broadly applied preferences
A task needs no ongoing personalization	Investigate a temporary or memory-disabled mode, if available	Its documented context, storage, and retention behavior separately	Use it only within those documented limits
The available settings leave the scope unclear	Continue with fictional material only	The unanswered boundary question	Hold real client material until the scope is understood

The useful decision is not simply “memory on” or “memory off.” It is whether the chosen configuration supports the separation your work requires.

A separate conversation is an organizational choice; verify its information boundary before relying on it.

Run the check and preserve the receipt

Begin by recording the visible configuration. Include whether memory or history reference is enabled, which work area contains the conversation, and which files or shared instructions are present.

Create an announcement for Amber Lantern in its designated area. Then create one for Cloud Orchard in its own area. Return to Amber Lantern and request a revision that keeps its original requirements.

That return visit gives you another output to inspect after working on the other fictional client. It is a proposed test sequence, not evidence that switching clients causes contamination.

Compare each answer with its authorized brief. Save the exact excerpt supporting any mismatch. If nothing conflicts, record the narrower result: no mismatch observed in the recorded output under these conditions.

Use this blank ledger:

Test date	Intended client	Visible settings and available context	Exact output excerpt	Requirement check	Action
Not run	Amber Lantern	To record	No output collected	Not assessed	Pending
Not run	Cloud Orchard	To record	No output collected	Not assessed	Pending
Not run	Amber Lantern revision	To record	No output collected	Not assessed	Pending

Artifact caption: Unfilled review ledger. Replace pending entries with observed text and conditions; preserve a private copy of the original output.

If you change a setting, repeat the affected task with the same fictional brief. Change only the setting under investigation so that the comparison remains interpretable.

What this check cannot settle

A clean fictional run cannot prove that all future client work will remain separate. Its evidence covers only the recorded configuration and outputs.

A mismatch also does not prove that saved memory caused it. Check whether the unwanted detail was already present in the conversation, reference files, or shared instructions.

Tone differences require judgment. Client names and workshop-versus-grocery content provide clearer review criteria. Record ambiguous cases as ambiguous rather than forcing a pass or failure.

Do not treat the assistant’s explanation of where a detail came from as an independently verified account. Compare it with the context and settings you can inspect.

Make the boundary review repeatable

Use this checklist whenever a draft names an unexpected client:

• Hold the draft before delivery.
• Check the full answer against the intended brief.
• Inspect conversation content, files, shared instructions, and available memory controls.
• Confirm the documented scope of the chosen configuration.
• Run the fictional-client check and preserve exact excerpts.
• Resolve discrepancies and review the final deliverable again.

Final decision: Use narrowly scoped client context where its behavior is documented, and retain human review before delivery. If the boundary remains unclear, keep real client material out of that configuration.

Copy the ledger and complete a fictional-client check before your next client draft.

Related build logs

• AI Human Review Checklist: Three Moments When a Correct Answer Still Needs You
• AI Human Review: Seed One Safe Error Before You Trust the Checklist