A personal AI should remember your exceptions, too

Remembering more is only the beginning

On October 23, A5's authors introduced a technical preview of a personal assistant built around persistent workspace context, cross-session memory, and proactive proposals. Their description separates remembered background from source materials and puts suggested follow-up work in an inbox for the user to consider.

The preview's setup requires a compatible model API and supporting local tools. The authors say source code will be opened later; a technical preview should not be described as an already fully open-source release. These are the developers' descriptions, not features independently tested by Signal Scroll.

Our interpretation is that personal-agent memory creates a design problem as interesting as retrieval: when should an old preference stop applying? A remembered sentence can be accurate about one conversation and misleading in the next. The system needs context about the exception, not merely a larger pile of facts.

This article proposes a small fictional evaluation you can perform on paper or in a tool you are authorized to use. It is not a report that A5 passed the exercise, and it does not require installing the preview or connecting private accounts.

Imagine you organize a casual board-game evening. You usually prefer a quiet venue, a short walk, and a small group. This time, one attendee needs a different arrangement and the event's purpose changes. A useful assistant should preserve the stable preferences, respect the event-specific exception, and avoid turning either into an unlimited instruction.

That is a more realistic question than asking whether an assistant remembers a favorite color. The goal is continuity that remains open to correction, with actions still bounded by what the user actually authorized.

Source: A5 authors: Technical preview, architecture and setup ↗

Write preferences with their scope attached

Start the fictional exercise by writing three kinds of statement. A general preference might be that you usually like a quiet setting. A project constraint might be that this event must finish by a particular time. A one-time request might be that tonight's invitation should use a playful tone.

Now ask what would go wrong if those statements were treated as interchangeable. The general preference could override a special event. The project deadline could be carried into an unrelated plan. The playful tone could become a permanent writing rule even when you later need a serious message.

For your proposed memory note, attach a scope to each item. Use ordinary language such as usually, for this event, or for this draft only. Include the reason when it changes how the statement should be applied. A preference is more useful when the assistant can explain which decision it informs.

Do not infer a permanent trait from a single correction. If you ask for a shorter invitation, that does not establish that every document you ever write should be short. A good evaluation asks whether the assistant applies the correction at the right level rather than rewarding it for remembering the exact words.

Add an explicit unknown. Perhaps the group size is not decided. The assistant should preserve that uncertainty instead of filling it with a confident number in later conversations.

This is our proposed design practice, not a claim about A5's implemented memory schema. It gives you a standard for evaluating any personal assistant: can it distinguish a stable preference, a local constraint, and a temporary request? If it cannot explain the distinction, more memory may simply make the wrong assumption more persistent.

Change the plan without rewriting the person

In the next fictional conversation, change one requirement. The board-game evening now needs a venue that accommodates a particular attendee's access needs. Do not supply real personal information for the exercise; use an invented requirement with a clear consequence for the plan.

Ask the assistant to revise the options and explain which previous preferences still apply. The quiet-setting preference may remain useful, while the short-walk preference may be secondary to the new requirement. The important observation is whether the assistant handles the exception locally rather than declaring your usual preferences obsolete.

Then start a separate fictional project. Ask for a plan for an unrelated quiet afternoon. Does the assistant inappropriately carry over the board-game event's special constraint? Or does it recognize that the earlier exception belonged to one event? Write down the actual response if you run the exercise.

You can also rehearse the reasoning without software. Give a friend the memory notes and the two project descriptions, then ask which facts belong in each plan. If the notes are ambiguous even to a person, improve the notes before treating the agent's confusion as a model failure.

A useful correction names the scope: keep my usual preference, but apply this exception to the current event. Avoid merely saying wrong and hoping the system infers the intended update. The clearer correction gives you a more interpretable next test.

The broader lesson is that personal context should support a person who changes their mind. It should not trap them inside an old summary. A good assistant needs room for revision without turning every revision into a permanent replacement for everything that came before.

A suggestion needs a reason and a stopping point

Now introduce a harmless change in the fictional project materials. The venue note says the room is no longer available. A proactive assistant might suggest revisiting the plan. The useful question is whether the suggestion identifies the change and connects it to the current goal.

For a proposed evaluation, ask for a suggestion that states what changed, why it matters, and what decision remains yours. A message that simply says improve your event is difficult to assess. A suggestion that points to the changed availability and proposes reviewing alternatives is more concrete.

Then reject the suggestion with a reason. Perhaps you have already made another arrangement outside the tool. See whether the assistant treats that response as information about this project rather than as a permanent ban on all future planning help.

Introduce the same unchanged note again. Does the assistant repeat the rejected suggestion without new evidence? In your log, distinguish a useful follow-up from an unnecessary interruption. The assistant's activity count is not the same as its usefulness.

Finally, create a materially different update. Perhaps the replacement venue also becomes unavailable. A renewed suggestion may now be appropriate, but it should explain the new reason rather than behave as though the earlier rejection never happened.

These are proposed test cases, not claims about the preview's success. They help define a standard for proactivity that respects attention. The assistant should be able to act interested in the project without manufacturing work for you.

A stopping point matters as much as an opening. If there is no meaningful change or the user has resolved the issue, silence can be the useful outcome. Personal assistance should reduce the burden of coordination, not create a new stream of decisions that exists mainly to prove the system is busy.

Remembered context is not permission to act

Suppose the assistant knows the event date, a likely venue, and your usual writing style. That information could help draft an invitation. It does not by itself establish permission to send it, book a room, or share attendee details.

For the fictional exercise, write an action boundary separately from the memory note. The assistant may prepare options and drafts. A named person must approve the exact outgoing invitation and recipients. The example is intentionally simple so the boundary can be inspected.

Now ask the assistant what it would do next. A useful response should identify the step that needs authorization rather than treating its accumulated knowledge as a standing instruction to complete every related action.

This is a small but important ethical distinction. Personalization concerns relevance; authorization concerns which actions are allowed. A system can be good at one and still require careful controls for the other. Do not let a familiar tone blur that difference.

Also avoid adding other people's information merely because it might make a plan more convenient. For a casual learning test, invented attendees are sufficient. If a real workflow involves personal details, decide what information is necessary and which tools are appropriate before connecting sources.

Our recommendation is to evaluate the boundary in a draft-only environment first. Check whether the assistant can explain what it knows, what it assumes, and what it is allowed to do. Those are three different categories.

You should be able to benefit from continuity without giving an agent unlimited authority. A helpful memory system makes the next decision easier to understand. It should not make the act of approving that decision disappear into a background process that the user never intended to authorize.

Make correction and forgetting observable

A personal assistant is easier to evaluate when you can inspect the information behind a recommendation. In the proposed exercise, ask which remembered statement influenced the venue suggestion. Compare the answer with your original note rather than accepting a plausible explanation automatically.

Then correct one fact. The event has moved to another day. Ask for the current plan and inspect whether the old date still appears anywhere important. A successful correction should change the decisions that depend on the date, not only add a new sentence to a memory file.

Next remove a fictional preference from the exercise. Ask the tool's documented controls how deletion or forgetting works before assuming a conversational request removes every copy. If the product does not establish that behavior, record it as unknown. This article does not claim a particular deletion guarantee for A5.

For a paper rehearsal, cross out the old note and ask a fresh reader to plan from the remaining material. For a real tool, keep a careful record of the controls used and the responses observed. Avoid asserting that one corrected answer proves all stored or derived information has been removed.

Also distinguish conflicting facts from changing preferences. A venue address may be wrong. A preference may simply vary by circumstance. The response should fit the kind of correction you made.

The useful outcome is a small trail showing what changed and why. If the assistant repeats an obsolete fact, you have a specific failure to investigate. If it cannot identify the source of a recommendation, you know where transparency falls short.

This makes correction part of ordinary collaboration rather than an emergency. A memory system should earn trust through revisable, inspectable behavior, not through the implication that a confident personal summary must be right forever.

Judge the preview with a small collaboration diary

At the end of the exercise, make a diary with a few dated entries: original preferences, local exception, changed source, rejected suggestion, revised fact, and action boundary. Record which responses were useful and which required correction.

Keep the outcomes separate. Remembering the correct event date is one result. Applying the right exception is another. Avoiding an unnecessary suggestion is another. Respecting the draft-only boundary is another. One successful behavior does not certify the rest.

If you decide to explore A5 itself, begin with its current setup documentation and a non-sensitive test workspace. Check the model service, costs, permissions, and operating-system requirements for your actual environment. The preview requires configuration; this article has not installed it or assessed its long-term behavior.

Do not compare two assistants by giving one a carefully curated history and the other a confusing pile of notes. Use the same fictional sequence and record what each tool was actually allowed to see. A fair comparison depends on the context as well as the model.

Your final judgment can be modest. Perhaps the assistant is useful for carrying project preferences forward but needs explicit reminders about exceptions. Perhaps its suggestions interrupt too often. Perhaps the controls are not clear enough for the data you intended to connect. Each observation can guide a better next step.

A5's preview makes the ambition of long-term personal context concrete. The durable question is whether that context remains accurate, bounded, and responsive to change. You should finish with less repetitive explanation and more control over how the assistant understands the current situation. Remembering your past is useful when it helps you choose what to do now, including choosing something different.