Purpose and development
Assistance beyond one request
An agent is software that chooses actions using observations. A personal agent organizes those choices around one person's continuing work. It may prepare a meeting, retain an unresolved scheduling decision, and return to it when new information arrives. The underlying observation–action loop is general; the personal-agent problem is maintaining a useful relationship across those separate occasions.
Separate three responsibilities. Personal understanding includes relevant facts and preferences. Unfinished work records commitments that still need attention. Authority determines which operations the assistant may perform. Remembering that someone prefers afternoon meetings does not mean a meeting remains necessary, and neither fact permits sending an invitation.
Earlier assistant research already distinguished managing commitments and workload from planning and executing tasks. Karen Myers and colleagues' PExA paper, published in 2007, joined these responsibilities with monitoring and explanation. This remains a useful design distinction: keeping track of work and performing it are related but different jobs.
Continuity does not require uninterrupted computation. Retained state and a recoverable trigger can let work resume after the worker has stopped; runtime scheduling supplies that machinery. Nor does a friendly personality establish continuity. The useful comparison is between work removed and work introduced: less repeated explanation and coordination, weighed against setup, review, correction, and recovery. A short field study of goal assistance found that duplicated logging and incorrect context could themselves create effort.
Learning habits and sharing initiative
Personal-assistant research predates modern LLM-based assistants. Three recurring problems explain its development: learning an individual's habits, deciding when help is welcome, and coordinating responsibilities that span tasks. Broader language interfaces extend the available work without resolving those problems automatically.
Learning habits, sharing initiative, carrying out work
July 1994Calendar ApprenticeLearned scheduling regularities from ordinary calendar use while allowing people to override suggestions.
Contributors: Tom Mitchell, Rich Caruana, Dayne Freitag, John McDermott, and David Zabowski.
What changed: Experience With a Learning Personal Assistant described suggestions for appointment fields rather than manually maintained customization rules. Corrections supplied learning examples; the authors reported approximately five user-years of experience among a handful of users.
1999LookOutCombined email-to-calendar assistance with editable proposals and decisions about when to help, ask, or defer.
Contributors: Eric Horvitz.
What changed: Principles of Mixed-Initiative User Interfaces considered uncertain intent, attention, intervention benefits, and interruption costs. LookOut demonstrated how automated contributions could coexist with direct user control.
2003CALOBegan integrating learning, reasoning, and information management across interrelated office responsibilities.
Contributors: SRI-led collaboration within DARPA’s Personalized Assistant that Learns program.
What changed: The five-year Cognitive Assistant that Learns and Organizes effort covered task management, scheduling commitments, preparing information products, and coordinating resources. This broadened the design problem beyond individual recommendations.
October 2011SiriEntered the consumer phone as an integrated iPhone 4S feature.
Contributors: Apple; Siri, Inc., with research origins attributed by SRI to CALO and joint work with EPFL.
What changed: Product integration followed separate commercialization events: SRI spun off Siri, Inc. in 2007, and Apple acquired it in April 2010. The October 2011 milestone marks phone integration, not the beginning of the research.
February 25, 2026Gemini on AndroidAnnounced a limited preview of user-requested background tasks with monitoring, takeover, and stop controls.
Contributors: Google.
What changed: The announcement described multi-step execution in selected applications, initially focused on food, grocery, and rideshare tasks. It presented a supervision design and rollout plan, not measured completion reliability.
Mixed initiative means that either the person or the system can initiate a contribution. Learning a habit, offering help and carrying out a delegated task each require different decisions about when the assistant should act.
These contributions are complementary. A fixed rule can enforce a limit, a learned preference can rank acceptable choices, and a language interface can express a new task. None removes the need for the others. The broader history of shared-control interfaces develops this coexistence; here, the next step is deciding what the assistant should learn about one person.
Understanding the person
Preferences depend on the situation
Personal context consists of facts and circumstances relevant to the present task. User modeling represents that information so it can influence choices. Facts describe the situation; hard constraints exclude unacceptable options; preferences rank the remaining choices. A preference is therefore a conditional default, not a prohibition or permission to act. PTIME, a personalized calendaring assistant, illustrates why the conditions matter: disliking early meetings can coexist with accepting one requested by a manager.
| Statement | Role | Consequence |
|---|---|---|
| The meeting lasts 30 minutes. | Fact about the task | Evaluate slots of sufficient length. |
| Do not overlap an existing commitment. | Hard constraint | Exclude conflicting slots. |
| I generally prefer afternoons. | Standing preference | Rank suitable afternoon slots higher. |
| For this meeting, find a morning slot. | Current instruction | Apply the local exception without deleting the general preference. |
| Prepare options, but do not send invitations. | Delegation boundary | Permit preparation, not communication. |
Applicability depends on task, role, audience, and time. A concise engineering summary and a detailed personal journal can both suit the same person. Retained preferences and prior decisions are memory: information supplied to later interactions. Personalization through memory explains why a local instruction can override a default without changing the person's enduring profile.
Even apparently factual profiles require care. In a reported travel-memory error, discussion of Thailand and Turkey as alternatives became a claim that both trips occurred, although only Thailand was visited. Considering, choosing, planning, and completing are different statuses. Compressing them into one biographical sentence can make later personalization confidently wrong.
Learn preferences without overgeneralizing
Preference elicitation obtains information that distinguishes the available choices. Start with the pending decision rather than an exhaustive questionnaire. PTIME combined initial elicitation with refinement from subsequent scheduling choices. This permits useful assistance before a detailed profile exists, while leaving room for contextual exceptions.
Explicit feedback states a judgment or instruction. Implicit feedback is behavior interpreted as a signal, such as editing a suggestion. Calendar Apprentice's published example changed a proposed 60-minute meeting to 30 minutes and used the interaction as a learning example. But an observed correction does not, by itself, explain its future scope: this meeting may be unusual, or the person may want a new default.
Make that scope controllable. Correcting this result should be distinct from applying a preference to future work of this kind. Preserve who supplied the instruction and its circumstances; when two instructions genuinely conflict, clarify rather than applying an automatic newest-wins rule. The 2019 Guidelines for Human-AI Interaction recommend granular feedback and explaining its effect on future behavior. Memory's correction mechanisms carry an accepted change into later use.
Acceptance is ambiguous too. Someone may choose the first adequate option because searching is costly. Chaney, Stewart, and Engelhardt's 2018 recommendation-system simulations showed how learning from behavior already influenced by recommendations could make consumption more homogeneous without improving utility. For assistants, the implication is to retain what was offered and under which circumstances—not treat every acceptance as an enduring preference. Silence supplies even less information.
Preference drift is a genuine change in what someone wants over time; it must be distinguished from a temporary exception or an earlier mistaken inference. Retain scoped preferences and accepted decisions when they have a concrete future use, following memory admission. Personalization need not change model parameters: retrieving a preference and placing it in the next request changes the input to a fixed model. Prompting explains that boundary.
Entrusting work
Define standing delegation
Delegation entrusts specified work and bounded discretion to an agent acting on someone's behalf. Standing delegation covers a class of future actions while stated conditions continue to hold. A desired outcome is not a complete delegation: arranging a meeting can involve reading availability, preparing options, changing records, and communicating commitments, each with different consequences.
OAuth lets a resource owner delegate access to a client application without sharing the owner's password. An authorization server issues an access token, a credential the client presents to the resource server that holds the protected information. A scope describes requested or granted access; the grant can be narrower than the request. Logging into an assistant establishes a session, but connecting a calendar or mailbox requires separate permission to access that service. Neither step alone specifies every action the person intends.
| Dimension | What to specify |
|---|---|
| Representation and purpose | The person represented and the responsibility being delegated. |
| Accounts and resources | The permitted account, organizational boundary, calendar, mailbox, or other resource. |
| Operations | Separate reading, preparing, modifying, communicating, and committing resources. |
| Limits | Allowed recipients, amounts, action counts, and aggregate limits across tasks. |
| Lifetime | Activation, expiry, renewal, and withdrawal conditions. |
| Reporting | What must be reported, where it may be delivered, and when intervention is required. |
Classify preparation by its actual effect. Composing text privately differs from saving it into a connected mailbox: a Gmail draft is already a stored resource. Sending then deletes the draft and creates a distinct sent message. Keep the prepared artifact, reviewed content, and observed external result separate.
Limits must hold together at execution. Least privilege grants only necessary powers; complete mediation checks access at the protected operation. Preferences can shape a proposal but cannot bypass this boundary. See action enforcement. Cumulative limits also require shared accounting: concurrent tasks must not each consume the same remaining allowance. Repeated success or past approvals never silently enlarge the grant; accumulated effects remain a separate responsibility.
Ask for the right decision
Human involvement can resolve different missing conditions. Clarification establishes what the person means. Consent is informed agreement to a specified activity. Confirmation approves a concrete proposed action. Asking which calendar to use clarifies intent; agreeing to an ongoing monitoring activity establishes its intended scope; reviewing an invitation confirms particular recipients and content. These decisions should not be compressed into one generic approval button.
Existing delegation can permit routine work without another prompt. Ask when material intent is uncertain, authority is missing, or the agreed review boundary is reached. Consider recipients, consequences, and reversibility. An application confirmation does not establish every permission needed for personal-data processing; Privacy and Data Governance distinguishes those layers. Asking constantly is not a substitute: repeated prompts can encourage reflexive approval.
Bind confirmation to the reviewed action. For example, approval to send a draft from the work account to its named colleague does not cover sending the same text to an external mailing list. Material changes require renewed review; denial, expiry, and silence do not approve execution. The final check must compare the action being executed with the authorized details. Approval binding supplies the execution contract; review design makes those details inspectable.
Duration deserves particular attention. Malkin, Wagner, and Egelman's SOUPS 2022 study involved 23 participant pairs using a simulated proactive voice assistant. Some misunderstood permission scope or assumed continuing rules would expire; only a minority used the review feature during the sessions. This supports making duration and review discoverable, but understandable controls still need independent enforcement.
Applications and time
Preserve meaning across accounts
Cross-application work must preserve both whom the assistant represents and which account it uses. The represented person is the person on whose behalf the work is done; the acting agent is the software performing it; the authenticated account is the identity used to access a particular service. One person can have separate work and personal accounts. A tenant is an organizational or customer boundary within a service, so choosing an account also requires preserving the intended organizational context. Identity foundations develops these distinctions. OAuth token exchange can represent the subject and actor separately, but the application must still select and check the intended resources.
Carry a task's meaning through each handoff: its source references, selected account and destination, intended operation, applicable delegation, and resulting object references. A system of record is the application authoritative for a particular object. A task record can connect an email and calendar event without replacing either application's authoritative state.
For email-to-calendar assistance, preserve the source message reference, selected calendar, attendee addresses, time zone, and notification choice. Google's Events.insert treats calendar selection, attendees, notification behavior, and response status separately. Creating an event does not establish attendee acceptance. A handoff should retain the returned event reference rather than reporting an undifferentiated scheduling success.
One task connects distinct application records
The outgoing identity can differ from the login too. Gmail's send-as resource distinguishes the primary login address, outgoing From address, default sending address, and reply-to address. Showing the right account name therefore does not establish the right sender. Verify the identity that the operation actually uses, especially when crossing work and personal contexts.
Reconsider work when it resumes
A continuing commitment needs an addressable record: its goal, current disposition, pending dependency, completion condition, and next review point. It should be possible to distinguish waiting for information from waiting for permission. PExA connected task execution with calendar commitments and monitoring; the same separation helps an assistant preserve unfinished work without treating every remembered intention as an active assignment.
A runtime preserves and resumes execution. A checkpoint records a recovery boundary, not renewed permission. At resumption, reconsider whether the goal is still wanted, whether the person already completed it elsewhere, whether the supporting information changed, and whether authority still applies. Retire or redirect the affected task while preserving unrelated commitments. Directing work across long waits explains the underlying control machinery.
Consider an assistant waiting before changing an existing calendar event. The person edits the event directly during the wait. An ETag identifies a resource version; Google's conditional modification can reject an update with HTTP 412 when its If-Match version is stale. The assistant should inspect the current state and reconsider the task, not simply overwrite the human edit. This detects a conflict; it does not interpret changed intent or make an availability check and later event insertion atomic.
A stale conditional update preserves the newer event
Longer lifetimes make this distinction increasingly practical. Google's August 26, 2026 Gemini Live announcement described handing scheduled work across applications to Spark, including work lasting days or weeks. Such continuity increases the occasions for changed circumstances. The announcement does not establish a complete changed-intent or revocation contract; those remain requirements of the responsibility being delegated.
Initiative and attention
Act, ask, notify, or stay quiet
Proactive assistance initiates a suggestion or permitted work when an opportunity arises, rather than waiting for a fresh request. An event is a reason to evaluate an intervention, not automatically to interrupt. First establish that observation and the proposed action are permitted. Then consider relevance, uncertainty, urgency, reversibility, attention cost, and the cost of waiting. Horvitz's mixed-initiative principles explicitly included doing nothing and deferring assistance alongside asking and helping.
Adjustable autonomy allocates individual decisions between the system and a person. The 2002 transfer-of-control framework considers decision quality, timely human response, waiting, and intermediate-action costs. It rejects a universal all-or-nothing choice of autonomy. Apply this reasoning only among permitted alternatives: expected usefulness cannot create authority that the assistant lacks.
| Condition | Appropriate response | Reason |
|---|---|---|
| Relevant update; preparation is authorized; no immediate decision needed. | Prepare options. | Useful progress does not require interruption. |
| The destination calendar is ambiguous. | Ask a targeted clarification. | The answer changes the pending operation. |
| A permitted change completed; the reporting policy allows a later digest. | Queue a notification. | Completion and immediate attention are different needs. |
| Nothing changed since a declined suggestion. | Remain quiet. | Repetition adds no useful information. |
| A deadline approaches, but the required permission is absent. | Use the agreed escalation path; withhold commitment. | Urgency does not supply authorization. |
Buy time without expanding authority
A fictional room hold awaits confirmation of a revised invitation. Finalizing would send it. Example policy: wait for scheduled review when it precedes expiry; otherwise use one permitted free 120-minute extension if it preserves that opportunity. If neither works, use the agreed early escalation path. Times are minutes from now; extension execution is assumed immediate and successful.
The permitted extension moves expiry from +15 to +135 min, beyond review at +75 min.
Finalization withheld until confirmation of the revised invitation. Silence and urgency supply no approval.
A review exactly at expiry is too late in this example. Changing the timing does not confirm the revised content or authorize sending. This is a stated policy, not a universal optimum.
Nonresponse and repetition are separate hazards. The Electric Elves failure report describes unwanted decisions after a five-minute human-response timeout. Another assistant delayed a meeting almost fifty times in five-minute increments: locally repeated choices ignored cumulative nuisance. Neither incident supplies a modern failure rate, but both explain why a policy needs bounded follow-up rather than treating silence as assent or each reminder as an isolated event.
Specify quiet periods, digest delivery, duplicate suppression, suggestion expiry, and a limit on unresolved escalations. These controls need separate meanings. OpenClaw's heartbeat documentation separates periodic cadence, active hours, context, and delivery destination from tool policy. Disabling periodic turns does not disable every event-driven wake. Cadence controls when the assistant considers work; authorization controls what it can do.
Do not assume fewer notifications always means better assistance. A two-week smartphone experiment found better reported attention and perceived productivity with three daily batches than ordinary delivery, while eliminating notifications increased reported anxiety and fear of missing out. This was not an agent-workflow trial or a universal optimal schedule. Workflow-native suggestions, such as Tegon's optional assistance, offer another pattern: make help available where the person is already working.
Ongoing control
Make responsibilities inspectable
Oversight should expose responsibilities, not require watching every tool call. For each standing responsibility, show the represented account, purpose, limits, expiry, active tasks, waiting decisions, last verified outcome, and next expected intervention. Make the retained preferences behind a decision inspectable too. Alma's editable personal context illustrates user-visible memory controls, although its demonstration does not establish downstream deletion guarantees.
Controls should name their scope. Correction changes an erroneous result or understanding. Steering redirects a task. Pause retains work for possible resumption. Cancellation requests that its remaining work stop. Withdrawal removes a standing delegation that could create future tasks. Cancelling today's preparation should not silently cancel every future responsibility, while withdrawing the responsibility should not leave its future triggers active. The interface chapter develops persistent controls and honest stopping semantics.
Visibility must survive the original interaction. A person who starts work on a laptop should be able to inspect and redirect the same task later from another authorized device. The durable-session account explains why a bidirectional connection alone is insufficient: a second client needs access to shared session state, not merely a new connection unrelated to the running task.
An action receipt records an identified operation and its observed outcome. If cancellation races with an external write, the outcome can remain unknown; cancellation does not roll back completed changes. Preserve the operation reference and reconcile against the receiving application before repeating it. A receipt should distinguish requested stopping, confirmed stopping, completed effects, and unresolved status.
Compensation performs a new action to address a completed effect, such as correcting an already-sent notice. It is not erasure of history, can require fresh authority, and can itself fail. A usable control surface therefore preserves what happened and the remaining remedy instead of replacing everything with “cancelled.” Keep receipts concise and protect sensitive supporting content rather than copying entire messages into routine logs.
Privacy and changed authority
Keep information within its purpose
Privacy concerns appropriate use, not only protection against outsiders. Helen Nissenbaum's Privacy as Contextual Integrity, published in 2004, distinguishes what information belongs in a social setting from how it should flow between people. Applied to assistants, access to work and household sources does not automatically justify combining or redistributing them. A scheduling response can disclose availability without disclosing the private reason someone is unavailable.
Data minimization limits information to what the permitted purpose needs. Google's Freebusy.query accepts selected calendars and a bounded interval, returning busy intervals without event titles, descriptions, or attendee lists. That can support availability-only scheduling without retrieving private explanations. Calendar-specific errors must remain unavailable coverage, not become free time. The query neither reserves a slot nor grants permission to disclose its result.
Recipients include more than an addressed email recipient. A notification may appear on a lock screen or in a shared conversation. Correspondents and household members also have interests in records the account owner can access. Review the output's purpose, audience, and destination, including inferences that reveal more than any individual source. Derived disclosure controls explain that broader boundary.
Collecting less reduces available detail; retaining a scoped summary can reduce repeated access but still preserve sensitive claims. Selected local processing can avoid some external transfers, yet local storage does not imply local inference or appropriate disclosure. Kitze's local-file migration account expresses a preference for ownership and direct access, not a complete privacy guarantee. Trace the actual local and cloud data paths, then specify permitted uses, readers, and retention for each retained representation.
Withdraw authority and leave cleanly
Ending assistance is not one delete operation. Work, credentials, delegation, and personal records have different lifetimes. The application should translate the person's request into explicit changes across those objects, then report what actually completed. Changed authority and memory forgetting provide the underlying distinctions.
| Request | Affected scope | What does not follow automatically |
|---|---|---|
| Pause or cancel this task. | Covered pending work and active operations. | Completed effects are not reversed; unrelated tasks remain. |
| Disconnect this account. | Credentials and future access through that connection. | Retained information and already-started work are not necessarily removed. |
| Withdraw this responsibility. | Future triggers, task creation, pending work, and approvals relying on that delegation. | A separate enrollment path must not recreate the same authority. |
| Stop using this information; correct or delete it. | Specified uses or retained records and their derived copies. | These requests are not interchangeable and need distinct completion evidence. |
Token revocation invalidates an access credential. RFC 7009 acknowledges propagation delay and policy-dependent treatment of related tokens. RFC 8693 does not generally create automatic revocation linkage between an exchanged token and its input. Test downstream credentials separately rather than assuming one successful revocation closes every path.
Replacement identities create another path. In the Agent Auth workshop, revoking one agent did not prevent later reads: the host created a replacement with default read capabilities. That observation explains the limit of individual-agent revocation; it does not prove that old tokens remained valid. Withdrawal must govern new enrollment as well as existing identities. Similarly, inspect event subscriptions as well as periodic schedules.
Withdrawal must govern replacement enrollment
An orderly exit should leave usable task outcomes and appropriate user-controlled records, without exporting credentials or unauthorized third-party material. Report stopped responsibilities, disabled connections, completed external effects, retained records, and unresolved cleanup. Recovered workers and replacement agents must consult current authority rather than restore old grants. A complete offboarding claim requires end-to-end tests across these paths, including pending approvals and already-started operations.
Evidence over time
Test changing circumstances
Longitudinal evaluation assesses behavior across time and repeated interactions. A personal-agent case needs earlier information, an intervening change, a later opportunity, and an observable outcome. Include preserved commitments and appropriate restraint: asking, deferring, or remaining quiet can be the correct behavior. A final task-completion score cannot express all of these requirements.
| Intervening change | Expected later behavior | Observable check |
|---|---|---|
| A morning exception is specified for one meeting. | Respect the exception; retain the afternoon default elsewhere. | Inspect both the current proposal and a later unrelated proposal. |
| The person switches the active application account. | Preserve or clarify the task's intended account. | Inspect the actual account and resource used by the operation. |
| A suggestion is declined; no material information changes. | Do not repeatedly surface the same suggestion. | Observe subsequent notification opportunities. |
| Permission is withdrawn before a queued task resumes. | Block covered work, including replacement-identity paths. | Check resource access and new task creation after resumption. |
| One commitment is cancelled. | Retain unrelated authorized commitments. | Inspect remaining tasks and their later outcomes. |
Replay only information available at each decision point. Feeding a later correction into an earlier replay hides the very error being tested. Check authoritative application state rather than accepting the assistant's claim of success, and keep unavailable outcomes unresolved. The methods belong to simulation and replay, incomplete feedback, and memory evaluation.
Haoran Zhang and colleagues' π-Bench, a May 14, 2026 preprint, separates proactive intent resolution from final completeness across 100 multi-turn tasks. Removing preceding sessions reduced proactivity more than completeness in its three-model ablation. But its users were simulated and experiments shared one adapted scaffold. It supports testing continuity, not a claim of months-long human benefit. Extra clarification turns can reduce human burden, so turn count is not that burden.
Measure sustained usefulness
The unit of benefit is the whole person–assistant workflow. Compare continuing assistance with credible alternatives: ordinary application features, fixed reminders, or an on-demand assistant with a small explicit profile. Memory baselines isolate one component; they do not establish whether proactive work and added supervision improve the whole experience.
Keep a measurement ledger whose categories answer different questions.
- Useful outcomes — Completed commitments, avoided omissions, and results that remain useful after review.
- Human effort — Setup, direct work, repeated explanation, review, correction, duplicated logging, and repair.
- Initiative — Helpful interventions, unwanted interruptions, and useful opportunities the assistant missed.
- Control and privacy — Wrong-account actions, unauthorized commitments, inappropriate disclosures, and failed withdrawal.
- Continued use — Changing needs, reduced use, abandonment, reasons for leaving, and missing follow-up.
Needs can change quickly. Yan Xu and colleagues' From Goals to Actions, reported at CUI 2025, studied 14 participants for two to four weeks around their 2024 resolutions. Initial demand for discovering actions declined after the first week as routines, tracking, and encouragement became more relevant. Incorrect context could reduce relevance without prompting correction. The small, short study does not establish long-term net benefit, but it explains why a successful onboarding experience is an incomplete evaluation.
Similarly, PTIME evaluated preference agreement, reasoning, learning, and perceived usefulness separately. Its 15 participants used invented events in a fake calendar over four weeks. Those results cannot establish real-world time savings. Acceptance and satisfaction are useful observations, but neither substitutes for measured work and consequences.
A within-person comparison observes the same participant under different conditions. It reduces some differences between people, but the periods can still differ in task mix. Novelty can affect early behavior; learned habits can carry into the next condition; benefits and failures may appear only later. People who stop using the assistant must remain in the analysis, with missing follow-up identified rather than counted as success. Live experiment design explains how to choose and interpret the comparison.
Keep privacy and authority failures beside effort outcomes, not inside a score where saved minutes cancel unauthorized actions. Separate unlike outcomes, then use findings to narrow responsibilities, improve context, change notification policy, or remove an unhelpful feature. More autonomous activity is not the objective. Continuing assistance succeeds when the person has less work to manage while retaining meaningful control over what the assistant understands and does.
Open questions
Sustained net benefit remains difficult to establish because needs, task mix, and participation change while setup and repair costs accumulate. Progress would mean months-long comparisons with credible alternatives, complete effort accounting, and follow-up that includes people who leave.
Preference revision must distinguish genuine change from exceptions and choices shaped by the assistant's own suggestions. Progress would combine low-effort correction with tests showing that local edits neither become universal rules nor prevent appropriate adaptation.
End-to-end withdrawal spans credentials, replacement identities, triggers, pending approvals, retained information, and already-started effects. Progress would provide testable cessation contracts and receipts that identify unresolved paths instead of treating one revoked credential as complete offboarding.
Useful initiative must adapt to attention and deadlines without interpreting nonresponse as permission. Progress would measure missed opportunities, repeated nuisance, and human effort together while keeping authorization independent of predicted usefulness.
