Somewhere in the last two years, the phrase "an AI that knows you" quietly moved from science fiction into product marketing. Assistants now recall your name, your job, your last several conversations, and sometimes your coffee order. It's tempting to conclude that the problem of a personal AI is basically solved and what remains is scale and polish.
This article argues that conclusion is premature, and tries to explain why in a way that can actually be tested rather than merely asserted.
The starting distinction is simple to state and harder to honor in practice: an AI having information about a person is not the same as an AI knowing that person. A spreadsheet has information about you. A records database has a great deal of information about you. Neither of these "knows" you in any sense that would make the term meaningful, and most people would object if someone described either that way. Something more than storage is being claimed when we say a system knows a person, and this article tries to work out what that something is, whether current AI architectures have it, and whether it is even fully specifiable with today's tools.
This piece did not set out looking for a satisfying answer. It set out looking for the actual requirements, reasoning through a prototype architecture against them, and trying to report honestly on what held up and what didn't.
The question underneath the question
"Knows you" is doing a lot of unexamined work. In ordinary usage, we apply it to a spouse, a longtime doctor, a close friend, and sometimes a good barista — cases that differ enormously in depth, but which share some family resemblance: continuity over time, some track record of being right about you, an understanding of what's appropriate to bring up and when, and a willingness to revise their picture of you when you change.
An AI product claiming to know a user is usually claiming something much thinner: that it can retrieve facts you or your usage pattern have produced. That's a real capability, but it is closer to what a well-organized filing system does than to what a person who knows you does. The question this article tries to answer was not "does the AI have facts about me" but: what observable properties would a system need before "familiarity" is a defensible description of what's happening, rather than an anthropomorphic gloss on a lookup table?
This is treated here as an engineering and epistemology question, not a consciousness question. Whether a system that meets these requirements would be conscious, or would "really" care about the user, is a separate and much harder question that this article deliberately sets aside.
It's worth being specific about what existing approaches actually contribute, because each of them is a genuine advance and none of them, alone, demonstrates familiarity.
Conversation history and long-context windows. Modern models can ingest enormous amounts of prior conversation directly. But having more room in the context window is not the same as maintaining continuity. The position of relevant information within a long input turns out to matter a great deal for how reliably a model actually uses it: information placed near the beginning or end of a long context tends to be used far more reliably than information buried in the middle, and this effect persists even in systems specifically built for long contexts. A large context window is a bigger desk, not a filing system, and it does not by itself provide provenance, revision, or a way to distinguish a fact from a passing mood.
Vector databases and semantic retrieval. Retrieval-augmented approaches let a system pull in facts it wasn't originally trained on, which is essential for personalization. But retrieval introduces its own failure modes. When retrieved material conflicts with what a model already holds from training, or when several retrieved passages disagree with one another, current systems frequently blend or mis-resolve the conflict rather than flagging it clearly, and low-quality or contradictory retrieved material can degrade accuracy rather than improve it. A retrieval system will happily return the most semantically similar memory to a query whether or not that memory is still true, still relevant, or was ever meant to be treated as a durable fact rather than a passing remark.
Structured user profiles and knowledge graphs. These impose discipline that free-text memory logs lack — a profile field for "employer" is at least explicit that it is tracking a single evolving value. But most profile systems don't natively encode when a fact was true or how confident the system should be in it. An ordinary knowledge graph tends to store relationships as though they are permanently true, which is precisely the assumption that breaks down for a person, who changes jobs, relationships, and preferences over the course of any long relationship with an assistant. Newer agent-memory designs have begun attaching explicit time intervals to stored facts — recording not just what is believed but when it became true and when it stopped being true — which is a meaningful improvement, but this temporal layer is still far from standard across personal-AI systems.
Fine-tuning and continual learning. Adjusting a model's weights on a person's data seems like the most literal form of "learning" someone. But training a model sequentially on new information carries a persistent, well-documented risk: it can degrade or lose previously learned knowledge, because the same weight adjustments that reduce error on new material can significantly disrupt what was reliably known before. This is one reason almost no deployed personal-AI system fine-tunes a model per user in real time; the tooling to do that safely, without quietly eroding other knowledge, remains an active area of work rather than a settled engineering practice.
Preference learning. Systems increasingly try to infer what a user likes from behavior, not just explicit statements. But much of the underlying alignment methodology assumes something close to a single, stable, average user, and even more personalized approaches struggle when a person's preferences are inconsistent, evolving, or context-dependent — which is the normal condition of being a person, not an edge case.
Agent memory frameworks. This is the most direct predecessor to a genuinely personal AI, and it is worth describing in some detail, because the field has converged on many of the same requirements this article is trying to state explicitly. One influential design pattern treats a model's limited context window the way an operating system treats working memory, moving information between a small active set and a much larger archive so that relevant material can be paged back in when needed, extending effective memory well beyond what fits in a single prompt. A separate and earlier design gave simulated agents a continuously growing memory stream paired with a periodic "reflection" process that synthesizes raw observations into higher-level generalizations — one of the more careful attempts to formalize the difference between a raw record and a durable belief. More recent designs have represented agent memory as an explicitly time-aware knowledge graph, and early results suggest that adding a temporal dimension to memory measurably improves a system's ability to answer questions that depend on when something was true, not just whether it was ever stated.
None of these architectures, individually or combined, demonstrates that a system knows a person in the fuller sense this article is investigating. They demonstrate that a system can store, retrieve, and sometimes reconcile facts about a person. Whether the system knows where those facts came from, how confident it should be in them, whether they are still true, and whether it is allowed to say them out loud in the current context are separate questions that these architectures address unevenly or not at all.
Twelve properties, examined one at a time
This article tries to break "knows you" into properties specific enough to test. Not all of them survived contact with the surrounding technical landscape in their original form; a few had to be narrowed, and one turned out to rest on a genuinely unresolved theoretical debate rather than an engineering gap.
1. Personal continuity
The minimum bar: the system's behavior in session ten should be shaped by what happened in sessions one through nine, without the user re-explaining themselves each time. This is close to solved as an engineering matter — several published agent-memory designs provide working mechanisms for it — but continuity of retrieval is not the same as continuity of understanding, which is where the next several properties come in.
2. Provenance
A system that knows something about you should, in principle, be able to answer "how do you know that?" The candidate sources aren't interchangeable: something you stated outright, something inferred from your behavior, something observed by a tool, something pulled from an external record, or something a third party said about you all carry different evidentiary weight and different consent implications. This is a well-established concept in fields concerned with data lineage more broadly, where standardized ways of representing who or what produced a piece of information, and through what process, have existed for some time. Personal-AI memory systems rarely apply this kind of rigor with any consistency — a fact inferred from tone of voice and a fact the user typed in plain language often end up stored identically.
3. Epistemic status
Related to provenance but distinct from it: even with a known source, a claim can be a confirmed statement, a hypothesis, an observation awaiting confirmation, an inferred preference, or a transient state. Whether a system can recognize what it knows versus doesn't know, express calibrated confidence, and selectively decline to answer has been explored elsewhere, but mostly on general factual question-answering, not on tagging the epistemic status of ongoing claims about a specific individual. Extending that work to personal memory, rather than trivia-style benchmarks, remains an open gap.
4. Revision
People change jobs, relationships, opinions, and health. A useful personal AI needs a defensible answer to "the user told me one thing in the spring and the opposite in the fall — what do I do with that?" Formal treatments of belief change, developed originally in logic and philosophy, already distinguish several distinct operations here: simply adding new information, removing information, and revising a belief set by adding new information while discarding just enough of the old to remain consistent. Almost no consumer memory system implements anything this disciplined; most either silently overwrite the old fact, silently keep both as if simultaneously true, or leave the contradiction for the model to stumble over at generation time. A system that explicitly marks an old claim as superseded rather than deleted — preserving the history of the change instead of just its outcome — is closer to what genuine revision requires.
5. Temporal understanding
Closely tied to revision: "is this true" is often less important than "when was this true." A person who liked jazz in college and hasn't listened to it in a decade wasn't lying then and isn't lying now; the claim needs a time interval attached to it, not just a truth value. This is one of the more tractable parts of the problem — the data structures for representing it exist and are gradually being adopted in memory-focused agent designs. The harder issue is deciding when a claim should be considered expired without an explicit correction, which is discussed further below.
6. Preference interpretation
A user asking for shorter answers once is not the same as a user who globally prefers brevity forever. Overgeneralizing from a single data point is a specific and well-documented failure mode, and it appears to be made worse by a training dynamic that pulls in exactly the wrong direction. Models trained heavily from human feedback show a recurring tendency toward sycophancy — aligning outputs with what a user seems to want to hear rather than with what is accurate or well-calibrated — and this tendency appears to become more pronounced after the very training stage meant to make models more helpful, because human raters tend to systematically favor agreeable responses. A personal AI shaped by this kind of pressure risks converting single interactions into permanent personality traits faster than it converts them into calibrated, revisable preferences, because agreement often reads as success during training. Distinguishing "learned your preference" from "learned to flatter you" turns out to be one of the harder problems this article ran into, not a minor implementation detail.
7. Behavioral continuity
A user may expect stable interaction patterns — a certain tone, a certain level of directness — that persist across sessions while still being able to evolve deliberately. This needs to be kept conceptually separate from factual memory: knowing you prefer terse answers is a behavioral directive, not a fact about the world, and conflating the two categories is part of why systems overgeneralize preferences into permanent facts in the first place.
8. Relationship context
Knowing a person also implicitly involves understanding what kind of relationship is in play — a work assistant is not a diary, and neither is a general-purpose chatbot a therapist, even when it is used that way. Treating this carefully means resisting the pull toward describing an AI as having a relationship in the way two people do. The more defensible framing is behavioral rather than experiential: a system can maintain relationship-appropriate patterns of interaction without any claim being made about whether it has an inner stance toward the user. This article does not take a position on whether that distinction is stable in the long run, only that collapsing it prematurely is a mistake.
9. Audience awareness
This is where an existing conceptual framework is most directly useful, because the underlying problem has a name and a structure attached to it already. Appropriateness of information flow depends not on secrecy in the abstract, but on whether a disclosure matches the norms of the specific context it originated in — who the information concerns, who is sending it, who is receiving it, what kind of information it is, and under what expectation it was shared. That framing maps closely onto the audience-awareness problem for personal AI: a fact disclosed privately to an assistant does not carry an automatic license to be surfaced in a public-facing response, a group summary, or a livestream, even though the system technically "knows" it and retrieval alone would happily return it. Evaluations built specifically to test whether language models recognize which disclosures are appropriate in a given social context have found that models frequently fail to make this distinction reliably on their own — which is why audience boundaries arguably need to be built into retrieval and generation, rather than added afterward as a final content filter.
10. Consent and control
For a memory to be trustworthy rather than merely present, users arguably need the ability to inspect what is stored, correct it, revoke it, and understand why something was remembered in the first place. This is more a design and governance requirement than an unsolved technical problem — the harder question, discussed below, is whether such controls can be made genuinely usable without becoming either a UI users ignore or a system so restrictive it undermines the continuity it is meant to serve.
11. Uncertainty and abstention
A system that states a shaky guess about you with full confidence is worse than one that says "I'm not sure, but I think..." or simply asks. Selective prediction is the general design pattern addressing this trade-off: a model can decline to answer when its own confidence is unreliable, with the goal not just of improving average accuracy by filtering out hard cases, but of offering some genuine reliability guarantee for the answers it does give. Personal-memory systems rarely implement anything like this in practice; weakly supported inferences about a user are usually surfaced with the same confident tone as directly stated facts, because most current architectures don't carry a confidence score from storage through to generation.
12. Agency boundaries
Knowing something about a person is not the same as being authorized to act on it. A system that has learned your travel dates should not, on that basis alone, be entitled to book a flight, message a contact, or post publicly on your behalf. The useful chain here is: knowledge, then reasoning, then a proposed action, then authorization, then the external action itself — and the last step needs to remain a distinct, gated event rather than an automatic consequence of the first three.
An experimental architecture
To move from a list of properties to something testable, this article sketches an experimental persistent personal-agent architecture on paper. It has not been built as a running product and was not evaluated with logged, measured outcomes; what follows is a conceptual design, and the scenarios in the next section are thought experiments worked through against its rules, not results from an operating system. It is also not presented as the only viable design — it deliberately borrows components already explored in the field rather than inventing new primitives for their own sake.
The core structure separates claims from the record of how those claims arrived and changed. Each claim about the user would carry: a provenance tag (stated, inferred, observed, external, retrieved, or third-party), an epistemic-status tag (confirmed, hypothesis, inference, or temporary state), a timestamp and, where relevant, a validity interval, a rough confidence indicator, and — critically — a pointer to whatever claim it supersedes, if any, rather than simply overwriting it. This is close in spirit to time-aware agent-memory designs and to formal accounts of belief revision that favor recording history over blind overwrite.
Separately, the architecture would keep a short-lived buffer of raw observations that is not automatically promoted into the durable claim store. Promotion would require either an explicit signal from the user, repeated corroboration over time, or a deliberate reflection step, echoing the reflection mechanisms used in some agent-memory designs. This buffer-and-store split is the architecture's answer to the casual-statement problem described in the next section.
Retrieval would be gated by a disclosure-permission tag attached to each claim, marking the contexts in which it can appropriately surface — private, a named group, professional, or public. Retrieval alone would not be sufficient to permit disclosure; the retrieval step and the disclosure-permission check are kept as two separable gates rather than one.
Finally, any action beyond generating text — sending a message, posting content, modifying an external system — would pass through an explicit authorization gate that is never satisfied merely by the system possessing relevant knowledge.
This is an experimental design meant to be argued with, not a finished product, and several of its components — particularly automatic promotion from buffer to durable store, and automatic confidence scoring — remain more aspirational than solved.
Hypothetical tests against the design
The following are not empirical experiments. Nothing here was run against real users or logged for measurable outcomes. These are structured thought experiments: specific scenarios reasoned through against the architecture's stated rules, used to check whether the design's logic produces a defensible answer, and — just as importantly — to expose where it doesn't. Where a scenario reveals a gap, that gap is treated as an open problem, not glossed over as if the architecture already handles it.
Casual statement vs. durable memory. "I've been drinking a lot of coffee lately" should not become "user permanently loves coffee." Under the architecture's rules, this would sit in the short-lived observation buffer, tagged as a temporary state with no promotion trigger, unless the user repeats the pattern over time or states a stable preference explicitly. What the scenario shows: the buffer-and-store separation is necessary to avoid this failure mode, but deciding the promotion threshold — how many repetitions, over what time window, should count as "stable" — has no principled answer available. It would be a design parameter chosen by judgment, not something derived from a solved question.
Revision. A previously stored preference is explicitly contradicted months later. Under the architecture's rules, the old claim would be marked superseded rather than deleted, preserving a timeline rather than a single current-state snapshot. What the scenario shows: this is achievable with existing time-aware and revision-inspired design patterns; the open problem is not the mechanism but detecting when a user has changed without an explicit correction — the far more common real-world case, discussed below.
Contradiction from two sources. The system receives conflicting claims, say, from the user directly and from an inferred behavioral pattern. Provenance weighting would resolve the easy cases — a direct user statement generally outranks an inference — but does not resolve cases where two direct statements conflict with each other. What the scenario shows: provenance is necessary but not sufficient for contradiction resolution; some conflicts would need to be surfaced to the user rather than silently arbitrated, which argues against any design that always produces a single confident merged answer.
Observation vs. confirmation. A tool observes something about the user — through a screen, an image, or a similar channel. Should that become canonical memory automatically? What the scenario shows: no. Treating observation as equivalent to a user-confirmed fact would collapse the provenance distinction the rest of the architecture depends on; observations should enter as low-confidence, low-disclosure-permission claims by default, promotable only with corroboration or explicit confirmation.
Private vs. public. Information given privately is later relevant to a public-facing generation task, such as a livestream response or a public post. What the scenario shows: if disclosure permission isn't a first-class, per-claim property checked at retrieval time, the natural failure mode is that retrieval quietly surfaces the private fact in a public context simply because it was the most semantically relevant memory available. This supports treating audience boundaries as part of retrieval itself rather than as a downstream filter — a filter catches obvious cases but is a fragile last line of defense.
Uncertain recall. The system retrieves a weakly supported claim. What the scenario shows: confidence needs to affect language, not just an internal score — the system should qualify, ask, or abstain, following the logic of selective prediction — but this is a design requirement the architecture states rather than something already proven to work; no personal-memory system reviewed for this article does this by default, and most surface retrieved content with a uniform, confident tone regardless of the underlying confidence, largely because confidence isn't computed for personal claims to begin with.
Preference overgeneralization. A one-time stylistic request, such as "be more concise," is at risk of becoming a permanent global directive. What the scenario shows: this risk appears to be amplified, not just permitted, by training dynamics that reward agreeable-seeming behavior — a system optimized to please is structurally biased toward treating single positive-seeming interactions as durable signal. Architectural fixes such as decay and explicit confirmation before permanence would help, but they don't address the underlying training incentive, which sits outside the architecture entirely.
Authorized action. The system has enough information to send a public reply on the user's behalf. What the scenario shows: knowledge sufficiency and action authorization need to be kept as genuinely separate gates in the design, not merely separate steps in a single automatic pipeline — otherwise "the system knows enough" quietly becomes "the system is entitled to act," which is a different claim entirely.
What these thought experiments suggest
Taken together, these scenarios point toward a small set of qualitative conclusions about the architecture's design, not measured results — nothing here was benchmarked, and the conclusions below describe what the reasoning exposed, not what was observed in operation.
Persistent retrieval is necessary but not sufficient; it answers "can the system find this again" without answering "should it," "is it still true," or "how sure should it be." Provenance matters concretely, not just conceptually, because different sources genuinely warrant different trust and different disclosure treatment — a claim inferred from behavior should not silently outrank a claim the user stated directly, and current systems often don't preserve enough information to even make that comparison. Remembering less can be safer than remembering more, particularly for observational or inferred claims, because low-confidence content surfaced with high-confidence language is a worse outcome than the same content simply not being retrieved. Audience boundaries have to live inside retrieval, not only in an output filter, or the private-public distinction breaks under the first plausible cross-context scenario. And knowledge and authority need to be architecturally distinct, because collapsing them is the difference between an assistant that recalls something useful and an assistant that acts on your behalf without a clear moment of authorization.
None of these conclusions are surprising in isolation. What this exercise clarified is how much of "knowing a user" depends on getting these boundaries right simultaneously, and how easy it would be for a system that gets nine of them right to fail on the tenth in a way that undermines trust in the whole.
What remains unsolved
This is the most important section, and honesty here matters more than a tidy conclusion.
Inferring stable preferences from sparse behavioral signal is genuinely unresolved. Personalized preference modeling has made real progress representing individual users more precisely rather than assuming one average user, but this depends on enough interaction data to be meaningful, and most personal-AI relationships don't generate that much signal quickly. The gap between "enough data to infer something real" and "enough data that the system starts overfitting to noise" doesn't have a general solution.
Detecting when a user has changed without an explicit correction looks, on the evidence gathered here, like one of the two or three hardest open problems in this space. Revision mechanisms work reasonably well when the user says "actually, I don't like that anymore." They have essentially no mechanism for detecting the far more common case where a person's preferences drift silently and are never explicitly restated. This is not primarily a data-structure problem; it's an inference problem with no clear ground truth to check against.
Quantifying the trustworthiness of a stored personal memory has partial engineering solutions, such as provenance-based weighting, but no agreed evaluation methodology. Calibration and selective-prediction work is comparatively mature for factual question-answering benchmarks; it is largely untested for claims about a specific individual, where there is rarely an external ground truth to calibrate against in the first place.
Evaluating whether an AI's personal model is actually accurate is an open problem with a structural obstacle: the most direct way to check would be to ask the user, but users are not perfectly reliable narrators of their own preferences either, and self-report introduces its own bias.
Preventing memory poisoning — a malicious or careless third party planting false claims that get treated as durable memory — is a real and current risk, not a hypothetical one. An attacker does not need any access to a user's own conversation with a system; only the ability to place content somewhere the system will later retrieve, such as a web page, document, or message, can be enough to influence the system's behavior. Personal-memory stores are a plausible, high-value target for exactly this kind of contamination, since a poisoned "fact" about a user could persist and quietly compound across sessions in a way a single poisoned response cannot.
Safe continual personalization runs directly into the forgetting problem described earlier; there is active mitigation work, but no consensus method that lets a model update on individual-user data over long periods without either losing other knowledge or requiring an architecture, such as the buffer-and-store separation described above, that avoids weight updates entirely and therefore isn't really continual learning in the strict sense.
Handling contradictory evidence has workable heuristics, such as provenance weighting and surfacing conflicts to the user, but no general solution when two equally credible sources genuinely disagree. Sometimes the correct answer is that both were true at different times, and detecting which case you're in without more context remains unresolved.
Representing highly contextual personal information — facts that are true in one relationship or setting and misleading if generalized outside it — is only partly addressed by disclosure-permission tagging. Tagging the context in which a claim is appropriate to share is more tractable than tagging the context that gives a claim its actual meaning, and the latter remains largely unaddressed.
Defining appropriate forgetting turns out to be philosophically harder than it looks. Techniques exist for removing the influence of specific data from a trained model in response to a deletion request, which gives some technical purchase on the problem. But these techniques mostly target discrete, well-defined removal requests, not the more fluid question of when an AI should let go of a claim about an ongoing relationship even without a formal request to do so — and reliably removing the influence of specific information from a large trained model, while leaving everything else intact, remains exceptionally difficult in general.
Handling shared memories involving multiple people — a fact one person disclosed about another, or a memory two users would describe differently — has essentially no established framework. It's adjacent to, but not solved by, the audience-awareness work above, because the problem isn't just who can hear a fact but whose fact it even is.
Evaluating relationship continuity as distinct from factual accuracy has no agreed metric. It's comparatively easy to measure whether a stored fact is correct; it's much harder to measure whether a pattern of interaction over time constitutes something a reasonable person would call continuity, rather than a series of disconnected, well-informed sessions.
Preventing correct information from being used in socially inappropriate ways goes beyond the audience-awareness problem into something closer to judgment — knowing a sensitive fact and knowing when, even within an authorized context, it is still the wrong moment to bring it up.
Distinguishing useful familiarity from manipulative personalization is not fully a technical problem. The sycophancy pattern already discussed suggests a real tension: the training pressures that make a system feel attentive and personally attuned are close cousins of the pressures that make it flatter and agree rather than tell the user something useful but unwelcome. There isn't yet a clean way to get one without some risk of the other.
Maintaining privacy when third-party infrastructure and model providers are involved is a structural, not merely implementational, problem. A persistent personal memory store is a concentrated, valuable target, and its risk surface includes database compromise, injected instructions hidden in retrieved content, tool misuse, cross-user leakage, unintended disclosure through generation, account compromise, exposure at the infrastructure level, ordinary logging, and dependence on systems outside any single organization's control. No architecture eliminates this risk category; the best a design can do is reduce blast radius and give users visibility and control, which is a mitigation, not a solution. This article makes no claim that any particular design solves privacy in an absolute sense, and readers should be skeptical of any product claim that it does.
Building strong user control without making the system unusably cumbersome is a genuine design tension rather than a solved trade-off. Systems that let users inspect, correct, and revoke every stored claim in granular detail tend to produce controls nobody uses; systems that simplify controls tend to hide exactly the decisions users would most want to see. This article doesn't have a resolution to offer here beyond naming the tension clearly.
Some of these are engineering problems with partial solutions already in hand, such as temporal representation, provenance tagging, and disclosure gating. Some are open problems with active work underway but no consensus, such as preference-drift detection, memory-poisoning defense, and safe continual personalization. And at least two — evaluating relationship continuity, and distinguishing genuine familiarity from personalization optimized purely for approval — look less like engineering problems and more like questions that engineering alone won't resolve, because they depend on what we're willing to count as "familiarity" in the first place, which is a definitional and to some extent philosophical choice, not just a measurement one.
Answering the original question, cautiously
Current technology can implement several of the necessary components of persistent personal familiarity: continuity across sessions, structured provenance, some forms of temporal knowledge representation, disclosure-aware retrieval, and gated authorization for action. None of these, alone or combined into the experimental architecture above, is sufficient. No single mechanism — memory storage, retrieval augmentation, long context, or fine-tuned personalization — closes the gap by itself, and stacking all of them together narrows the gap without eliminating it, because several of the hardest problems, such as silent preference drift, evaluating model accuracy against a genuinely reliable ground truth, and distinguishing familiarity from optimized agreeableness, aren't storage or retrieval problems at all.
If there is a defensible narrower claim available here, it is something like this: a system that maintains claims, not just facts, with provenance and confidence, that revises rather than silently overwrites, that gates disclosure by context rather than by relevance alone, and that keeps knowledge and authorization to act as separate steps, is closer to a system that could reasonably be described as familiar with a user than one that merely retrieves. "Closer to" is doing real work in that sentence. It is not the same as "is."
The framing this article arrives at, revised from where it started, is something like: an AI that knows a person would need not only the capacity to remember, but also the capacity to doubt what it remembers, to revise it when the person changes, to forget or set aside what's no longer relevant, to recognize which context a piece of knowledge belongs to, to ask rather than assume when uncertain, to decline to answer when it should, and to keep private information to itself even while technically able to retrieve it. Most of these capacities are individually approachable with current techniques. None of the systems considered here, including the sketch built for it, has all of them at once, robustly, across real usage rather than a curated scenario.
If any part of this problem is solved enough to build on, it is probably the narrowest and most mechanical layer: structured, provenance-tagged, temporally-aware storage with disclosure gating. That is a reasonable foundation for future work, and any product built on it later would be pursuing a well-scoped subset of the problem, not the full claim that the resulting system knows its users. The broader question this article set out to answer remains, honestly, not solved.