You should be able to change your mind

Suppose a team plans to give a public demo on Friday. You ask an assistant to help prepare the announcement. It learns the date, the audience and the argument you want to make.

Then the plan changes. Friday becomes a private review. The public announcement will wait. You update the project brief and tell the assistant why.

On Thursday, it suggests posting the launch thread.

The assistant has remembered something real. It has failed to understand what that memory means now.

This is a design problem for personal AI. Keeping more of a person's history creates a responsibility to handle changes within it. A system that remembers your decisions should also help you stop living by the ones you have replaced.

A past decision has a place

The original demo plan still matters. It explains the work already done, the invitation someone drafted and the announcement sitting in a folder. Deleting every trace of it would make those things harder to understand.

But keeping the plan in history should not leave it active. The assistant needs a relationship between the earlier decision and the later one: this was the plan; this is the decision that replaced it; this is the work affected by the change.

That relationship gives different questions different answers. “Why did we prepare a launch thread?” should lead back to the old plan. “What should we do on Friday?” should use the current one. “What needs updating?” should connect them.

Software has a useful vocabulary for part of this problem. In Bitemporal History, Martin Fowler distinguishes when something was true from when a system learned about it. Information can arrive late, and an earlier record can need correction. The distinction helps explain why a single field called “the latest fact” can lose important meaning.

An AI interface does not need to teach its user temporal database theory. It needs to handle an ordinary sentence: the plan changed.

Three changes that deserve different treatment

Consider three corrections a person might make.

“The review moved to Tuesday.” A real decision changed. The earlier date remains part of the history.

“I said Tuesday, but the note recorded Thursday.” The record was wrong. There may never have been a Thursday plan to preserve as a decision.

“Use Tuesday for this project only.” The instruction has a boundary. It should not rearrange every other project that happens to look similar.

An assistant that puts all three sentences into a growing summary can retain their words and still miss their consequences. The useful work is identifying what each correction changes, where it applies and which later outputs depend on it.

Three illustrative cases for a context system. They describe the meaning of a correction, rather than a product interface.

This becomes more personal when the remembered fact is a preference. You might prefer short meetings while finishing a project and longer working sessions when a new collaboration begins. An assistant should be able to apply either preference in the right setting. It should not turn one period of your working life into an enduring label.

The newest sentence does not always win

Replacing every old statement with the newest matching sentence would create another problem.

A forwarded message can quote an abandoned plan. A colleague can suggest a change without owning the decision. A brainstorming note can contain an option that nobody adopted. The order in which these records arrive does not settle their authority.

The system needs to preserve who said what, the source, the scope and whether a proposal became a decision. When those signals conflict, it should show the conflict in terms a person can resolve. “The project brief says Tuesday; the calendar still says Friday” is useful. Quietly choosing one and hiding the other makes the next mistake harder to diagnose.

The question should be as small as the uncertainty. A person who has already moved a meeting should not have to approve the entire project again. The assistant can update the work clearly covered by that instruction and identify anything outside it.

A correction should reach the work

Acknowledging a correction is only the beginning. If the old date is still in a draft invitation, the work has not caught up.

A helpful assistant should identify the affected drafts, plans and reminders it can inspect. It should distinguish changes it completed from changes it merely recommends, and from places it cannot access. If an invitation was already sent, revising a private draft will not revise the recipient's copy.

This is where a memory system becomes useful to the person doing the work. The correction has visible consequences. They can see what changed and continue from the revised state.

For Zortex, whose context direction connects records across the apps a person uses, this is a demanding design standard. More connected history increases the importance of source, scope and revision. A persistent account of someone's work must be open to correction by the person living it.

Try changing the premise

A useful test for any personal AI begins after it has learned a plan. Change one important part of that plan. Then ask what happens next.

Can it explain which decision now applies? Can it still explain the earlier work? Does it avoid changing unrelated projects? Can it show what remains unresolved without making you reconstruct the whole story?

Those questions reveal more than a demonstration in which the assistant recalls a favorite color or repeats a deadline. They test whether the system can stay useful as the person and the work move on.

In the Friday example, the next useful output is a revised preparation plan for the private review, with the old announcement put aside. The assistant should help you get ready for the decision you made.