AI Employee Memory: What It Should Remember - and Forget

§ 01AI Employee Memory at a Glance

§ 02What Is AI Employee Memory?

AI employee memory is persisted information that a standing AI role can use across tasks, sessions, shifts, or handovers to continue work without rebuilding all relevant context from zero.

The important word is persisted. A model’s current context disappears when the interaction ends unless a system deliberately stores something and makes it available later. An AI employee platform can create continuity by saving role configuration, project knowledge, work state, decisions, or other records outside the immediate model call.

That continuity is one reason an AI employee differs from a one-off assistant. The role can resume work, apply approved operating knowledge, and carry forward unresolved items. But persistence also creates a governance obligation: yesterday’s context can shape tomorrow’s action.

Memory is not the same as context

Memory is information available for future use. Context is the subset placed in front of the model for the current decision.

A memory store might contain 10,000 records. The next task may require 12. Good retrieval chooses the relevant 12, explains their authority, and leaves the rest out.

Anthropic describes context as a finite resource and recommends selecting the smallest high-signal set needed for an agent’s next action. Its context-engineering guidance also warns that accumulating context can reduce performance when irrelevant or conflicting material consumes attention.

Memory is not the source of truth

A source of truth is the authoritative system or approved document. Memory is a representation that helps the employee use that truth.

For example: the CRM is the source of truth for account ownership; the policy repository is the source of truth for the current refund rule; the task board is the source of truth for task state; memory may preserve the customer’s approved communication preference or the rationale behind an earlier decision.

If memory and the authoritative source disagree, the source hierarchy should decide which one wins. “The agent remembers it” is not evidence.

Memory is not a log

A log records events for diagnosis, security, or audit. Memory changes future work.

The employee does not need every tool call in active memory. It may need the conclusion, the supporting source, the resulting decision, and the unresolved exception. Keep raw execution history in the appropriate log system and promote only useful, validated information into memory.

Memory is not training

Saving a preference or decision does not necessarily retrain the underlying model. Most operational memory systems store external records and retrieve selected material at runtime.

This distinction matters for correction. A stored record can be edited, superseded, or deleted without changing model weights. A buyer should confirm how a platform implements memory rather than using “learning” as a catch-all term.

§ 03Why Should an AI Employee Remember Anything?

Without memory, a standing AI role is repeatedly briefed like a new contractor on its first morning.

It may ask the same questions, reopen settled decisions, forget corrections, duplicate research, lose customer commitments, and rebuild task context at every shift. Humans then become the continuity layer.

Continuity across shifts

A useful memory system preserves: what the role is responsible for; what was already attempted; which source resolved a question; what remains blocked; who owns the next decision; what must happen by a deadline; and which correction should prevent a repeated error.

This does not replace a structured handover. It makes the handover durable and retrievable, while the handover protocol must still define ownership, required context, acceptance, and closure.

Consistent application of approved knowledge

An employee can apply the same approved definition, policy hierarchy, writing preference, or escalation boundary across recurring work.

Consistency is valuable only when the knowledge is current. A remembered 2025 policy should not override a version effective in 2026. Store the version, effective date, and owner with the content.

Less repetitive human supervision

If a reviewer corrects the same entity name, evidence rule, or account preference every week, the operating system is wasting correction effort.

The correction should become one of three things: a source-of-truth update; a scoped memory record; or an evaluation case that tests whether the role applies the rule.

Which route is correct depends on authority and reuse. Not every correction deserves permanent memory.

Better recovery after interruption

Long-running work is frequently interrupted by waits, tool failures, approvals, shifts, or new information. Memory can preserve the work’s compressed state so the employee resumes from a verified checkpoint instead of guessing from an old conversation.

The key is to save state that supports resumption: objective, completed work, evidence, open questions, next action, dependencies, and expiry. “Continue working” is not enough.

§ 04What Should an AI Employee Remember?

Remember information that is reusable, verified enough for its purpose, permitted for the role, and cheaper or safer to preserve than to reconstruct.

Use five operational scopes. These are business scopes for deciding access and retrieval - not a technical taxonomy of how models implement memory.

1. Role memory

Role memory defines the standing job.

Role charter and boundaries. Store the role’s purpose; in-scope and out-of-scope work; approved goals; quality standard; escalation conditions; prohibited actions; required approvals; and completion definition. These records should point to the current role charter rather than becoming an independent copy with no owner.

Source and policy hierarchy. The employee should know which sources are allowed and which source wins during conflict. For example: (1) current legal or security policy; (2) approved product documentation; (3) live system-of-record data; (4) manager-approved operating decision; (5) prior work and memory; (6) unverified external material. The exact order varies by role. The important point is that memory does not automatically outrank a current authoritative source.

Stable preferences. Remember a preference when it is genuinely useful across tasks; approved or explicitly expressed; scoped to the right person, account, or role; not sensitive beyond the role’s need; correctable; and distinguishable from a temporary request.

“Use UK spelling for Acme’s public content” can be a stable account preference. “Make this email shorter” may apply only to one draft.

2. Organizational and reference memory

This scope helps a role navigate the company’s approved knowledge.

Definitions and named entities. Store canonical names, approved definitions, product relationships, team ownership, and common disambiguations - ideally with links back to the governing source. Do not copy every document into memory. Store enough structure to locate and interpret the right material.

Approved decisions and rationale. Remember decisions that affect future work: what was decided; who approved it; when it became effective; which scope it covers; why it was chosen; which alternatives were rejected; what event triggers reconsideration; and where the evidence lives. Rationale prevents a later employee from treating a deliberate exception as an unexplained inconsistency.

Known corrections and failure lessons. If the employee previously used the wrong definition, missed a source, or overstepped a boundary, preserve the durable lesson. Write the memory as an actionable correction:

For pricing comparisons, use the current pricing page captured on the review date. Do not reuse amounts from earlier drafts. Escalate when the public page and sales documentation differ.

Avoid: “Pricing was wrong last time.” The first record supports future behavior. The second preserves shame without instruction.

3. Relationship or account memory

Account memory can reduce repeated questioning while keeping one customer’s information out of another customer’s work.

Verified account facts. Useful examples include the approved company name and domain; account owner; contracted product or plan; operating region; relevant lifecycle state; declared communication preference; active constraints; and the authoritative system record. Retrieve these only inside the matching account scope.

Commitments and unresolved questions. Remember what the organization promised, who made the commitment, the due date, and the completion condition. Also preserve uncertainty:

The customer asked whether EU processing is available. No approved answer was found as of July 18. Owner: security. Do not infer; escalate before responding.

An explicit unknown is safer than a plausible invented answer.

4. Task and progress memory

Task memory helps work resume after a pause.

Current objective and accepted completion state. Store the requested outcome, deadline, relevant constraints, owner, and definition of done. Avoid reducing the task to the most recent message. Earlier requirements may still govern the work.

Work completed and evidence gathered. Record completed steps; sources examined; important findings; failed approaches; the current artifact location; review status; and unresolved conflicts.

Next action and blockers. A resumable record names one next action and the condition that unlocks it:

Await finance approval on invoice variance. When approval arrives, update the reconciliation row, verify the final total, and route the report to the controller.

That is more useful than preserving the entire conversation that produced it.

5. Decision and correction memory

This scope preserves how the role should behave after review.

Human decisions. Remember approvals, rejections, exceptions, and narrowed permissions with the actor, timestamp, scope, and expiry. An approval for one $200 refund should not silently become a general rule allowing every $200 refund.

Supersession. When a fact changes, preserve the relationship: old record; new record; effective date; reason; approver; downstream memories or tasks affected; and whether the old record must remain discoverable for audit.

Durable corrections. A correction becomes durable memory only after deciding its scope:

§ 05What Should an AI Employee Forget?

Forgetting has three forms:

1. Do not capture: the information should never become memory.
2. Stop retrieving: the record may need to exist for a limited business purpose, but it should not influence normal work.
3. Delete: the record no longer has a valid purpose or must be removed under the applicable policy or request.

Treat these as separate controls. Hiding a record from retrieval is not the same as deleting it.

Never store secrets in general memory

Do not place these in ordinary AI memory: passwords; API keys; recovery codes; access tokens; browser cookies; private encryption keys; secret answers; or raw authentication headers.

Use a dedicated secret manager or platform credential mechanism. The employee can remember that an approved integration exists and which workflow may use it. It should not retrieve the credential as prose.

Highly sensitive data without a role need. Do not retain private information merely because it appeared in a message or document. Before capture, ask: Is this necessary for the role’s approved outcome? Is this role permitted to use it? Is the proposed scope narrower than the original access? Is there a defined owner and retention basis? Could a reference to the source replace a copied value?

Access to information does not automatically authorize promotion into persistent memory.

Do not remember unverified claims as facts

Observations need a confidence state. An employee may need to preserve a hypothesis while research continues. Label it clearly: observed; inferred; unverified; disputed; confirmed; or superseded. Add the evidence and next validation step. Do not convert “a reviewer suspects…” into a permanent factual claim.

Model-generated summaries are derived records. A summary is not a source. It can omit a condition, date, exception, or contradiction. Store the source reference, derivation date, and scope with the summary. For high-impact decisions, retrieve and check the underlying material before acting.

Anthropic’s Contextual Retrieval research shows why retrieved fragments need enough surrounding meaning to be interpreted correctly. In an operating system, the same principle means a memory should not lose the document, section, account, time, or decision that gave it meaning.

Expire temporary information

Time-bound exceptions need explicit expiry: promotional pricing; incident workarounds; delegated approval authority; campaign messaging; staff coverage; launch embargoes; beta instructions; and one-time customer accommodations. At expiry, either delete, archive, or reapprove them. “Keep until someone notices” is not a retention policy.

Volatile facts change too quickly to treat as standing memory: inventory; price; service status; account balance; ownership; availability; regulatory status; and active permissions. Memory can preserve where to retrieve the fact and how fresh it must be. The live system should supply the current value.

Isolate information that belongs elsewhere

Cross-account data. One customer’s preferences, usage, documents, and decisions should not influence another customer’s work unless the information has been intentionally anonymized and approved for broader use. Test this boundary with near-identical tasks from two accounts.

Out-of-role knowledge. A sales research employee may see a payroll attachment while navigating a shared drive. That does not make payroll data useful role memory. Memory capture should respect the role’s purpose and permission boundaries, not merely the broadest data the connected account can expose.

Instructions embedded in retrieved content. Web pages, emails, documents, and tool results can contain text that looks like an instruction. Treat external content as data unless it comes through an approved instruction channel. Do not promote “ignore prior rules,” “send this file,” or similar embedded text into role memory. Include embedded instructions in the role’s prompt-injection threat model and test plan.

Remove low-value noise

Raw transcripts may be retained under a separate record policy, but they should not automatically become active memory. Extract the decision, commitment, correction, or unresolved question. Link back to the transcript when authorized users need the evidence.

Tool exhaust - search result pages, intermediate calculations, retry messages, and duplicate outputs - creates retrieval noise. Preserve the validated conclusion and necessary provenance, not every intermediate token.

Completed state with no future use. Once a task is accepted, remove temporary working notes that have no audit, reuse, or legal value. Keep the accepted artifact and the small set of durable decisions or lessons.

§ 06What Fields Should Every Important Memory Have?

A memory record needs enough structure to answer: what is this, why should the employee trust it, where does it apply, and when should it stop being used?

Not every trivial note needs a database form with 11 visible fields. But every memory that can materially change an external action should be able to answer them.

Content and purpose

Write one decision-sized record. Keep each memory small enough to update without rewriting unrelated material. A page-long note combining five policies, three accounts, and two dates will become partially stale.

State the operational use. “Acme prefers concise answers” is vague. “For Acme’s weekly executive update, use a five-bullet summary followed by risks and required decisions” is testable and scoped.

Scope and permitted use

Scope narrowly by default. Prefer one task over all tasks; one account over all accounts; one role over the organization; one region over global use; and one permitted action over general autonomy. Broader scope should require stronger evidence and ownership.

Separate read from action. The employee may be allowed to use a memory when drafting but not when executing an irreversible action. Remembered refund context may support a proposed resolution; the actual refund can still require live verification and approval.

Provenance and authority

Link to the governing source. Store a stable identifier, URL, document version, or system record ID. A source label like “company docs” is too broad.

Preserve transformations. If a memory summarizes three sources, list them and record how conflicts were resolved. If a human approved the synthesis, capture that decision.

Freshness and supersession

Use event-based expiry where possible. Calendar dates are useful, but business events are often better: until contract renewal; until campaign closes; until policy version changes; until incident is resolved; until a named approval is revoked; or until the task is accepted.

Never overwrite silently. If the old record affected prior work, supersede it rather than erasing its existence. Authorized reviewers may need to understand why the employee made an earlier decision.

Confidence and unknowns

Confidence is not a decorative percentage. It should decide behavior:

Avoid false precision. “83% confident” is not useful unless the organization has calibrated what that score means. Plain operational states are often easier to test and govern.

§ 07How Should the AI Employee Memory Lifecycle Work?

Use seven stages: propose, validate, store, retrieve, apply, review, and retire.

Stage 1: Propose. A candidate memory may come from an approved configuration; an authoritative source; a human decision; a correction; a completed task; a handover; an account interaction; or the employee’s own observation. At this stage, it is not automatically trusted. Filter for future value: will the information predictably reduce repeated work, prevent an error, support continuity, or preserve an important commitment? If it is useful only in the current context, leave it in task state.

Stage 2: Validate. Confirm the source - authority, version, effective date, and whether the source actually supports the proposed memory. Confirm permission and sensitivity: verify that the role can retain and later use the information, not merely view it during one task. Resolve conflict: if another memory or source disagrees, do not store both as equally current.

Stage 3: Store. Attach scope, provenance, owner, dates, status, sensitivity, permitted use, and supersession metadata. Keep source content separate from instructions - documents and messages may contain untrusted text; store their factual content under the appropriate data scope, not as higher-priority operating instructions.

Stage 4: Retrieve. Filter by active role; project or account; task type; jurisdiction; time; permission; sensitivity; record status; and source authority. Then rank for relevance. Prefer progressive disclosure: retrieve a small index or summary first, then fetch the underlying detail when the task needs it.

Stage 5: Apply. For high-impact work, record which memories influenced the output or action. This makes a wrong result diagnosable. Recheck live facts: memory may guide the method while a live system supplies the current value.

Stage 6: Review and correct. A reviewer should be able to identify the wrong record; the correct value or rule; the source; affected scope; urgency; whether completed work must be reopened; and whether an evaluation case should be added. Propagate the correction: correct the source or memory, invalidate derived summaries, re-index if necessary, and identify affected open tasks. A green “memory updated” message is not proof that every retrieval path stopped serving the old record.

Stage 7: Retire. Choose archive (preserve for authorized historical review, exclude from current retrieval), suppress (temporarily prevent use during a dispute or incident), or delete (remove under the applicable process). Verify downstream removal: check indexes, summaries, caches, embeddings, exports, derived records, and queued tasks where applicable.

§ 08How Should Memory Retrieval Work?

The employee should retrieve by task need, authority, scope, and freshness - not by semantic similarity alone.

A record can sound relevant while being: for the wrong customer; from the wrong region; no longer current; derived from a weak source; outside the role’s permission; intended only for investigation; superseded by a later decision; or too sensitive for the present action.

Use hard filters before ranking

Before similarity ranking, filter out records that fail mandatory conditions: tenant or organization; account; role; project; sensitivity; permission; valid time window; and active status. This reduces the chance that a highly similar but prohibited memory enters context.

Ranking can then consider direct task match; source authority; recency; specificity; prior usefulness; unresolved conflict; relationship to the active artifact; and evidence completeness.

Relevance should not overpower authority. An old answer containing the exact keywords should not outrank the current policy.

Retrieve both the claim and its frame

Include provenance. For material records, the employee needs the source, date, scope, and status beside the content. Otherwise it cannot determine whether the memory is safe to apply.

Include the exception. If a policy says “allowed only when A and B are true,” storing “allowed” without the conditions changes the rule. Test chunking and summarization against conditions, negations, tables, footnotes, and cross-references.

Use a context budget

The current request, live evidence, operating instructions, tool output, and response all compete for finite context. Memory should not consume the entire budget before the employee starts.

Set budgets by role and task risk. A routine classification may need a small policy excerpt. A complex exception investigation may justify more sources and conflict history.

Compress with loss checks. Compaction helps long-running work, but compression can remove a deadline, caveat, or unresolved conflict. Test the compacted state: Is the objective intact? Are constraints intact? Are sources traceable? Are unknowns still unknown? Are completed and pending work separated? Is the next action explicit? Did any exception become a general rule?

Let the employee abstain

Missing memory is a valid result. If no current, in-scope record exists, the employee should retrieve from the source, ask a person, or escalate. It should not fill the gap with the closest remembered answer.

Conflict is a valid result. If two authoritative records disagree, show the conflict and owners. Retrieval should not silently choose whichever item scored slightly higher.

§ 09What Are the Main AI Memory Failure Modes?

Memory failures can originate during capture, storage, retrieval, use, correction, or retirement. Diagnose the stage before adding more prompts.

Stale and superseded memory. Sample high-impact responses and compare their cited memory version with the current source. Require effective dates for volatile rules, schedule review, and trigger invalidation when the governing document changes.

Scope leakage. Create two synthetic accounts with similar names but conflicting preferences. Run the same task for both and inspect retrieved record IDs. Use hard account or project isolation before semantic search.

False or unsupported memory. Ask for the source behind randomly sampled records. A memory with no recoverable provenance should not support a factual external claim.

Retrieval miss. Build a gold set of realistic questions with expected records. Measure whether the required memory was retrieved, whether irrelevant records crowded it out, and whether the employee used it correctly.

Context pollution. Compare performance with the full retrieved set, a curated minimum set, and no memory. If the minimum set performs better, the issue is selection rather than capacity.

Poisoned memory. Place benign test instructions in untrusted documents and verify that they are not promoted into role memory or followed as policy.

§ 10How Do You Govern Correction, Retention, and Deletion?

Memory governance should answer who may view, add, approve, edit, suppress, export, and delete each class of record. The organization owns that operating policy even when a platform supplies the storage and controls.

Assign memory owners

The business owner decides whether a memory is useful for the role and which outcomes it may influence. The knowledge owner confirms the source, version, interpretation, and review cadence. The security or privacy owner sets sensitivity, access, retention, incident, and request-handling requirements.

One person can hold more than one role in a small company. The decisions still need explicit ownership.

Create correction paths

A useful correction request includes: the record or output affected; current content; proposed correction; supporting source; scope; urgency; requester; approver; affected open work; and desired deletion or history treatment.

Emergency suppression. Give authorized operators a fast way to stop retrieval of a dangerous record while the root cause is investigated. Emergency suppression should create an incident or review record, not become an invisible permanent workaround.

Define retention by record class

Use purpose, not one universal duration. Role charters, customer preferences, task notes, approval records, raw transcripts, security logs, and deleted-account data may need different treatment.

For each class, specify: purpose; system; owner; legal or contractual requirement; active period; archival period; deletion event; permitted access; derived copies; and verification method.

A complete privacy and retention policy requires legal, security, and operational input. The immediate operating rule is simpler: no memory should exist indefinitely merely because the system can retain it.

Make deletion testable

Ask whether deletion applies to: the primary record; the search index; the embedding or vector representation; derived summaries; caches; exports; backups; audit history; and downstream artifacts already created from the memory. The correct treatment varies. Buyers should understand the actual behavior and any policy or legal limits.

After a deletion or correction, rerun representative tasks. Confirm that the old record is not retrieved or used and that the replacement behaves as intended.

§ 11How Does CellCog Handle AI Employee Memory?

CellCog AI Employees are presented as standing roles with goals, shifts, tasks, memory, handovers, approvals, and work surfaces. That product model makes continuity useful: the employee can operate across shifts rather than starting as a blank chat each time.

The buyer still needs to decide what information belongs in the role, how it is scoped, and how corrections or deletion requests are handled.

Persistent role memory and Context Trees

CellCog’s Memory System Guide describes Context Trees as hierarchical document stores that can be associated with projects, agent roles, and organizations. That hierarchy can support useful scope: organization knowledge shared across approved roles; role-specific operating context; project material available only to the relevant work; and references that the employee can retrieve when needed.

When roles coordinate, use the AI employee collaboration model to exchange versioned artifacts and minimized task context rather than copying accumulated memory between workers. Shared sources can remain authoritative while role working memory stays scoped.

The shared versus role-specific AI memory architecture defines the read/write topology, promotion rules, retrieval gates, poisoning controls, correction propagation, and migration method for that boundary.

If task ownership also moves, the AI agent handoff protocol specifies which source references, prior decisions, artifact versions, uncertainty, and authority must travel - and which accumulated role memory should stay behind.

Buyers should verify the current in-product behavior, permissions, correction flow, and retrieval boundaries against their own use case. The memory section of the 50-question AI employee platform RFP turns those requirements into proof requests.

Memory updates

CellCog’s Chat Guide documents an “Update Agent Memory” action. Use deliberate updates for durable corrections and preferences rather than assuming every chat message should become permanent. Before updating, attach the source, scope, owner, and review condition.

Retention is not the same as provider inference retention

CellCog’s current Privacy Policy, effective May 14, 2026 and last updated June 20, 2026, says: an AI Employee’s mailbox, memory, and workspace are retained until the user deletes the AI Employee or account; configuration, mail, memory, work artifacts, and actions on connected accounts can be processed as part of the service; current LLM providers operate under zero-data-retention API terms for inference content; and users may request access, correction, deletion, and portability, subject to the policy.

Those statements describe two different layers:

1. CellCog service memory: intentionally persists to create employee continuity.
2. LLM inference handling: the policy says current model providers do not retain inference content under their API terms.

“Zero retention by the model provider” does not mean “the AI Employee has no persistent memory.” Conflating the two leads to incorrect security and deletion assumptions.

User responsibility and autonomous action

CellCog’s Terms of Service says an AI Employee may act across shifts with its own memory and may operate without per-action approval, depending on configuration. The terms also place responsibility for the employee’s actions on the user.

That makes memory quality part of action governance. A stale rule is more consequential when the employee can use it to take an external action.

Pair memory scope with the permission-and-approval matrix: broad memory access does not require broad action access; a remembered preference does not waive an approval; a prior approval does not authorize a new case; current system state should be checked before irreversible action; and high-impact memories should be traceable to their owner and source.

What to verify in a CellCog pilot

Memory behavior. Test which interactions become memory automatically or manually; how Context Trees are scoped; what metadata is visible; how the employee chooses among conflicting records; whether a corrected memory stops appearing; whether role deletion removes memory from normal retrieval; and which logs or historical records remain under the applicable policy.

Boundary behavior. Test two similar projects with conflicting rules; one expired exception; one unverified observation; one sensitive source the role may view but should not preserve; one instruction embedded in an untrusted document; one corrected policy summary; and one deleted employee/account request using the documented process.

Document observed behavior rather than assuming the public label “memory” answers every architectural question.

§ 12How Do You Build a Safe Memory System for One AI Employee?

Start with one role and one recurring workflow. Do not import the entire company drive.

Step 1: Write the memory purpose. Complete this sentence: This role needs memory so it can ___ across ___ without repeatedly ___. Example: “The competitive-research employee needs memory so it can track verified competitor entities and prior corrections across weekly scans without repeatedly rebuilding the monitored-company map.” If the sentence says only “so the AI knows our business,” the scope is too broad. Then name the prohibited uses: no customer PII in organization-wide memory; no remembered price used without a live check; no external send based only on a prior approval; no cross-project retrieval; no inferred claim presented as confirmed; and no credentials in memory.

Step 2: Inventory candidate memory. For each workflow stage, list information repeatedly reintroduced; decisions repeatedly reopened; corrections repeatedly made; commitments easy to lose; source locations hard to rediscover; and volatile facts that should remain live lookups. This inventory complements the task-fit analysis in the best tasks for AI employees guide. Classify each candidate: source of truth; role memory; organization/reference memory; account memory; task state; handover; log only; secret store; or do not retain.

Step 3: Create the source hierarchy. Rank authority with real systems and owners:

For each pair likely to disagree, specify whether the employee should prefer one source; retrieve a fresher value; preserve both and surface the conflict; pause action; or request approval.

Step 4: Define the record schema. A low-impact writing preference may need a source, account scope, owner, and review date. A record capable of authorizing an external action needs the full schema and stronger approval. State which channels may propose memory and which roles can approve it.

Step 5: Configure retrieval. Implement tenant, account, project, role, sensitivity, time, and status filters as enforceable system controls where the platform supports them. Tell the employee to prefer current authoritative sources; expose important provenance; distinguish confirmed from inferred; recheck volatile facts; retrieve only the active scope; abstain when no adequate record exists; and surface conflict rather than averaging it away.

Step 6: Seed only the minimum. Seed the role charter; source hierarchy; five to ten recurring definitions or decisions; critical escalation conditions; a small set of verified account or project facts; and known corrections that prevent repeated failure. Link, do not duplicate: store a structured pointer and summary that leads to the current source.

Step 7: Test before expanding. Build four test sets: positive retrieval (the correct memory should appear); negative retrieval (a tempting but out-of-scope memory must not appear); freshness/conflict (a newer source must beat an older memory); and correction/deletion (the old record must stop affecting work). Connect tests to role acceptance: measure whether completed work is accepted, whether evidence is visible, whether escalation is correct, and whether review effort falls, per the AI employee KPI framework.

Step 8: Launch with review. During onboarding, sample tasks where memory changed the answer or action. The AI employee onboarding guide uses a staged progression from observation through supervised production. Expand memory scope only when the current role produces accepted work; correction paths work; cross-scope tests pass; stale records are detected; reviewers can trace important use; and deletion or retirement behavior has been verified.

§ 13What Does Good AI Employee Memory Look Like in Practice?

Two worked examples show how to convert vague “learning” into governed continuity. All names and records below are illustrative.

Example 1: Competitive-research employee

The employee produces a weekly briefing for an approved list of competitors.

It does not remember a competitor’s current price as permanently true. It remembers the pricing source and the requirement to verify it during the current scan.

For each monitored company, the employee retrieves canonical entity identifiers; relevant prior correction; current-week task state; approved source order; and output format. It then performs fresh research. Prior findings help target the scan but do not substitute for current evidence.

When the watchlist changes, retired entities leave active retrieval. Old briefing observations remain in the historical artifact if policy allows, but do not become current facts.

Example 2: Support-drafting employee

The employee drafts responses for a human reviewer. It does not send high-risk answers autonomously.

If account memory says the customer is eligible for a feature but the live account system says otherwise, the employee: treats the live system as current; marks the memory for correction; avoids promising access; surfaces the conflict to the reviewer; and preserves the customer’s question as open task state.

After the account owner confirms the change, the record is superseded, affected draft work is rechecked, and the conflict becomes a regression case.

§ 14How Do You Measure AI Employee Memory Quality?

Measure whether the right memory reaches the right task, stays current, and improves accepted outcomes without creating unacceptable risk. Do not use memory count as the primary KPI.

Retrieval metrics. Required-record recall = cases retrieving the required record ÷ cases where the record was required. Retrieval precision = useful permitted records ÷ reviewed retrieved records. High recall with poor precision creates context pollution. High precision with poor recall leaves the employee uninformed.

Freshness and integrity metrics. Superseded-memory exposure (tasks where a superseded record entered context); provenance completeness (share of material records with accessible source, owner, scope, status); conflict-resolution quality (whether the employee applied the hierarchy, escalated appropriately, and avoided unsupported certainty).

Correction metrics. Correction propagation time (from approved correction to consistent use of the new record); repeat-memory error rate (same root-cause error after correction); memory-caused correction minutes (human time fixing work where retrieved memory was stale, false, irrelevant, or out of scope).

Boundary and risk metrics. Cross-scope retrieval incidents; sensitive-memory exposure; deletion verification (share of sampled deletion requests passing post-deletion checks within the required time).

Outcome metrics. Compare memory-enabled and controlled baseline work on first-pass acceptance; repeated-question frequency; reviewer correction minutes; correctly escalated unknowns; missed commitments; cycle time; reopened work; and incident severity.

Memory is successful when it improves the role’s accepted outcome while staying inside its risk boundaries - not when the employee sounds familiar.

§ 15The Bottom Line

An AI employee should not remember everything it has seen. It should remember what its role is allowed to reuse, with enough provenance and scope to know when that information applies.

The operating standard is straightforward:

1. preserve verified role knowledge, decisions, commitments, corrections, and resumable state;
2. keep secrets, irrelevant private data, raw noise, and untrusted instructions out;
3. retrieve the smallest current, permitted set for the task;
4. prefer authoritative live sources over remembered copies;
5. make uncertainty and conflict visible;
6. propagate corrections across every retrieval path; and
7. retire memory when its purpose ends.

For implementation, hire one bounded CellCog AI Employee role, establish its source and permission contracts, and seed only the memory it needs to pass realistic work. Then verify retrieval, correction, and deletion behavior before expanding the role.