Several AI agents can work, but one person still answers their questions
Ask one AI agent to implement a feature and another to research a topic. They can work independently, but their questions and reports arrive in separate conversations. Each time, the user has to reopen the conversation and remember what they asked for and how they answered before. Adding agents does not add hours to the person's day.
I am experimenting with a personal assistant called dot as the point of contact for several Codex tasks running in local environments. Here, a task means a conversation working on a particular request, such as research or implementation. I ask dot to read those conversations and identify what is finished, what remains, and what needs my answer.
Consider three hypothetical tasks, which we will return to throughout the article. A has implemented a requested feature but has not run the tests included in the same request. B asks whether it may introduce an external service. C is work the user explicitly paused. I want dot to tell A to run the tests, bring B's question to me, and leave C paused.
The latest progress reports alone cannot support those choices. Dot also needs to remember what the user requested, why they made earlier decisions, and what they later changed. Research on long-term conversational memory helps identify what to retain and how to use it.
Finishing the work does not necessarily reduce questions for the user
A reports, “Implementation is done. What next?” If the user must repeatedly reply, “Run the tests, as originally requested,” execution has been delegated but prompting the next step remains their job. I want the assistant to reread the request so the user does not have to explain it again.
Researchers have long considered when an assistant should act and when it should ask. Horvitz's 1999 paper discusses uncertainty about user intent, the cost of interrupting someone, and memory of recent interactions. These principles help frame dot's job: use information already available and ask about what it cannot determine.
What difference does remembering earlier conversations make? π-Bench evaluates 100 tasks across five personas. Some tasks require preferences or conditions established in previous conversations or other work. It separately measures final completeness and whether the agent resolves or elicits missing requirements before the user supplies them.
In §4.3, the authors remove preceding sessions for the final task in groups with strong dependencies. Across three reported models, the average proactivity score falls by 9.5 points, while completeness falls by 2.5 points. An agent may eventually finish after the user explains the missing conditions, yet fail to reduce repeated explanation.
The experiment uses simulated users and one agent scaffold; it does not measure minutes saved by real people. It nevertheless shows why evaluating dot only by completed work would miss the effort of answering questions. I also want to count repeated questions and occasions when the user rereads conversations to answer them.
Remember what was requested and why the user decided it
Suppose B's external service was previously considered and put on hold because its data destination was unclear. Remembering only “do not use an external service” could keep blocking it after that question is resolved. Remembering “do not use it until the data destination is checked” identifies what to investigate next.
Research distinguishes memories by what they support, beyond simply saving conversations. CoALA organizes working memory for current decisions, episodic memory for experiences, semantic memory for knowledge, and procedural memory for ways of acting. It is a conceptual design framework, not an experiment showing that creating stores with these names improves performance.
The following proposal turns that distinction into records I would like dot to retain.
| What to remember | Example record | What it helps do |
|---|---|---|
| Current priorities | Prioritize release preparation over features this week | Choose which work to advance first |
| Reasons for earlier answers | B's service is on hold because its data destination is unknown | Check that destination before asking the same question again |
| What remains in each task | A has implemented the feature but not run the requested tests | Tell A to run those tests |
| Usual verification steps | Changes to this app require interaction checks on a device | Avoid treating a successful build as completion |
| Work requested and work paused | A includes testing; C is paused | Advance A without restarting C |
The assistant need not receive every saved conversation on every call. MemGPT separates limited model input from external memory and moves needed information between them. For A, dot could retrieve the original request, earlier answers, and the latest test results. Keeping a path back to the original statements would let it check whether a summary omitted “including the tests.”
Do not confuse old instructions with current ones, or answers across jobs
Suppose the user paused C and later said, “Resume it.” If dot remembers only the earlier stop, C remains paused indefinitely. Finding an instruction is not enough; the assistant must also read later cancellations and changes.
LongMemEval evaluates five abilities: recalling information, combining evidence across sessions, reasoning about time, updating knowledge, and abstaining when information is unavailable. For dot, this suggests checking whether a question was answered later, a stop was lifted, or a relevant conversation could not be read. The paper mainly evaluates question answering; correctly restarting actual tasks requires separate verification.
Remembering a change also does not guarantee using it. PersonaMem studies changing preferences in simulated long-term conversations. It reports cases where applying the latest preference is harder than recalling how preferences changed. A test asking what changed can therefore differ from a test asking the assistant to make a suitable recommendation.
User preferences can also change which procedure to follow. The October 2026 preprint PraxisMemBench evaluates tasks requiring both personal and procedural memory. Its comparisons include DualMem, which stores the two separately and combines retrieved contents at task time. It exposes difficulty preserving the relationship between a user's circumstances and the procedure to use across long interactions. The evaluation uses fictional personas, synthetic histories, and isolated applications; effectiveness for real users remains a separate question.
For dot, simply remembering “the user allowed an external service” would be risky. Suppose one project allows trying such a service while another forbids sending recordings outside the environment. Using an external-transfer procedure in the second project would be wrong even though both instructions came from the same person.
I would therefore record which project and operation an instruction concerns, alongside who said it and when. Later changes should remain linked to the original instruction. A newer instruction about a different job should not erase the earlier job's conditions.
Run the requested tests; ask before adding a service
The opening tasks A, B, and C need different responses. A's tests were already requested, so dot should tell A to run them. B's service has not been approved, so dot should explain what it would do and which data it would receive, then ask the user. C must remain paused until the user requests resumption.
The assistant must distinguish a choice the user might like from work they actually requested. Frequently choosing external services in the past does not approve B's service. Even for A, newly discovered external transfers or charges require checking whether the original request covers them.
Intelligent AI Delegation argues that delegation includes defining permitted actions, monitoring progress, and verifying completion as well as assigning work. I would include that whole sequence in dot's role. The paper proposes a design framework; it does not experimentally evaluate dot.
In practice, dot should read the request and subsequent conversation to check whether remaining work was requested and whether the user later stopped it. The tools executing work also need to prevent unrequested operations. If a conversation cannot be read, the assistant should report what it cannot check rather than assume it may proceed.
When the user answers B, return that answer to B's conversation. Do not automatically apply it to A or C. Also retain whether it means “try it this time” or “try it again under these conditions.” Remembering the answer with the circumstances where it applies helps determine what needs to be asked next time.
Sending A “run the tests” does not mean the tests are done. Dot needs to check whether A ran them and whether they passed. Reporting completion requires results as well as a record of the instruction being sent.
What I am trying with dot and what I still want to build
My operating notes describe dot listing accessible tasks and reading their conversations to identify progress and unanswered questions. It checks whether apparently pending questions received later answers, returns the user's answers to the original tasks, and asks tasks to finish work already requested. Tasks the user paused are not restarted.
An “idle” label alone does not distinguish finished work from waiting for the user's answer. An unreadable conversation also does not establish that the task has no problems. Reports should distinguish tasks dot checked from tasks it could not check.
Reading conversations today differs from reliably remembering and using months of instructions. Consistently keeping the records in Table 1, linking amendments, and retrieving what a particular job needs are mechanisms I still want to implement and evaluate. Current practice does not establish that all the memory mechanisms described here are complete.
Data handling needs inspection too. Tasks running locally do not establish that conversation storage or model input stays on the same device. Actual connections determine what information goes where.
Does the user explain less while the requested work proceeds correctly?
I want to compare managing tasks directly with managing them through dot. Comparable task types and difficulty would let me record repeated explanations, rereading conversations, and time spent waiting. Fewer questions would not count as success if the assistant skipped necessary checks and advanced the wrong work.
| What to find out | What to count | Mistakes to check alongside it |
|---|---|---|
| Does the user repeat fewer explanations? | Questions already answered; conversations reread to answer | Different conditions mistakenly treated as the same question |
| Does requested work proceed without waiting? | Time from the next step becoming possible to actually starting | Restarting paused work, duplicate instructions, unrequested actions |
| Are changed instructions remembered? | Whether “resume” or “cancel this time” is applied | Using old instructions or an answer intended for another task |
| Can completion reports be trusted? | Verification results and time spent on human corrections | Tests not run, missed checks, and rework |
The research shows why retrieval, updating, and using memories in later work need separate checks. For dot, I also want to verify that it advances only requested work and checks the results. There are not yet measurements supporting general claims about time saved or how many tasks it can manage.
The goal is for the user to focus on the new question of whether to adopt B's service. Starting A's already requested tests should require less repeated instruction. Keeping C paused should require less reminding. That is why I want dot to remember what I requested, the reasons behind it, and the instructions I later changed.