DOT: Digital Chief of Staff (referred to throughout this page as “DOT”) is a personal AI agent whose purpose is to automate the everyday administrative tasks that fill up your week, by creating documents, calendar entries, and emails on your behalf. It combines language-model reasoning with a library of skills that connect to the apps and tools you already use every day, through an open protocol layer called Model Context Protocol (MCP).
Where a conventional chatbot can only converse, this agent acts. Ask it once to handle a recurring obligation — sending a weekly status email to your team, drafting a meeting invite for a client and adding the event to your calendar, putting together a proposal document with the latest project numbers, reminding you to book your physiotherapy appointment, confirming a hotel reservation — and the agent carries out the multi-step workflow end-to-end. It reads the necessary context from your connected services, drafts whatever artefacts are needed (an email, a calendar entry, a Drive document), and either delivers them directly or queues them for your review.
Purpose
DOT: Digital Chief of Staff is an AI agent whose purpose is to automate the everyday administrative tasks that fill up your week, by integrating with the apps and tools you use every day.
The everyday work DOT is designed to take off your plate falls into a few familiar categories. Most weeks, a typical user will lose between three and ten hours to tasks that are necessary but mechanical — drafting the same kind of email to the same kind of recipient, scheduling the same kind of meeting, generating the same kind of document, chasing the same kind of confirmation, summarising the same kind of data into the same kind of weekly report. None of that work is hard, but it consumes time, attention, and willpower, and the cost of it compounds across a month and a year. DOT exists to give that time back.
Concretely, DOT automates everyday tasks across these categories:
- Email — drafting replies to recurring correspondence, sending the same kind of weekly update to the same recipients (status emails, client check-ins, follow-up notes), triaging an inbox and summarising what actually needs attention, and composing enquiry, booking, or confirmation messages on your behalf.
- Calendar — finding time and scheduling meetings, blocking time for focus work, rescheduling around conflicts, creating recurring blocks for workouts or deep-work sessions, and preparing one-page briefs for upcoming meetings.
- Documents — drafting proposals, meeting agendas, project briefs, weekly summaries, training reviews, invoices, and any other recurring document type, using your existing templates and pulling supporting data from your other connected services.
- Bookings and reminders — drafting and sending the request emails needed to book appointments (dentist, physio, hairdresser, car service, restaurant reservation), watching for the reply, and creating the calendar entry once a time is confirmed.
- Health and training — pulling activity, sleep, and recovery data each week, summarising trends, drafting an update to a coach or a personal training log, flagging concerning patterns, and creating a Drive document with the full digest for your records.
- Personal and household admin — sending the regular reminders that keep a household running, drafting routine messages to family or work groups, and surfacing what is coming up in the next seven days so nothing falls through the cracks.
DOT does all of this by sitting between you and the services your work and personal life already live in — Gmail, Google Calendar, Google Drive, Strava, your health and fitness apps, and other tools you add over time. You describe a recurring task once: what kind of email or document or calendar entry should be produced, who should receive it, and what should trigger it (a fixed date, a recurring schedule, an inbound message, or an explicit instruction). The agent owns the execution from then on. When the trigger fires, DOT reads the necessary context from your connected services, drafts the artefact the task requires, and either delivers it on your behalf or queues it for your one-tap approval.
The integration layer that makes this possible is the Model Context Protocol (MCP) — an open protocol that lets a language model securely call defined operations exposed by an external service. The protocol is what gives DOT the bridge it needs to read your calendar, draft your email, and create your documents. It is the difference between an AI that can describe the right action and an AI that can perform it. The protocol is also why the hosting subdomain for this site is mcp.hyani.net — DOT was built on, and around, MCP.
DOT began as a personal experiment to find out how much weekly admin work could be safely delegated to a language model with the right tool access. It quickly became clear that the limit is not the model — current language models are easily capable of drafting a competent status update, a coherent proposal, or a sensible meeting agenda. The limit is integration. A chatbot can write a perfect message but cannot send it; it can describe an ideal calendar entry but cannot create it; it can describe the right document but cannot put it in Drive. The MCP integration layer is what closes that gap, and is the reason DOT can act rather than merely converse.
DOT is designed for individual, personal use — one human delegating their own routine work to one agent, operating against the human's own accounts on connected services. It is not a multi-tenant SaaS, not a data-aggregation product, and not a marketing tool. The relationship is strictly between you, the agent acting on your behalf, and the services you have connected to it.
Design principles
- Acts only when asked. The agent does not initiate work unprompted. Every action it takes is traceable to an explicit one-off instruction or a recurring rule that you defined.
- Drafts first, sends second. For any action with external visibility — sending email, inviting other people to a meeting, sharing a document — the default behaviour is to draft and queue the artefact for your review. Autonomous send is opt-in per workflow.
- Minimum scopes. Each integration is wired through its own MCP server, requesting only the OAuth scopes required for the operations that integration performs. The agent never receives a superset of permissions “just in case”.
- Server isolation. Each MCP server runs in its own process boundary with access only to the credentials and scopes for its own service. Data fetched through the Workspace MCP server is not visible to the Strava MCP server, and vice versa.
- No retention of substantive data. Content fetched from connected services is processed transiently and not stored on the application's servers beyond what is required to return the response to you. The Privacy Policy details the full retention picture.
- You stay in control. Every connected service can be disconnected from its own native settings page (Google Account, Strava, and so on). Revocation is immediate, and the agent has no alternative access path once a connection is revoked.
What the agent does
The agent's core job is to take repetitive work off your plate by producing the actual artefacts that the work requires:
- Creates and sends email — drafts messages in your voice, attaches files where appropriate, and either sends them on your behalf or holds them for your approval.
- Creates calendar entries — finds an available slot, adds the event to your calendar with the right invitees, location, video link, agenda, and description.
- Creates documents — drafts invites, proposals, meeting agendas, briefs, summaries, weekly reports, and short reference documents as Google Docs, optionally sharing them with named recipients.
- Makes bookings — drafts and sends the request emails (or fills out the booking forms) required to reserve appointments, restaurants, or services that operate through standard channels, then creates the calendar entry once a booking is confirmed.
- Sends reminders — schedules nudges for things you have asked it to track, delivered as calendar reminders or follow-up emails at the right time.
- Summarises and surfaces information — pulls together context from email threads, documents, and connected fitness or health platforms to answer questions or generate weekly digests.
About the MCP integration layer
MCP (Model Context Protocol) is the integration layer that connects DOT to third-party applications and systems. It is an open protocol that lets a language model securely call defined operations exposed by an external service — the technical bridge that turns a passive chatbot into an agent that can read your calendar, draft your email, and create your documents.
For each external service DOT supports, a small dedicated MCP server exposes a defined set of operations. A Google Workspace MCP server, for example, exposes operations such as composing and sending Gmail messages, listing and creating Calendar events, and creating or editing Drive documents. DOT invokes those operations using the OAuth credentials you have granted to that specific service, and only those credentials. Adding support for a new service means adding a new MCP server — the core DOT agent does not change, and the new server has no access to any other service's data or credentials.
This design has two consequences worth understanding:
- Each MCP server requests only the OAuth scopes required to perform its declared operations. A Workspace integration that only needs to read and create calendar events asks for calendar scopes — not Gmail or Drive.
- Each MCP server is isolated. Data fetched through the Workspace MCP server is not visible to the Strava MCP server, and vice versa.
What it integrates with
- Google Workspace — Gmail, Calendar, and Drive. Triage and draft messages, schedule events on your behalf, search and reference documents you already own.
- Strava — training history, recent activity details, and performance trends so the assistant can reason about your week of training.
- Health and fitness platforms — workouts, sleep, recovery, and body-metric data from supported trackers and apps.
- And more — additional integrations are added over time as new MCP servers become available, including productivity, finance, and home-automation services.
Purpose for which DOT requests access to your data
To perform the automation tasks described on this page, DOT needs to read and act on data inside the services you choose to connect. Each access request has a single, narrow purpose tied to a specific user-facing feature. This section sets out, for each category of data, the exact purpose DOT has in requesting it — so you can see, and Google can verify, that the access requested is limited to what is required to deliver the user-facing features.
Gmail — read access. Purpose: to locate and read the specific email thread you have referred to (for example, “the email from procurement last Tuesday”) so the agent can ground its drafts and summaries in the actual conversation. Without this access, the agent can describe what an email reply might look like but cannot tailor it to the message you have asked it to work with.
Gmail — compose and send access. Purpose: to create the email drafts you have asked the agent to write, save them to your Gmail drafts folder for review, and (only for workflows where you have explicitly opted in) send them on your behalf. Without this access, the agent can write a message body but cannot produce a real Gmail draft or send a message you have approved.
Google Calendar — read access. Purpose: to find available time, look up events you have referenced (“the call with Sarah next Tuesday”), and check for conflicts before scheduling something new. Without this access, the agent cannot reliably propose a meeting time or pull context for a meeting prep brief.
Google Calendar — write access. Purpose: to create, update, or remove calendar events at your request, including attaching invitees, location, video-conference link, agenda, and description. Without this access, the agent can describe a calendar entry but cannot put it on your calendar.
Google Drive — read access (file metadata and content for files the user explicitly references). Purpose: to open and reference documents you have asked the agent to work with — a brief, a template, a prior proposal, a meeting notes document — so the agent can use your existing materials as input when drafting new artefacts. The application does not request broad Drive scopes; it requests only the access required to read files you have specifically pointed it to or that are shared with the workflow you set up.
Google Drive — create and edit access. Purpose: to write out the documents the agent has drafted on your behalf (proposals, meeting invites, agendas, summaries, weekly digests, training reviews) and place them in your Drive so you can find, edit, and share them. Without this access, the agent can describe a document but cannot deliver one.
Strava — activity read access. Purpose: to pull your recent training data when you have asked the agent to summarise a week, draft an email update to a coach, generate a recovery review, or plan workouts around your activity history. Without this access, the agent has no source data for training-related workflows.
Health and fitness platforms — metric read access. Purpose: to pull workout, sleep, recovery, and body-metric data when you have asked the agent to surface trends, generate a weekly health review, or flag concerning patterns. Read-only; the agent does not write health data back to these platforms.
Scope minimisation as a rule. The same principle applies across every integration: the agent requests the narrowest scope that lets it perform the operations you have explicitly enabled, and nothing wider. Workflows that only need calendar read do not trigger a calendar write request. Workflows that only need to draft email (never autosend) can be configured to request only the compose scope. Any future integration is wired the same way — one MCP server per service, with declared operations and minimum scopes.
What DOT does not request. DOT does not request access it does not need for a declared user-facing feature. It does not ask for full-Drive enumeration when a single file reference is sufficient. It does not ask for the entire Gmail mailbox when a single thread reference is sufficient. It does not ask for “profile” or “contacts” scopes that do not contribute to a workflow the user set up.
How it works
You describe what you want in plain language. The assistant chooses the matching skill, calls the underlying MCP server, and reports back with the result — or asks a clarifying question if needed. Each connector requests only the OAuth scopes it needs to fulfil the task, and you can revoke access at any time from the originating platform. For Google Workspace integrations, that's the Third-party apps with account access section of your Google Account settings.
Example tasks
Single instructions that produce concrete artefacts:
- “Draft a proposal in Drive for the client meeting on Tuesday — use last month's invoice as the template and pull the relevant pricing from the email thread with their procurement team.”
- “Send the weekly status update to my team. Pull progress from my calendar and the project doc in Drive, draft the email in my voice, and hold it for my review before sending.”
- “Create a calendar invite for a 30-minute intro call with the new contractor next Wednesday morning, attach the project brief from Drive, and send the invite.”
- “Book the next available appointment with my usual physiotherapist by email, then add it to my calendar once they confirm.”
- “Draft a meeting agenda for tomorrow's project review as a new Drive document, share it with the attendees, and link it from the calendar event.”
- “Summarise my sleep and recovery for the past 14 days, flag any concerning trends, and put the summary in a new Drive document called ‘Weekly Health Review’.”
Scheduled, recurring workflows
The agent is designed for tasks that repeat. You describe the pattern once and the agent carries it out on schedule, producing the artefacts each time:
- Weekly status email — every Friday afternoon, pull updates from this week's calendar and a project document in Drive, draft the team email, and hold it for review.
- Meeting prep brief — the morning of each external meeting, draft a one-page brief in Drive with the attendee's background, recent email thread, and discussion points, and link it from the calendar event.
- Training digest — every Sunday evening, pull the week's activities from Strava, summarise the load, draft an email to a coach, and create a Drive document with the long-form summary.
- Proposal and invoice drafts — at the end of each project phase, draft a proposal document and an invoice in Drive based on templates you provided, and email them to the client.
- Booking reminders — when a quarterly appointment (dentist, physio, car service) is due, draft and send the booking request email; once a confirmation arrives, create the calendar event automatically.
- Health and recovery flags — review sleep and recovery data weekly and email any concerning trends, optionally creating a follow-up calendar entry.
How your data is used
Data retrieved from connected services through DOT: Digital Chief of Staff (via the MCP integration layer) is used only to fulfil the request you made. It is not transferred to third parties, not used to train language models, not used to serve advertising, and not sold. DOT: Digital Chief of Staff's use and transfer to any other application of information received from Google APIs adheres to Google's API Services User Data Policy, including the Limited Use requirements. See the Privacy Policy for details on what is logged, retained, and how to exercise your rights, and the Terms & Conditions for the rules governing use of this service.
Who it's for
Individuals who want a single conversational interface for the work and personal services they already use, without context-switching between a dozen apps. DOT is a personal-use desktop tool; access is granted per user account through the standard OAuth consent flow of each connected service.
Contact
For questions about the application, this page, or to request information about data associated with your account, write to: roryhw [at] gmail [dot] com.