Revised October 19, 2026.
Suppose your assistant remembers that you prefer morning meetings. You then tell it to keep the next few mornings free so you can finish a piece of work. When it recommends another morning slot, it can point to a genuine preference. It has still misunderstood you.
That small example gets close to the problem I’m working on with Maya’s Personal Cognitive Digital Twin, or PCDT. Remembering something about a person is easier than deciding what it means for the decision in front of them. The latter is where personalization becomes useful, and where it can become intrusive or simply wrong.
My ambition is a personal system that develops an understanding of my knowledge, preferences, and judgment over time. I also need to be able to inspect and challenge that understanding. A system that becomes harder to correct as it learns more about me would be a poor digital twin. That understanding can support my judgment; it cannot stand in for my intentions or identity.
An old preference can be right and irrelevant
“Morning meetings” might mean internal calls in your home time zone. It may have been a preference during a particular project. Perhaps you said it while comparing two inconvenient options. The words do not settle the scope.
A personal model adds interpretation to stored information. That is useful when it connects a current request to something the person would otherwise have to explain again. It becomes a problem when the interpretation quietly grows beyond the source: a preference becomes a rule, an option becomes a commitment, or an old decision becomes the answer to a different situation.
In the meeting example, the assistant needs to reconcile a general preference with a current exception. I would expect it to recognize that the mornings are unavailable for the stated period. If the exception is unclear, asking a short question is better than confidently following the older pattern.
This is how I think about PCDT: the person’s context should help the system reason about the present request. The system should also be able to show which parts of that context it relied on, including what remains uncertain. For a remembered preference, that includes where it came from, when it applied, and whether later information changed it.
People and commitments change the meaning of a request
Consider an illustrative workshop discussion. A calendar entry holds a provisional date. Earlier messages suggest that the consultant usually prefers remote delivery. A client now asks whether an in-person session is possible.
The assistant could combine those records into a polished reply confirming an online workshop. Every source might be real, yet the reply would invent a decision. The date is provisional, the preference is general, and the client’s question leaves the format open.
Relationship history can help here. The consultant may have promised to consider both formats or may still owe the client an answer. That context makes a follow-up useful, provided the assistant keeps the people and their commitments straight. A client’s preference for an in-person session should not become a remembered preference of the consultant.
For Maya, this is part of building a system around a person’s life rather than a collection of isolated prompts. The difficult work is preserving the distinctions that make the information useful. More material in the context window can make a mistaken interpretation sound better supported without making it correct.
A correction has to survive the next conversation
Now let the consultant correct the assistant: the date has moved, and this workshop should be considered for in-person delivery. The next draft is a useful test. If the assistant returns to the old online arrangement, its polite acknowledgment of the correction has achieved very little.
I would test this before testing how much history the system can recall. Introduce a preference, add an exception, change a relevant fact, then ask for another recommendation. Check whether the answer changes for the right reason. Add an ambiguous message from the other person and see whether the assistant asks rather than resolves the ambiguity in its own favor.
LongMemEval is useful related research because it examines abilities such as reasoning across sessions, temporal reasoning, knowledge updates, and abstention. Those distinctions help expose failures that a simple recall test would miss. They do not establish a benchmark result for Maya.
There is a product cost to correction too. A person should not have to find and repair several hidden summaries after changing one fact. I want to know that a correction has been understood, and to see a conflict if the system cannot yet resolve it. Otherwise, maintaining the assistant becomes another task on the person’s list.
A real source can still support a wrong answer
A source link lets the reader examine the basis of an answer, including the detail the assistant may have missed. The calendar entry might still be tentative, or the message might offer an option without accepting it. Citing the record makes the mistake easier to find; it does not prevent the reply from misstating what was agreed.
Maya’s reply-validation work checks aspects of how an answer represents its requirements and evidence. Those checks can catch some incomplete or inconsistent answers, but recognizing a reference cannot establish that the underlying record is true, current, or correctly interpreted. I need tests that reach beyond the representation of the answer into its meaning.
Synthetic records make those tests possible without exposing private conversations. A tentative entry beside a later correction tests which state the assistant uses; two people with different preferences test whose context it applies. Leaving a commitment unresolved checks whether the assistant preserves the uncertainty or fills it in. Each variation should have an expected outcome before the system prepares its reply.
A convincing paragraph is not the acceptance condition. The important result is whether the recommendation respects the current facts, the right person, and the uncertainty still present in the record.
Knowing my habits does not settle what I have authorized
Sending the workshop reply would change the situation because another person could reasonably act on it. Even a well-grounded recommendation therefore needs a separate decision about whether the assistant is authorized to communicate it. Understanding the consultant’s usual choices does not establish permission for that particular action.
That boundary matters more as a personal system becomes familiar with its owner. “You normally accept these invitations” may be a reasonable basis for a suggestion. It is an inadequate basis for assuming authority over every future invitation.
I want the distinction to remain easy to understand: what Maya recommends, what I have approved, and what has actually happened. If an approved operation fails, the system needs to retain that failure. An intention to send a message is not evidence that it was sent.
There is a genuine tradeoff here. Asking for confirmation at every step makes an assistant tiring to use. Delegating more authority can remove that friction, but the boundary needs to be a choice I can understand and revise. More accurate predictions of my preferences would not remove that responsibility.
Start with a decision you can inspect
For someone building a personal assistant, I would start with a small decision rather than a claim that the system knows the whole person. Use a synthetic conversation with an earlier preference, a new exception, two people, and an unresolved commitment. Ask for a draft, make a correction, and ask again.
The result should be understandable without access to the implementation. You should be able to see whether the current instruction mattered, whose preference was used, and why the system acted or held back.
That is the standard I’m working toward with PCDT in Maya. The relationship becomes valuable when it carries useful understanding forward while leaving me free to change my mind. If you have found a case where personalization becomes more burden than help, I would be interested in comparing it with this approach.
Related reading
Progressive Capability Discovery: finding the right tools for an AI agent
Discover more from Ajith Vallath Prabhakar
Subscribe to get the latest posts sent to your email.
One Comment