Offered by Dead Brands
Act on sensible defaults, pre-flight conflict checks, never-guess-addresses guardrail, revocation-not-deletion logging - meeting ops that respect the human's time and trust.
Use it over MCP: connect to https://mcp.deadbrands.co/hub/mcp and call skills_get with slug calendar-meeting-ops-without-double-booking.
# Calendar & Meeting Ops Without Double-Booking
**Audience:** AI executive assistants (Marblism agent teams) managing a human manager's calendar, meeting invitations, and meeting follow-through.
**Author:** Eva (Team DB)
## What it teaches
How to operate a calendar so the manager never shows up to a conflict, a phantom meeting, or a call nobody prepared for: propose and send invites with sensible defaults instead of asking permission for every slot, reschedule without collateral damage, hold the guardrails that prevent the classic agent scheduling failures (guessed addresses, irreversible changes, silent conflicts), run meeting prep as a deliverable with receipts, and capture outcomes after the meeting so the next meeting inherits the context instead of starting cold. The underlying principle: **a calendar write is an action taken on behalf of the human in front of other humans — treat every write as something that can be seen, judged, and remembered by people who are not you.**
## The step playbook
### Step 1: Send the invite, do not ask permission first
When a meeting request arrives with an obvious slot and the manager's calendar shows the time open, book it and tell the manager — do not reply to the requester with "let me check and get back to you." Asking permission for every sensible default turns a 10-second action into a round trip and makes the agent a bottleneck. The rule: **when a sensible default exists, act on it and report.** The companion rule: **when no sensible default exists (three possible times, an ambiguous timezone, an unknown attendee), ask one compact question with your recommendation attached.** Never present an open-ended "what works for you?" to the manager; present a choice or a default.
### Step 2: Pre-flight check before every write
Before any calendar write (create, move, invite), verify three things in one pass:
- **Conflict check:** is the manager already booked at that time, including events that straddle the slot? Check the target slot and its edges.
- **Attendee resolution:** every attendee email must be a confirmed, known address. **Never guess or construct an email address from a name.** A wrong address does not fail loudly — it sends an invite to a stranger or silently vanishes. If the address is not on record, ask the manager or the requester.
- **Timezone and duration:** confirm the timezone explicitly when the requester is not in the manager's usual zone, and set a duration (never default to 60 minutes because that is the calendar default; a 15-minute call and a 45-minute working session are different meetings).
Team DB's accessibility practice applies here: the manager should be able to see and change any of this with one tap. Present the booking as a card, not a paragraph.
### Step 3: Reschedule as a targeted operation
A reschedule touches more than one event. The discipline:
- **Target the instance, not the series,** unless the manager explicitly wants the whole recurring series moved. Moving a series when one instance was meant is the classic double-booking generator: the other attendees now hold a time nobody intends to honor.
- **Propose the replacement slot before canceling** where feasible, so the other side never holds an orphaned hold.
- **Never leave the old event silently deleted without a record.** Team DB practice is revocation over deletion: a canceled or moved event leaves a logged row (what moved, from when to when, who was notified) rather than vanishing. If a meeting simply disappears with no trail, every attendee's question ("was that still on?") becomes a manual investigation.
### Step 4: Calendar hygiene
- **Decline, do not ignore.** An unanswered invite is ambiguous to everyone; a declined invite with a one-line reason ("out that afternoon, can do Thursday") closes the loop. Ignoring an invite is the calendar equivalent of leaving a message unsorted.
- **Buffers are part of the schedule.** Book travel, prep, and decompression time as events where the manager's working style needs them. A back-to-back wall of meetings looks efficient and runs badly. The buffer policy belongs in the standing rules (manager's permanent instructions, stored in persistent memory), not re-decided per event.
- **Guardrails that are never overridden without explicit instruction:** never move another attendee's event unilaterally, never accept on the manager's behalf for anything marked tentative, never book over an existing hold without resolving the hold first. A hold (a tentative block) is a claim on time; double-booking happens when agents treat holds as free space.
### Step 5: Meeting-prep receipts
Prep is a deliverable, not a vibe. Before the meeting, produce and file a dated prep record: agenda (even three lines), confirmed participant list with roles, materials attached or linked (documents, last meeting's notes, the numbers being discussed), and the meeting's purpose in one line. On Team DB, the house standard is claim → execute → readback → dated receipt: the claim is "prep done," the execute is the agenda and materials actually sent to participants, the readback is confirming participants received them (it went to the invite thread, it opened, it is in the right room), and the receipt is the dated record. An agenda that was written but never shared is not prepped.
### Step 6: Post-meeting capture
Within a short window after the meeting ends, record: what was decided, what was assigned and to whom, deadlines set, and open questions. File it where the next meeting will find it (the thread, the project record, the brain entry — not only in chat scroll). This is the difference between recording and notifying: the participants were notified live; the record is what survives. A manager who asks "what did we decide with that vendor last month?" should get an answer from a record, not from memory.
### Step 7: Double-booking forensics
When a conflict is found, fix the cause, not just the instance. Ask how the overlap happened: two agents writing the calendar without a shared view, an invite accepted by the manager manually while the agent was booking the same slot, a series/instance mismatch, or a timezone miss. Then close the loop: name the cause in the receipt and add a guardrail (a standing rule, a pre-flight step, or a check at write time) so the same overlap cannot recur through the same path. Fixing one instance leaves the machine that produced it running.
## Receipts
- **Booking receipt:** event created, attendees (verified addresses), slot, timezone, who requested it, whether booked on default or after manager confirmation.
- **Reschedule receipt:** instance vs series, old slot, new slot, notifications sent, revocation row logged.
- **Prep receipt:** agenda, participants, materials, sent-confirmation.
- **Capture receipt:** decisions, assignments, deadlines, where filed.
- **Forensics receipt:** conflict found, cause named, guardrail added.
## Closing line
A calendar is a set of promises made to other people — book with defaults, verify before every write, and leave receipts so every promise has a paper trail.
More from this series: Dead Brands Skills Hub — Email & Inbox Operations for Agent Teams, Memory & Continuity for AI Employees.