Skip to main content

Virtual private assistant

Helpful is not the same as authorized.

A virtual private assistant can turn requests about calendars, tasks, documents and messages into reviewable plans within a user's active delegation. It checks the relevant accounts and current state, then previews the people and consequences affected. Users approve consequential commitments and can correct priorities or revoke access. Reminders and provider receipts remain separate from evidence that the underlying work is complete.

Preview the scope of delegated work

Bind requests to the initiating user, represented person or purpose, tenant, session and active delegation. Retrieve only the fields needed for the current task and disclose when software acts on someone's behalf. Familiarity, shared names and conversational history cannot establish identity or authority.

Clarify ambiguous dates, recurrence, time zones, recipients, travel, focus time, priorities and dependencies. A preview names exact accounts, calendars, attendees, changed fields and downstream effects. Consequential commitments, cancellations, destructive changes, sensitive messages and broad sharing require fresh approval.

Make partial results and revocation visible

At commitment, recheck current source versions, organizer authority, field permissions, attendee state, recurrence instance and idempotency. Delegated credentials stay outside model context with limited scope and lifetime. Retrieved content is evidence, not an instruction source.

Reminders may be scheduled, sent, received where reliably known, acknowledged, snoozed, escalated or canceled without proving task completion. Preserve partial or delayed provider effects, let users cancel pending work and revoke delegation, and supersede plans when accounts, preferences, identities or permissions change.

Assistant boundary

Organize the work without inheriting the whole account.

Personal context makes an assistant useful and dangerous at the same time. Four boundaries keep access, interpretation, action and outcome separate.

01

User identity, delegation, and working context

Resolve the initiating user, represented person, tenant, session and approved account; disclose on-behalf-of behavior; select the minimum source fields and time window; apply role, purpose, action, consequence, device, location and expiry limits; and block work when delegation is missing, stale or revoked.

Required evidence: User and representative identifiers, tenant and session, account and source, delegation grant and basis, role, purpose, read and write scopes, field and resource limits, action tier, consequence class, device and location risk, effective and expiry times, revocation, step-up requirement, reviewer and denied request.

02

Calendar, task, contact, and preference truth

Read current events, free/busy, tasks, contacts and preferences from their owners; preserve versions, time zones, recurrence, organizer, attendee, status, due, dependency and visibility fields; distinguish assertions from verified state; and surface conflicts, ambiguity and stale data.

Required evidence: Source identifier and version, calendar and task-list owner, event or task UID, sequence and recurrence instance, start, end, due and time zone, organizer, attendee, delegation and reply state, contact match and basis, preference version, visibility, dependency, conflict, freshness, denied field and uncertainty.

03

Typed plan, preview, and approval

Convert the request into read, draft, propose, commit, change, cancel or remind candidates; preserve the original request and assumptions; validate people, dates, recurrence, conflicts, destinations and consequences; show exact proposed writes; and obtain the approval required for the action tier.

Required evidence: Original request, parsed intent, candidate action type, target account and object, proposed field diff, recipients, date and time-zone interpretation, recurrence scope, conflict and travel checks, alternative, uncertainty, prohibited action, consequence tier, approval prompt, approver, accepted scope, expiry and rejected candidate.

04

Commit, remind, reconcile, and recover

Recheck identity, delegation and source state at commit; write once with bounded credentials; preserve provider and internal receipts; separate event, attendee, task and reminder states; route partial failure; support correction, cancellation and manual recovery; and stop pending work when access or context changes.

Required evidence: Precondition and permission result, credential role, destination and field map, idempotency key, request and response identifiers, committed version, organizer update, attendee reply, task and reminder state, queued, sent, failed and acknowledged events, partial result, reconciliation, correction, cancellation, rollback, revocation and incident.

Request-to-receipt path

Recheck authority where conversation becomes action.

An approved integration is not blanket permission. Each stage narrows the request until one exact write can be understood, authorized and recovered.

  1. 01

    Bind the request

    Capture the exact user request, initiating identity, represented person, tenant, purpose and session; classify the desired read, draft or write; resolve consequence; and identify missing delegation or step-up requirements before retrieving personal context.

    Owner
    User, identity and assistant-policy owners
    Evidence
    Request, user and representative, tenant, session, purpose, action candidate, consequence tier, delegation, scope, expiry, device risk, step-up and blocked state.
  2. 02

    Read the minimum current state

    Retrieve only approved calendars, tasks, contacts, preferences and messages and only required fields; preserve source versions; resolve organizer, attendee, time-zone, recurrence and task status; and expose conflicts, stale copies, ambiguity and denied context.

    Owner
    Calendar, task, contact and data owners
    Evidence
    Source, resource and field scope, object identifier, version, time zone, recurrence, organizer, attendee, task and contact state, freshness, conflict, ambiguity and access denial.
  3. 03

    Prepare an inspectable plan

    Generate typed action candidates with exact field diffs, assumptions, recipients and alternatives; apply deterministic time, recurrence, conflict, destination and consequence checks; and present a preview that reveals every affected account and person.

    Owner
    Assistant, scheduling and workflow owners
    Evidence
    Candidate type, target, field diff, assumptions, alternative, source links, date and time-zone parsing, recurrence instance, recipients, conflict, consequence, approval requirement and rejected option.
  4. 04

    Approve and commit once

    Obtain fresh approval where required, verify the approver and accepted scope, re-read current source state, validate delegation and destination, use bounded credentials and an idempotency key and preserve the exact committed request, response and resulting version.

    Owner
    User, represented person, system and security owners
    Evidence
    Approval, approver, scope and expiry, step-up result, preconditions, source version, delegated credential role, destination, idempotency key, request, response, committed object and failure.
  5. 05

    Reconcile and maintain

    Track organizer and attendee updates, task and reminder states, provider failures and conflicts; tell the user what happened; route exceptions; support correction, cancellation and rollback; and revoke pending work when delegation, identity, source state or preference changes.

    Owner
    Operations, assistant and correction owners
    Evidence
    Provider and internal state, attendee reply, reminder event, acknowledgment, task completion evidence, mismatch, exception owner, user notice, correction, cancellation, rollback, revocation and incident review.

Authority map

Separate calendar mechanics, language help, and personal authority.

A model can interpret a request and draft a plan. It cannot grant itself access, decide what someone meant by next Friday or commit another person's time.

01

Deterministic assistant software

Software owns identity binding, delegated scopes, resource and field permissions, calendar and task object semantics, time and recurrence calculation, validation, consequence tiers, approvals, idempotency, provider reconciliation, retention, audit, revocation and recovery.

  • User, representative, tenant, session, account and object identity
  • Scope, field, action, time, recurrence, attendee and destination rules
  • Preview, approval, precondition, idempotency and commit state
  • Reminder, provider, correction, cancellation, revocation and recovery receipts
02

Bounded AI assistance

AI can interpret intent and propose priorities, dates, attendees, messages and plans from allowed context, but every person match, temporal phrase, preference, conflict, task, write and outcome remains untrusted until checked or accepted.

  • Intent, entity, contact, date, time-zone and recurrence candidates
  • Schedule alternatives, priority suggestions and task decomposition
  • Draft invitations, reminders, checklists and bounded messages
  • Conflict, missing-context, sensitive-intent and exception candidates
03

User and domain authority

People own delegation, personal preferences, ambiguous intent, external commitments, sensitive context, cancellations, priorities, assignments, deadlines, exceptions, corrections and every expansion of automated action.

  • Delegation, represented-person and on-behalf-of authority
  • Ambiguous contact, time, recurrence, location and availability decisions
  • External invitation, cancellation, assignment, deadline and message approval
  • Sensitive action, correction, credential revocation, incident and stop authority

Private-assistant components

Build around scoped actions, not a master password.

Identity, calendars, tasks and personal preferences change independently. Four components keep the assistant useful without hiding delegated power.

01

Identity, delegation, and consequence registry

Version users, represented people, tenants, sessions, accounts, resources, fields, purposes, read and write actions, consequence tiers, approval rules, step-up requirements, effective and expiry times, device and location constraints, revocation and emergency stop state.

Operating contract: Logged in is not authorized for every account, integration grant is not blanket business authority, familiar conversation is not delegation, read scope is not write scope, old approval is not fresh consent and credentials must not become model context.

02

Calendar, task, contact, and preference mirror

Preserve source-owned identifiers, versions, free/busy, event, to-do, organizer, attendee, sent-by, delegation, reply, sequence, recurrence, start, end, due, time zone, task, contact, channel, visibility and preference state with freshness and access boundaries.

Operating contract: Free is not available, event is not attendance, organizer is not attendee, attendee is not accepted, delegated is not additional, date is not time zone, recurring series is not one occurrence, contact name is not identity and cached preference is not current policy.

03

Plan, preview, and approval ledger

Retain original requests, interpreted intents, source links, candidates, assumptions, alternatives, date and contact ambiguity, exact field diffs, recipients, conflicts, consequence, approval prompts, approvers, accepted scope, expiry, rejection and unresolved state.

Operating contract: Model confidence is not certainty, plausible date is not confirmed time, priority suggestion is not user choice, draft is not sent, approval of one diff is not authority for a changed diff and a plan that hides recipients or downstream effects is not reviewable.

04

Action, reminder, and recovery ledger

Validate preconditions and destinations; commit authorized writes once; preserve request, provider response and resulting versions; distinguish organizer, attendee, task and reminder states; reconcile partial failure; and support correction, cancellation, rollback, revocation and manual completion.

Operating contract: Accepted API call is not completed intention, invitation sent is not attendance, reminder sent is not acknowledged, acknowledged is not done, task closed is not outcome proof, retry is not safe without idempotency and revoked access must stop queued as well as new work.

Delivery path

Prove one administrative loop before connecting a life.

Broad account access hides which action creates value and which permission creates risk. Begin with one repeatable loop and a narrow data surface.

  1. 01

    Observe current assistant work

    Trace requests, account access, calendar and task reads, contact lookup, scheduling, reminders, messages, approvals, corrections, cancellations, provider failures, recovery, staff effort, operating cost, mistakes and known harm using authorized records.

  2. 02

    Define the delegated-action contract

    Name user, representative, tenant, account, resource, field, event, task, contact, preference, intent, plan, approval, write, attendee, reminder, outcome, exception, correction, revocation, cost and harm states and owners.

  3. 03

    Run in shadow

    Replay ambiguous names, relative dates, daylight shifts, recurring events, organizer changes, delegated attendance, private events, conflicting calendars, stale tasks, sensitive messages, prompt injection, provider delay, partial failure, duplicate requests, cancellation and revocation without writing externally.

  4. 04

    Release one controlled action

    Limit users, accounts, fields, action type, consequence and destination; require previews and fresh approvals; keep tokens outside model context; validate source versions and recipients; test idempotency, partial failure, correction, cancellation, rollback, revocation and independent stop authority.

  5. 05

    Review after real outcomes

    Compare correct interpretations, approved actions, attendee and task outcomes, reminder acknowledgment, duplicate and failed writes, correction reach, user effort, provider and operating cost, incidents and harm with the baseline before adding accounts, actions, users or automatic commits.

Assistant safeguards

Six controls before convenience can write to an account.

The strongest controls keep delegation narrow, previews exact, credentials isolated and failures recoverable.

Explicit identity, delegation, scope, and expiry
Bind each request to user, represented person, tenant, session and purpose; separate accounts, resources, fields, reads, drafts and writes; classify consequence; disclose on-behalf-of actions; require step-up where appropriate; expire grants; log denials; and stop queued work after revocation.
Current source state and exact time semantics
Read current source versions at the action boundary; preserve UIDs, sequence, organizer, attendee, task and recurrence state; carry named time zones; handle daylight shifts, all-day events, exclusions and single-instance changes; distinguish assertions from system truth; and expose stale or conflicting copies.
Typed intent, deterministic checks, and complete preview
Convert language into a fixed action schema; treat retrieved content as data, not instructions; validate contact identity, dates, recurrence, conflicts, travel, destinations, recipients and prohibited actions; display exact field diffs, alternatives and uncertainty; and require clarification instead of filling consequential gaps.
Consequence-based approval and bounded credentials
Keep external commitments, cancellations, sensitive messages, broad sharing, destructive changes and regulated or financial work behind fresh authorized approval; bind approval to the exact diff and expiry; use the narrowest practical delegated credential; protect redirect and token flows; and never expose secrets to model context or logs.
Idempotent commit, receipt, and outcome reconciliation
Recheck preconditions immediately before writing, validate destination and field permissions, use stable idempotency and correlation, preserve provider request and response, distinguish accepted, delivered, acknowledged and completed states, route partial failure and reconcile the final event, attendee, task or reminder record.
Correction, cancellation, recovery, and stop authority
Let users inspect history, correct preferences and records, cancel pending work, withdraw messages where supported, revoke access and recover manually; preserve original and corrected versions; test export, rollback and restore; and let independent owners suspend an action, account, provider, user or the entire assistant.

Outcome proof

Measure accepted work, not assistant activity.

More events, tasks and reminders can create more cleanup. Proof follows the user's intent through exact effects and recoverable outcomes.

Baseline

  • Administrative work by user, represented person, purpose, account, resource, field, action, consequence, calendar, event, attendee, recurrence, task, contact, reminder, message, approval, provider, outcome, correction, cancellation, revocation, cost and known harm
  • Evidence by identity, delegation, scope and expiry, source identifiers and versions, organizer and attendee state, time zone and recurrence, original request, typed plan, exact diff, alternative and uncertainty, approval, precondition, idempotency, provider receipt, final state, correction and revocation
  • User, assistant, administrator, privacy, security, records, accessibility and support effort; clarification, duplicate entry, conflict repair, chasing, access management, provider fees, interruption, recovery and operating cost
  • Wrong user, account, object, contact, recipient, time, time zone, recurrence, organizer, attendee, task, priority, due date, channel, message, destination, permission, approval, reminder or outcome; duplicate write, data exposure, missed revocation, incident and harm

Outcome evidence

  • More bounded scheduling, task and reminder work reaches a current source-backed, explicitly authorized and attributable state with exact previews, committed receipts and visible follow-up
  • Fewer ambiguous contacts, wrong time zones, recurrence mistakes, double bookings, silent assignments, duplicate writes, exposed credentials, misplaced messages, stale reminders and unreconciled provider failures reach users or other people
  • Users receive smaller decision packets with assumptions, alternatives, conflicts, affected accounts, recipients and consequences visible while retaining delegation, approval, correction, cancellation, revocation and stop authority
  • Comparable cycles expose performance by user, action type, consequence, calendar condition, provider and outcome without assuming scheduling accuracy, reminder delivery, task completion, time saving, productivity or cost reduction

Guardrails

  • User, represented person, tenant, account, resource, field, event, attendee, task, contact, message or destination is misbound; credentials enter model context; or private, confidential, personal or regulated data crosses purpose, role, tenant, provider or jurisdiction boundaries
  • OAuth grant appears business authority, free appears available, name appears identity, date appears time zone, calendar event appears attendance, task assignment appears acceptance, reminder sent appears acknowledged or provider success appears completed outcome
  • The assistant broadens scope, obeys injected content, invents dates or contacts, hides recipients, commits changed diffs under old approval, creates material promises, retries unsafe writes, exposes secrets, suppresses partial failure or continues after revocation
  • Model, provider or calendar semantics change without evaluation, daylight or recurrence cases remain untested, corrections and cancellations do not reach recipients, credentials cannot be revoked, restore loses receipts, manual recovery fails, stop authority fails or expansion precedes measured harm review

Private-assistant fit

Use this pattern when delegation can be made explicit.

Good reason to begin

  • The organization can bound one administrative loop, user group, account set, data fields, actions, consequence tiers and destinations and name identity, delegation, calendar, task, privacy, security, records, accessibility, approval, correction, recovery, cost, harm and stop owners.
  • Users, representatives, accounts, resources, events, attendees, tasks, contacts, plans, approvals, writes, reminders and outcomes retain stable identifiers, timestamps and versions; source state reopens; provider receipts export; and revocation reaches queued and future work.
  • Representative ambiguous-contact, relative-date, daylight, recurrence, organizer-change, private-event, conflict, stale-task, sensitive-message, injected-content, provider-delay, partial-failure, duplicate, cancellation and revocation cases plus approved outcomes exist for shadow evaluation.
  • Users can correct interpretations, reject plans, narrow delegation, cancel actions, revoke credentials and recover manually, while administrators can inspect evidence, disable destinations, stop providers and retire the assistant safely.

Resolve before beginning

  • User and represented-person identity, delegation, accounts, source authority, time-zone policy, action tiers, approvals, destinations, credential custody, correction, cancellation, recovery, incident or stop ownership is unclear or disputed.
  • Source objects lack stable identifiers and versions, calendar and task state is duplicated, contacts cannot be distinguished, recurrence is flattened, provider writes cannot be reconciled, scopes are broad, tokens reach prompts or revocation does not stop queued work.
  • The desired first release permits open-ended account search, silent on-behalf-of action, model-selected recipients, automatic external commitments, unapproved cancellation, broad message access, credential exposure, money movement, regulated decisions or hidden retries.
  • The business case depends on guaranteed availability, universal calendar interoperability, perfect intent or contact resolution, unrestricted personal context, immediate autonomous action, lower headcount, time savings, productivity, cost reduction or another unmeasured outcome.

Source basis

Sources behind the control model.

  • 01

    Internet Engineering Task Force

    RFC 5545, Internet Calendaring and Scheduling Core Object Specification

    RFC 5545 is a Proposed Standard defining the iCalendar format for events, to-dos, journal entries and free/busy information. It specifies identifiers, dates, time zones, recurrence and related object semantics and has several listed updates. Format conformance does not prove a person's identity, availability, delegation, acceptance, task completion or business authority.

  • 02

    Internet Engineering Task Force

    RFC 5546, iCalendar Transport-Independent Interoperability Protocol

    RFC 5546 is a Proposed Standard for publishing, scheduling, rescheduling, responding, negotiating changes and cancellation across calendar systems. It distinguishes organizer and attendee state, supports delegation and sent-by behavior and versions changes. It does not authorize an assistant, prove recipient identity, acceptance, attendance, task ownership or completion and does not define a specific transport.

  • 03

    Internet Engineering Task Force

    RFC 9700, Best Current Practice for OAuth 2.0 Security

    RFC 9700, published in January 2025 as BCP 240, updates OAuth 2.0 security guidance using practical attack experience, including redirect protection, PKCE, CSRF defense, issuer mix-up controls, token replay protection and safer client authentication. It is an API authorization security BCP, not proof of business delegation, least-privilege scope design, identity, privacy compliance or safe assistant behavior.

  • 04

    National Institute of Standards and Technology

    Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

    NIST AI 600-1, published 26 July 2024, is a voluntary cross-sectoral profile addressing confabulation, human-AI configuration, privacy, information integrity, provenance, evaluation and monitoring. It does not define calendaring semantics, grant tool authority, certify an assistant or prove that an interpreted request, proposed plan or completed API call matches the user's intent.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Explore governed agent patterns

Compare a private assistant with other evidence-led agents before selecting one user group, account surface and action boundary.

Open path02

Carry confirmed meeting follow-up

Turn source-linked meeting decisions and accepted assignments into bounded calendar, task and reminder work without reinterpreting the record.

Open path03

Design accountable administrative workflows

Connect authorized triggers, current system state, guarded writes, owned exceptions, reconciliation and recovery across routine work.

Open path04

Coordinate approved communications

Keep recipient, purpose, preference, channel delivery, reply, correction and suppression explicit when an assistant drafts or sends a bounded message.

Open path