Personal Agents

The personal assistance contract

Personal assistance combines automated contributions with direct human control. A model can select a next action as circumstances change; fixed automation follows predefined transitions. The underlying observe–decide–act cycle matters here because a missing reply, ambiguous request, or changed deadline can require a different next step. [1]

In the constructed workflow used here, Mira delegates arranging a 30-minute work meeting with Alex by 10 September. The assistant may inspect specified correspondence and availability, prepare coordination, perform authorized communication, and track responses. Completion requires a confirmed calendar event, the required participants' acceptance, and updated task tracking. Missing information or expired permission returns the affected decision to Mira. [2][3]

Background execution can preserve assistance while a phone is offline; Bee describes a stateful backend for that purpose. Execution location does not establish privacy or authority. The assistance contract still needs to identify permitted information, permitted effects, and when work must wait. [4]

Personal context, preferences, and exceptions

A preference favors a choice under particular circumstances. It helps rank acceptable options; it does not establish permission. PTIME's scheduling examples show why context matters: someone can dislike early meetings yet accept them for a particular relationship. Preserve that condition instead of learning a universal rule from the selected time. [5]

Explicit statements and inferred patterns deserve different treatment. Record the observation behind an inference and keep it correctable: Ario's demonstration inferred a child's school stage incorrectly. Sparse or conflicting evidence warrants a targeted clarification about the current decision, rather than invented certainty about the person. [9]

Accepting a morning meeting can be a one-time exception. Make the future scope of a correction visible, as an application of the Human-AI Interaction guidelines. Persistent changes must reach subsequent reads; Agent Memory explains that lifecycle requirement. [10]

Necessary records and information boundaries

Memory is retained application information made available to later interactions. This assistant needs scoped preferences and their evidence, relevant decisions, unfinished commitments, and references to external records. Conversation history and reusable personal records serve different purposes. Admission and durable writes separate a reason to retain information from evidence that it is accurate. [11]

Data minimization limits information to what an approved purpose requires. Decide separately what may enter model processing, persist, or reach another person. A participant's information needs these boundaries too. Privacy and Data Governance develops the broader lifecycle; a useful task record does not require a copy of every source document. [12]

Freebusy.query returns busy intervals for specified calendars and a bounded interval without event descriptions. Calendar errors mean unavailable coverage, not free time. Availability remains personal information; reading it neither reserves a slot nor authorizes disclosure. [7]

Diagnostic records create another disclosure surface. Retain operation identifiers, outcomes, and necessary diagnostic fields under access and retention controls. Avoid copying access tokens, entire messages, or private calendar contents into logs merely because they helped explain a failure. [13]

Bounded delegation and correct action targets

Delegation assigns work together with bounded authority. Specify the objective, allowed actions, resources, recipients, limits, duration, and revocation route. Distinguish the agent performing an operation from the person it represents and whoever manages it. A task identifier describes the work; it is not the represented person. [14]

Consent here means informed agreement to a specified use or effect. It is not a claim that consent supplies every applicable legal basis. Rights and decision authority distinguish those issues. [15]

Valid standing permission avoids asking again for every covered operation. Adjustable autonomy allocates individual decisions between agent and person, including waiting or transferring control. It chooses among already permitted alternatives. Urgency, a preference, or silence cannot create authority that was never granted. [8][17]

Authentication establishes identity; authorization permits an operation on a resource. OAuth provides delegated application access, with scope describing granted permissions; requested scope may be reduced. Neither login nor a token establishes Mira's intent for a particular message. Apply access and disclosure checks to the resolved operation. [6][18]

Prompt injection attempts to make examined content redirect the model as instructions. An email asking the assistant to expose Mira's calendar is still external content. Keep credentials and enforcement outside that interpretation; AI Security explains the instruction boundary. [20]

Persistent commitments across interactions

A commitment record identifies what remains to be done. For M17, retain its objective and intent version, preference and permission references, due conditions, pending input, external-object references, known effects, and completion or expiry rules. M18 can involve Alex too while remaining a separate commitment. A contact name cannot identify either task reliably. [21][22]

A continuation records the resumption point and pending conditions. It lets work wait without keeping a worker alive; Harness Engineering covers the mechanics. A shared durable session can let Mira return from another device, but resumed work still needs current task state rather than an old conversational summary. [22][23]

Waiting must have an end condition. In the historical Electric Elves deployment, repeated short meeting delays accumulated into substantial nuisance. M17 therefore has a follow-up limit and an expiry condition; neither elapsed time nor repeated reminders establishes completion. [24]

Proactive assistance and attention

Proactive assistance initiates a suggestion or permitted action without a fresh request. Mixed initiative allows both person and system to initiate contributions. Horvitz's framework accounts for uncertain intent, intervention benefit, interruption cost, and deferral. An approaching deadline supplies a trigger, not a decision to interrupt. [1]

Mira's example policy allows quiet preparation and one batched reminder, suppresses dismissed duplicates, and asks immediately only when a necessary decision cannot wait. Quiet periods affect timing, not permission. Missing calendar observations remain unresolved; an invitee's silence does not authorize outreach. [25][24][7]

Look for recurring moments when people stop work to seek help. Tegon's narrated issue-composition assistance uses such context to offer questions in place. That pattern identifies a candidate intervention; its usefulness still depends on timing, relevance, and the person's ability to decline. [26][27]

Reducing interruptions differs from suppressing all information. A two-week smartphone experiment found benefits in reported attention and perceived productivity from three daily notification batches, while eliminating notifications increased reported anxiety and fear of missing out. These findings do not determine an assistant's ideal schedule. [28]

One objective across applications

A system of record is the authoritative application for a particular fact: the mailbox for messages, the calendar for events, and the task application for tracking. M17 links their records. Its summary cannot substitute for checking whether an external object exists or changed. [21]

An integration adapter exposes an application's operations to the assistant. Model Context Protocol offers a reusable interface; locally controlled functions may need only direct calls. Computer Use covers screen-driven interaction. Neither integration route removes the application's state or permission responsibilities. [29][30]

Keep an identity ledger linking M17 to its email evidence, reviewed proposal version, sent message, calendar/event pair, and task reference. In Gmail, saving a draft already writes to the mailbox. Its stable draft ID survives content replacement; sending removes the draft and creates a sent message with a new ID. [31]

Resolve dates and time zones explicitly, recheck availability, and distinguish creating an event from participant acceptance. For existing calendar resources, an ETag identifies a version: an If-Match update can reject an intervening edit with 412 Precondition Failed. Retrieve and assess the changed event before proceeding. This protection does not apply to insertion or make availability-read-then-create atomic. [2][32]

Confirmation of concrete effects

Clarification obtains a missing fact; review evaluates quality; authorization permits an effect. Review and authorization require different decisions. Complete permitted preparation before requesting authority, then bind approval to the inspected proposal and its lifetime. A materially changed proposal needs renewed authorization unless a standing rule independently covers it. [33]

For a separate coordination email, expose its From and reply-to addresses too. A default alias can differ from the login address. A saved draft ID identifies a container, not unchanged reviewed content. The final execution check must preserve the approved account, target, arguments, and scope through callbacks and retries. [19][31][34]

Changed preferences, intent, and permission

A new morning default for future meetings need not change M17 if Mira explicitly preserves its afternoon exception. If the scope is ambiguous, pause affected consequential work and clarify. A correction must influence future retrieval, not merely appear later in a transcript; Agent Memory explains supersession. [11][10]

Late results from earlier work remain evidence, not fresh authority. Record a confirmed send even after permission is revoked, but do not let that result initiate unauthorized follow-up. Changing intent, stopping execution, deleting retained information, and counteracting a completed effect are separate operations. [35][12][36]

Interruption and visible task state

Expose execution state separately from effect knowledge. Preparing, waiting for input, authorized, and dispatching describe work in progress. Confirmed, failed, and outcome unknown describe what is established about an operation. A paused commitment may resume after reassessment; a cancelled commitment has ended, although its earlier effects may still require investigation. [37]

Closing a view can mean lost connectivity rather than an intentional stop. Separate the control request from the connection. A shared session supports return from another device; merely replacing a one-way transport with a bidirectional one does not provide shared task visibility. [38][39]

An effective stop prevents new dispatch and requests cancellation of active operations where supported. Server handlers may need to cooperate; an acknowledgement does not establish termination. Harness Engineering covers observed stopping. Keep the Stop path available even when ordinary work is blocked. [40][41]

A useful return view reports completed effects, unresolved operations, current authority, and the next decision. After an interrupted send, it can show that further dispatch is disabled while delivery remains unresolved. That is actionable progress without a promise of recall. [23][36]

Partial completion and personal recovery

Reconciliation checks recorded intent and observations against authoritative application state. Compensation performs a new action intended to counter an earlier effect. Harness Engineering develops both mechanisms. Separate application writes do not form one atomic transaction, so recovery must track each effect. [42]

A timeout does not establish failure. Repeating an uncertain mutation requires an established receiver-enforced idempotency contract—repetition must not add another effect—or explicit recovery after reconciliation. Merely retaining the same local identifier supplies no such guarantee. [37]

Bound recovery attempts and hand off confirmed effects, unresolved facts, evidence references, restrictions, and safe next steps. Cancellation or a corrective message needs applicable authority. Compensation can fail and cannot erase an earlier disclosure; a remedy must preserve concurrent human work rather than blindly restore an old snapshot. [42]

Personal utility across repeated use

Personal utility concerns completed work relative to the effort and unwanted effects assistance creates. Define the evidence before designing feedback collection. Compare recurring tasks with manual work and simpler reminders under comparable conditions; Evals explains why live observation alone does not establish causal improvement. [43][8]

Include sparse initial context, changed preferences, revocation, duplicate triggers, account confusion, and interrupted operations. Capture post-acceptance edits: an initial yes can conceal extensive correction. An edit can also reflect preference or changed intent, so it is not automatically an error label. [44][45]

Existing studies leave important limits. PTIME's four-week study involved 15 participants scheduling invented events on a fake calendar. The notification experiment measured short-term reported outcomes. Neither establishes sustained net benefit for autonomous coordination across a person's real accounts. [5][28]

Task-specific trust and delegation decisions

Calibrated trust, used operationally here, means reliance appropriate to demonstrated capability and limits for an activity. Useful private drafts do not establish reliable recipient selection. Explanations should connect decisions to applicable preferences, permission, and observed effects; confidence in wording is not external completion evidence. [10][46]

Test whether oversight rejects unsupported suggestions. The seeded-alert study inserted fabricated cheating signals into historical exam reviews and observed some acceptance despite human review. For scheduling, use non-effecting review exercises containing known wrong recipients or times. Measure correction and rejection, not merely approval. This transfers an evaluation method, not a personal-agent failure rate. [47]

After failure, preserve human edits, report uncertainty, and follow through on bounded recovery. Continued reliance needs observable behavior; reassurance alone cannot supply it. Satisfaction and repeated use remain feedback about the experience, not automatic grants of additional authority. [44][17]

Open questions

1. 01

   Reliable correction scope remains difficult: an exception and a lasting change can look similar. Progress would preserve explicitly exempt commitments while updating future decisions, without requiring clarification after every edit. [10][5]

2. 02

   Attention policies need longer evaluation under changing urgency and user control. Short-term notification findings cannot determine when an agent should interrupt. Progress would reduce cumulative nuisance without increasing missed commitments or hiding urgent decisions. [28][24]

3. 03

   Cross-application stopping remains limited by service-specific observation and cancellation contracts. Progress would resolve each in-flight mutation after interruption while preventing duplicate effects and preserving later human edits. [36][32]

4. 04

   Sustained personal benefit requires evidence beyond acceptance and prototype usefulness. Real-task comparisons must include setup, correction, interruption, and recovery while limiting sensitive data collection; improvement must survive those costs and changing task mix. [5][12]