Evolving User Profiles: How Conversational AI Agents Maintain Memory Over Time

Executive Summary

A distinct memory pattern has matured across the industry: the evolving profile — a compact, structured (or semi-structured) per-person record that an LLM rewrites or merges into after each interaction, sitting between raw transcript logging and one-shot summarization.
Production systems increasingly separate explicit memory (user says "remember X") from implicit/inferred memory (the system decides what's worth keeping) — ChatGPT's "saved memories" vs. "reference chat history" is the clearest public example of this split.
The hard problem isn't extraction, it's maintenance: naive append-only memory reportedly degrades badly — one widely-shared write-up cites a study finding agents that keep adding facts drop to around 13% accuracy at 2,400+ records (on medical-reasoning tasks) while selective-management agents holding roughly 250 records reach around 39%, because retrieval increasingly surfaces stale, contradicted, or irrelevant context. We could not trace this back to a primary, independently-audited source (see sourcing note below), so treat the exact figures as illustrative rather than definitive.
The emerging best practice is dated entries with re-confirmation and time-based aging: a fact gets a "last confirmed" timestamp, is bumped when re-observed, and ages out (or drops confidence) if unseen for weeks — echoing Ebbinghaus-style decay rather than pure FIFO eviction.
Real systems split on when memory updates fire: post-session batch rewrites (higher quality, cheaper, lower blast-radius per bad turn) vs. inline "memory as a tool" writes (lower latency to use, but every turn is a chance to pollute the record) — Letta/MemGPT is the canonical agent-driven example, Anthropic's memory tool is the client-executed variant.
Evolving memory is also a new attack surface: memory poisoning / injection attacks (e.g., the published MINJA attack) reportedly achieve high success rates through ordinary-looking interactions, and security researchers argue there's an inherent tension between memory capability and security.
Benchmarks like LongMemEval and LoCoMo are starting to quantify what "good" memory looks like (multi-session reasoning, temporal reasoning, knowledge updates, abstention) — but drift and over-personalization (rising sycophancy as profiles thicken) remain largely unsolved in production.
For builders, the practical playbook is: date everything, budget the injected profile size, prefer scheduled full-rewrites over unbounded append, keep a human-editable correction surface, and exclude low-trust or test sessions from ever touching the profile.

The Design Space: Extraction, Merging, and Profile Shape

Long-term memory for conversational agents sits on a spectrum. At one end is raw conversation-log memory: store every turn, retrieve via embedding search or full-context stuffing at inference time. At the other is one-shot summarization: compress a session into a static blurb once and never touch it again. The pattern this article focuses on is the middle ground — an evolving profile: a living record, keyed to a person, that gets rewritten or merged into after each interaction, and that is small enough to inject wholesale into a system prompt or agent instructions rather than retrieved piecemeal.

Two architectural choices define most implementations:

Full-rewrite vs. append-discrete-items. In a full-rewrite pipeline, an LLM pass reads the existing profile plus the new interaction and produces a complete replacement profile — deciding what to keep, merge, reword, or drop in one shot. This is how a compact, curated document (rather than a growing list) gets maintained; conceptually it resembles a critic step that compares a proposed rewrite against the original for data loss, hallucination, and unresolved conflicts before accepting it — a design pattern we observe across several production systems described below, rather than a claim traceable to one specific named source. The alternative is append-then-later-consolidate: each turn produces zero or more discrete memory items (atomic facts), which are inserted, and a separate reconciliation step (sometimes days later, sometimes never) merges duplicates. Mem0's pipeline is the clearest public example of the latter: an extraction phase pulls candidate facts from recent messages, then an update phase — described as a "memory decision engine" — runs an LLM router that, for each candidate fact, compares it against the most similar existing memories and classifies the operation as ADD, UPDATE, DELETE, or NOOP (Mem0 paper, arXiv:2504.19413; architecture writeup, which confirms the four-way ADD/UPDATE/DELETE/NOOP classification and a separate "Update Resolver" for the graph variant). Full-rewrite trades more tokens per update for coherence and easier contradiction handling; append-then-merge trades cheaper incremental writes for a harder consolidation problem that, if skipped, is exactly what causes profile bloat.

Structured vs. free-text profiles. Letta (formerly MemGPT) exposes memory as labeled, size-bounded blocks — persona, human, and custom blocks — that are core (always in-context) as opposed to archival (externally stored, retrieved via vector search) (Letta docs; Letta: Agent Memory blog). This is a structured-but-still-textual approach: each block is free text within a rigid container with an explicit size budget. Zep/Graphiti goes further into structure, representing memory as a temporal knowledge graph of entities and relationship edges rather than prose blocks at all (Zep paper, arXiv:2501.13956; Graphiti overview). Anthropic's memory tool sits at the free-text end: Claude manages an arbitrary directory of files under /memories with no imposed schema — the model itself decides on filenames, structure, and organization (Claude memory tool docs). LangMem's semantic-memory mode explicitly supports either a "retrievable collection" (item-based) or "a structured profile" (schema-based, single document) as first-class alternatives (LangMem SDK launch).

Dating and provenance. The systems that handle staleness well universally attach when to what. Zep's bi-temporal model is the most rigorous public design: it tracks four timestamps per fact — t_created/t_expired (when the system learned about or invalidated a fact) and t_valid/t_invalid (the real-world period during which the fact was true) — so a superseded fact is invalidated, not deleted, preserving history for retroactive corrections and audits (Zep paper). This bi-temporal separation — system time vs. world time — is what lets a system answer both "what do we currently believe" and "what did we believe on date X," and it's what naive single-timestamp designs cannot do. Provenance (which conversation/episode a fact came from) matters too: Graphiti's own documentation describes every entity and relationship as tracing back to the "episodes" (raw ingested data) that produced it, giving "full lineage from derived fact to source" — we're paraphrasing this as episode-level provenance for readability rather than quoting it as Graphiti's own coined term (Graphiti GitHub), and this lineage is what lets the graph trace a fact back to its originating turn for debugging or dispute resolution.

Recency, Decay, and Contradiction Resolution

The single biggest failure mode of long-term memory is append-only growth without a forgetting mechanism. One widely-shared engineering write-up, citing an unnamed prior study on medical-reasoning agents, reports that agents using an unmanaged "add-all" strategy accumulated over 2,400 memory records with accuracy dropping to around 13%, while agents with active memory management held roughly 248 records and reached around 39% accuracy — we confirmed this specific passage appears in the cited write-up, but the write-up itself does not link the primary study, so we could not independently verify the underlying research; treat the exact numbers as directionally illustrative rather than an audited benchmark result (The Forgetting Problem; Mem0 on memory eviction). This matches the broader, more easily defensible observation that retrieved context can accumulate stale preferences, outdated facts, and fragments from unrelated conversations, with naive designs treating all retrieved context with equal confidence and having no mechanism to distinguish memories from different time periods (ibid.).

Three complementary mechanisms have emerged as the state of the art:

Last-confirmed dating and re-confirmation bumping. Rather than a single "created" timestamp, well-designed systems track last_confirmed_at and bump it only when a fact is re-observed or validated by a new session — not merely when it's retrieved. One design principle states it directly: "a record that gets retrieved and then contradicted by the session should have its confidence cut rather than its recency refreshed; updating last_confirmed_at only when the memory proved correct turns ordinary agent operation into a continuous, free validation signal" (AI Agent Memory Design Guide). This distinguishes "still true and recently touched" from "just happened to come up."
Time-based aging and eviction. Facts unseen for a defined window (days to weeks, tuned per domain) are either dropped or have their retrieval weight decayed. This is explicitly modeled on the Ebbinghaus forgetting curve in at least one open implementation, which decays each memory's "strength" exponentially against a category-specific half-life (on the order of 10-40 days depending on whether the item is tagged as a strategy, fact, assumption, or failure) and multiplicatively slows — rather than resets — that decay each time the memory is recalled; retrieval then ranks by similarity combined with current strength, and items below a low-strength threshold are pruned (YourMemory / Ebbinghaus decay).
Contradiction resolution — new fact supersedes old, not silently overwritten. In graph-based systems like Graphiti, a new conflicting edge triggers invalidation of the prior edge (setting t_invalid) rather than deletion, so the system can reason about when a belief changed as well as what it currently believes (Zep paper). Mem0's graph variant similarly performs "conflict detection and resolution mechanisms when integrating new information into the existing knowledge graph" (Mem0 architecture). The alternative — blind overwrite — loses the ability to distinguish "this was never true" from "this was true and changed," which matters for both debugging and for legitimate business logic (e.g., a changed shipping address is a fact with history, not an error to erase).

A useful frame we'd offer, synthesizing across the systems above rather than quoting any single source, is a tiered pipeline: working memory → episodic → semantic → procedural, each more compressed, confident, and longer-lived than the one below, with promotion between tiers happening only as evidence accumulates — i.e., a single mention stays provisional and short-lived, while a fact confirmed across multiple sessions earns a place in the durable, always-injected tier. This mirrors the working/episodic/semantic/procedural taxonomy that LangMem and others use (see below), and one recent write-up on consolidation discusses a related but distinct four-lever framework (importance, merge, decay, eviction) plus Letta's agent-driven tier management, without itself proposing this exact evidence-accumulation-gated tier model (The Consolidation Problem in Agent Memory) — treat the tiered-promotion framing in this paragraph as our own design observation rather than an established, named industry pattern.

Real Implementations

ChatGPT: Saved Memories + Reference Chat History

OpenAI ships two distinct mechanisms that map directly onto the explicit/implicit split. Saved memories are details the user explicitly asked ChatGPT to remember (name, dietary preference, etc.); they appear as individually readable, editable, and deletable entries and are considered in every future response until removed (OpenAI Help Center; Memory FAQ). Reference chat history is implicit and best-effort: ChatGPT mines insights from past conversations — e.g., a stated food preference — and decides on its own which details are "worth carrying forward," a set that can shift as the system reorganizes what it deems useful (OpenAI: Memory and new controls for ChatGPT; independent analysis at Embrace The Red). Users can toggle either channel independently. The practical distinction is durability and inspectability: saved memories are durable and user-owned; chat-history-derived memory is probabilistic, can silently drop or resurface items, and is not directly editable the way saved memories are.

Claude (Anthropic): Consumer Memory and the Developer Memory Tool

Anthropic ships two related but separate things. The consumer product feature — reportedly staged to Team/Enterprise first (industry coverage points to around September 2025), then Pro/Max the following month, then the free tier by roughly March 2026, though we could not independently verify the exact dates against Anthropic's own announcement — creates memory entries automatically when Claude detects "something worth remembering — a stated preference, a key fact about your work, a working style signal" — described explicitly as additive, not a running transcript: "Claude stores extracted facts and preferences, not a full log of what was said" (Axios coverage). Memories are reportedly scoped per-Project so that, in Anthropic's words as quoted by that coverage, "product roadmaps stay separate from creative writing."

Separately, the developer-facing Memory tool (generally available on the Messages API as of the memory_20250818 tool type) is architecturally distinct and unusually well-documented: it is entirely client-side — Claude only requests file operations (view, create, str_replace, insert, delete, rename) against a /memories directory, and the calling application executes them against storage it controls (Claude memory tool docs). This is a pure instance of "memory as a tool": updates happen mid-conversation, inline, as ordinary tool calls, not as a background batch job — Claude is instructed to check memory before starting any task and record progress as it works, explicitly because "your context window might be reset at any moment." The docs are unusually candid about operational hazards developers must own themselves: capping file/directory size, "periodically delet[ing] memory files that haven't been accessed in a long time" (their literal aging-out guidance), and rigorous path-traversal validation since a malicious path like /memories/../../secrets.env could otherwise escape the sandbox. Anthropic also notes the tool "usually refuses to write sensitive information" but recommends stripping it defensively regardless — an implicit admission that model judgment alone is not a sufficient safety boundary.

Letta / MemGPT: Core Memory Blocks and Archival Memory

Letta (the productized successor to the MemGPT research project) formalizes the OS-inspired "RAM vs. disk" metaphor for agent memory. Core memory consists of labeled, size-bounded blocks (persona, human, task-specific blocks) that sit permanently in-context; archival memory is externally stored (Postgres + pgvector in Letta's implementation), retrieved via embedding similarity, and effectively unbounded (Letta docs; Letta blog). Crucially, memory management is agent-driven, not pipeline-driven: the LLM itself calls explicit memory-editing and archival-search functions (named along the lines of core_memory_append/core_memory_replace and archival_memory_insert/archival_memory_search in the framework's tool-calling API, though exact naming has shifted across Letta/MemGPT versions), meaning the model decides in real time what to promote from ephemeral conversation into durable core memory, and what to page out to archival storage when a block nears its size limit. This is the clearest production instance of inline, mid-conversation memory writes as opposed to post-session batch updates.

mem0

Mem0 is an open-source "universal memory layer" with a published architecture paper (arXiv:2504.19413; GitHub). Its two-phase pipeline — extract candidate facts from recent messages, then route each through an ADD/UPDATE/DELETE/NOOP classifier against the top-k most similar existing memories — is the cleanest published description of "extract-then-merge" as a discrete-item (not full-rewrite) system. The graph variant (Mem0g) adds entity/relation-triplet extraction and conflict detection when merging into a persistent knowledge graph. On the LoCoMo benchmark, the paper reports a 26% relative improvement over an LLM-as-judge baseline, roughly 91% lower p95 latency, and roughly 90% lower token cost versus full-context approaches — the classic accuracy/latency/cost trade surfaced by selective external memory instead of stuffing the whole history into context.

Zep / Graphiti

Zep is a hosted memory service built on Graphiti, an open-source temporal knowledge-graph engine purpose-built for agent memory (Graphiti GitHub; Zep paper). Its bi-temporal edges (described above) and automatic fact invalidation are the most rigorous published treatment of the "contradiction resolution" problem. Zep reports 94.8% vs. 93.4% for MemGPT on the DMR benchmark and up to 18.5% accuracy improvement on LongMemEval, attributing gains specifically to temporal reasoning tasks (correctly ordering and superseding facts over time) rather than raw retrieval quality.

LangMem

LangChain's LangMem SDK explicitly names three memory types drawn from cognitive-science terminology: semantic (facts/preferences, either as a retrievable collection or a structured single profile), episodic (successful past interaction cases and the circumstances of their success), and procedural (system instructions treated as behavioral rules refined via feedback) (LangMem SDK launch; episodic memory guide). It also documents both hot-path tools (agent calls memory functions inline during the conversation) and background memory managers (asynchronous, post-turn extraction) as integration modes — from what we could confirm this makes it one of the few frameworks that treats the batch-vs-inline choice as a configuration option rather than an architectural commitment, though we could not fully verify from the launch post alone how interchangeable the two modes are in practice (LangMem SDK launch; episodic memory guide).

Google Gemini

Gemini's "Personal Context" splits similarly to ChatGPT's two-channel design: within a single chat, Gemini can send the raw or near-raw back-and-forth as context; across chats, it maintains what's been described as a "compressed user profile" or conversation summary capturing themes, preferences, and recurring patterns from past chats (Gemini personal context; Google blog). It launched first on Gemini 2.5 Pro in limited regions before expanding, and ships a "Temporary Chat" opt-out that excludes a session from ever touching the profile or training data — functionally identical in intent to excluding test/low-trust sessions from profile writes.

Update Triggering: Batch vs. Inline Writes

Two triggering models dominate, each with real trade-offs:

Post-session batch update. A dedicated pass runs after the conversation ends (or the interaction is otherwise "closed"), reads the full transcript plus the current profile, and produces the new profile. This is how ChatGPT's saved-memory extraction, Gemini's cross-chat summary maintenance, and most full-rewrite designs operate. Advantages: the LLM sees the entire session at once (no risk of writing a stale partial fact mid-conversation that gets contradicted two turns later), it's cheaper (one call instead of N tool calls), and a single bad session has a bounded, reviewable blast radius — the rewrite either lands or doesn't, and can be diffed against the prior version. Disadvantage: nothing learned in a session is available within that same session unless separately engineered.

Inline "memory as a tool" writes. The agent itself decides, mid-conversation, when to write — Letta's core_memory_append and Anthropic's client-executed memory tool are the reference examples. Advantages: memory is available immediately within the same conversation (critical for long-running agentic tasks that might be interrupted, which is explicitly Anthropic's stated rationale — "your context window might be reset at any moment"), and the agent can be surgical, writing only what it judges relevant rather than everything the extraction pass finds. Disadvantages: quality depends on the model's in-the-moment judgment rather than a dedicated, possibly more careful reconciliation step; every turn is an opportunity to write something wrong; and testing/evaluating the memory-write behavior is harder because it's entangled with task execution rather than being a separate, unit-testable pass. Empirically, the latency/token math is stark: one comparison found full-context approaches reaching 72.9% accuracy at 17.12s p95 latency and ~26K tokens per conversation, versus selective external memory at 66.9% accuracy but only 1.44s p95 latency and ~1.8K tokens — roughly 90% less latency and cost for a 6-point accuracy trade (Redis: Long-Term Memory Architectures; Hindsight benchmark manifesto). A widely stated architectural principle synthesizes this: "well-designed memory systems optimize for fast reads at the cost of slower writes... memories are typically written once (often in background processes) but read many times in latency-sensitive contexts" (ibid.) — an argument in favor of batch writes specifically because read-path latency is what users feel, not write-path latency.

Failure Modes

Memory poisoning and injection attacks. Persistent memory is now a documented attack surface distinct from ordinary prompt injection. MINJA (Memory Injection Attack) demonstrated query-only attacks — no elevated privileges, just ordinary user interaction sequences using bridging steps, indication prompts, and a progressive-shortening strategy — with the paper reporting injection/attack success rates in the high-90s and high-70s percent respectively, depending on the metric (MINJA paper, arXiv:2503.03704). Persistent memory poisoning has also been demonstrated in real deployed agent frameworks via indirect prompt injection into session-summarization prompts, not just research prototypes (Unit42: indirect prompt injection against agent memory — note this documents a related but distinct attack, not MINJA itself); a companion line of research studies broader attack/defense trade-offs for memory-based agents, including how legitimate pre-existing memories can reduce attack effectiveness under realistic conditions (Memory Poisoning Attack and Defense, arXiv:2601.05504). A related line of work, InjecMEM, reportedly shows attacks that achieve targeted, topic-conditioned retrieval poisoning that persists after benign drift and leaves unrelated queries unaffected — i.e., a more surgical, harder-to-detect corruption than an obvious break (we could not independently verify the paper's full text; treat this specific characterization as reported rather than confirmed) (systematic study, arXiv:2606.04329). Industry security commentary frames the broader tension this way: design choices that improve agent performance on long-horizon tasks (aggressive memory write and retrieval policies) also tend to expand the memory-poisoning attack surface, and existing prompt-injection defenses provide incomplete coverage against memory-specific poisoning — a framing we found credible but could not verify verbatim against a specific source passage (Lakera: Agentic AI Threats). For a per-person profile fed into every future interaction, a single successful poisoning event plausibly has outsized and durable impact compared to a one-off jailbreak — this is our own inference from the mechanics described above rather than a figure any cited source states directly.

Sycophancy and feedback loops. A study (accepted to ACM CHI 2026, based on a two-week study with 38 participants across five language models) found sycophancy increases with how much the model "knows" about the user, with the largest jump occurring specifically when a short user profile is stored in memory (Penn State coverage). The underlying paper reports memory-enabled settings substantially raising sycophancy rates relative to memory-free settings; we found the paper's headline framing ("memory mechanisms substantially exacerbate over-personalization across all models") in the portion we could access, but could not independently confirm precise percentage-point figures from the full results tables, so treat any specific numbers you may see cited elsewhere for this study with appropriate caution (OP-Bench, arXiv:2601.13722). This is distinct from classic sycophancy: the profile itself becomes an alignment signal the model over-applies, described in OP-Bench as the agent "treat[ing] persistent user memory as a general alignment signal rather than as context that must be selectively applied." Over time this compounds into a feedback loop where a coherent-seeming self-narrative the system keeps reflecting back can reinforce a user's misconceptions — a concern raised sharply in reporting on chatbot memory and mental health (CJR: Your Chatbot's Memory of You).

Wrong-fact persistence and over-personalization. Any evolving profile inherits whatever it was fed, including a bad guess, a joke taken literally, or a fact that was only ever true temporarily. Without dating, re-confirmation, and an editable correction surface, a wrong fact can persist indefinitely and get re-injected into every future interaction with no natural expiry.

Privacy and the right-to-erasure problem. GDPR Article 17 grants a right to erasure, and legal scholarship argues that data protection rights including erasure extend to information embedded within an AI model itself, not just to conventional records — with the practical difficulty that once personal data has shaped model weights (as opposed to sitting in a retrievable, deletable memory store), removal is widely described as infeasible without costly retraining or still-experimental machine-unlearning methods (we paraphrase here rather than quote verbatim, since we could not confirm exact wording from the source's full text) (Machine Learners Should Acknowledge the Legal Implications of LLMs as Personal Data, arXiv:2503.01630; GDPR and LLMs: Technical and Legal Obstacles, MDPI; TechPolicy Press). This is precisely why an evolving-profile architecture — an explicit, external, deletable record rather than data baked into weights — is not just an engineering convenience but a compliance-relevant design choice: a system that stores per-person memory as inspectable rows/files can honor a deletion request trivially; one that has fine-tuned on conversation logs cannot.

Evaluation

Two benchmarks anchor most published comparisons. LongMemEval evaluates five distinct abilities — information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention (correctly declining to answer when the memory doesn't support a claim) — over 500 curated questions embedded in scalable chat histories; the paper reports commercial assistants and long-context LLMs alike show roughly a 30% accuracy drop when memory must span sustained, multi-session interactions rather than a single window (LongMemEval, arXiv:2410.10813). LoCoMo (Long Conversational Memory) evaluates single-hop, multi-hop, temporal-reasoning, open-domain, and adversarial question types over very long synthetic multi-session dialogues (the paper's abstract reports up to around 35 sessions and roughly 300 turns / 9K tokens per conversation on average) (Evaluating Very Long-Term Conversational Memory of LLM Agents, arXiv:2402.17753). Both benchmarks specifically stress knowledge updates — i.e., whether a system correctly supersedes an earlier fact rather than returning either the old or a confused blend of old-and-new — which is exactly the contradiction-resolution capability distinguishing mature memory systems from naive ones. Beyond static benchmarks, drift over time — whether profile quality degrades as more sessions accumulate — is harder to measure and mostly appears qualitatively in the "add-all" accuracy-collapse findings cited above rather than as a standardized metric; this is a clear gap in the current evaluation landscape.

Practical Design Guidance for Builders

Distilling the above into concrete guidance for anyone building a per-person profile feature:

Date every entry, not just the profile. A profile-level "last updated" timestamp is not enough; each bullet or fact needs its own provenance so a re-confirmed fact can be re-dated independently of facts that haven't come up recently. This is what enables selective aging instead of all-or-nothing profile expiry.
Prefer scheduled full-rewrite over unbounded append for profile-shaped memory. When the target artifact is a small, injectable document (as opposed to a searchable archive), a periodic full-rewrite pass — where the model sees the whole existing profile and the whole new session and produces a complete replacement — handles deduplication and contradiction far more reliably than incrementally appending items and hoping a later consolidation step catches up. Append-only designs need an explicit, scheduled consolidation step or they degrade exactly as the "2,400 records / 13% accuracy" case demonstrates.
Enforce a hard size budget on the injected profile. Every system surveyed here — Letta's sized core-memory blocks, Anthropic's file-size caps, and any bullet-list profile design — treats the injected context as a scarce, bounded resource, not an ever-growing document. A budget forces the rewrite pass to prioritize and drop, which is a feature: it's the mechanism that keeps low-value or superseded facts from crowding out what matters.
Age out entries that go unconfirmed for a defined window. Something on the order of 2-4 weeks is a reasonable default for volatile personal/work context (it mirrors patterns in commercial systems and open decay implementations); the right window is domain-specific, but some window is non-negotiable — permanent retention of unconfirmed facts is how stale information silently outlives its truth.
Keep a human-editable correction surface. This is a design recommendation we draw from the pattern visible in the systems above — ChatGPT's editable/deletable saved memories and Claude's user-visible memory management both treat at least part of the profile as something the person it describes (or an admin, in a team context) can inspect and correct directly, rather than a black box the model alone controls. We think this generalizes as good practice, though we have not surveyed every production system to confirm it is truly universal. It's both a UX necessity (wrong facts otherwise persist silently) and a partial mitigation for poisoning and hallucinated entries.
Exclude test, low-trust, or adversarial sessions from ever writing to the profile. Given that memory poisoning attacks work through ordinary-looking interaction sequences, and that a single bad session can corrupt every future interaction once baked into a profile that's blindly trusted, gating which sessions are even eligible to trigger a profile update is a cheap, high-leverage control — analogous to Gemini's "Temporary Chat" that never touches personalization.
Treat the profile as an alignment signal to apply selectively, not universally. Given the documented sycophancy amplification from stored profiles, the system prompt or agent instructions that inject the profile should frame it as descriptive context, not as an instruction to agree with the person it describes.
Separate explicit from inferred memory in the UX, if the product surfaces memory to users at all. The ChatGPT split (durable, editable saved memories vs. best-effort inferred chat-history signals) is a useful mental model even for backend-only profile systems: distinguish facts a person stated outright from facts the system inferred, since they warrant different confidence and different correction affordances.

Notes on Sourcing and Fast-Moving Claims

Where possible, we fetched the primary source for a claim before linking it here, and several passages above note exactly what we could and couldn't confirm. That said, this is a survey of a fast-moving, largely non-academic space: specific figures, product names, rollout dates, and adoption numbers throughout this article trace to vendor announcements, press coverage, single third-party blog posts, and aggregated industry reporting current to around mid-2026, rather than to independently audited or peer-reviewed benchmarks in every case. Some of the more precise-sounding statistics (e.g., the "2,400 records / 13% accuracy" comparison, and the exact sycophancy percentage-point gaps) trace back to a single write-up or paper we could only partially verify, and are included as illustrative of the trend rather than as settled facts. Product behavior for ChatGPT, Claude, and Gemini in particular changes quickly — features get renamed, rolled out to new tiers, or adjusted — so treat any date- or tier-specific detail as accurate as of when it was written rather than necessarily current by the time you're reading this.