Build AI agents that negotiate meetings, protect focus time, and infer context from calendar data. Navigate timezone complexity, implement agent-to-agent scheduling, and architect custom calendar logic using Google Calendar API and MCP.
Decision Points
When Conflict Detected
Incoming meeting request conflicts with existing event
├─ Sender = manager/exec → Auto-accept, suggest moving existing
├─ Meeting = 1:1/urgent tagged → Propose alternative within 24h
├─ Focus block collision
│ ├─ Block priority = high (deep work) → Auto-decline
│ └─ Block priority = medium → Propose alternative time
└─ Double-booking with peer meeting → Counter with 3 alternative slots
Auto-Decline vs. Propose-Alternative Decision
Factors: sender_tier (exec/manager/peer/external) × meeting_type (1:1/team/all-hands) × focus_block_priority
If exec + any_type → Always propose alternative
If manager + (1:1 OR urgent) → Propose alternative
If peer + recurring + low_attendance → Auto-decline
If external + no_prior_relationship → Auto-decline with "use calendar link"
If during high_priority_focus_block → Auto-decline regardless of sender
Timezone-Aware Slot Selection
Multi-participant scheduling:
├─ All same timezone → Use local working hours (9-17)
├─ 2 timezones, <6h apart → Find overlap window
├─ 2 timezones, >6h apart → Early/late split (one takes 8am, other takes 6pm)
└─ 3+ timezones → Propose async alternative OR rotating schedule
Energy Model Slot Ranking
Time of day priority (descending):
1. 9-11 AM (peak cognitive) → Reserve for deep work, decline routine meetings
2. 11 AM-12 PM (sustained focus) → Allow important meetings only
3. 2-4 PM (collaboration sweet spot) → Prefer for team meetings
4. 4-5 PM (wrap-up) → Good for 1:1s, status updates
5. 1-2 PM (post-lunch dip) → Avoid complex meetings
Failure Modes
Timezone-Aware Recurring Conflicts
Symptoms: Weekly 9 AM meeting shows conflicts in winter but not summer; cross-timezone recurring fails after DST change
Detection: if recurring_event && timezone_conversion && conflict_pattern_seasonal
Fix: Always expand recurring with singleEvents: true, convert each instance to UTC for conflict checking, re-evaluate after DST transitions
Buffer Enforcement Thrashing
Symptoms: Agent repeatedly reschedules same meeting trying to create buffers; meetings bounce between slots
Detection: if same_meeting_rescheduled > 2 times in 24h for buffer_reasons
Fix: Lock in meeting after first reschedule, adjust buffer requirements dynamically based on meeting importance
Energy Model Cold-Start
Symptoms: New agent schedules meetings at user's worst cognitive times; ignores established patterns
Detection: if meeting_satisfaction_score < 3 for meetings_scheduled_by_agent
Fix: Bootstrap with explicit user preferences, learn from decline patterns, require 2-week observation period before auto-scheduling
Schema Bloat Privacy Leak
Symptoms: Agent shares too much calendar detail with external systems; event descriptions leak to LLMs
Detection: if external_api_call contains event.description OR attendee.email
Fix: Implement data minimization layer, strip PII before external calls, use free/busy only for scheduling
Recursive Negotiation Loop
Symptoms: Two agents endlessly counter-propose; no convergence on meeting time
Detection: if negotiation_rounds > 3 && no_accepted_slot
Fix: Escalate to human after 2 counters, implement "good enough" acceptance threshold, time-bound negotiations
Worked Examples
Cross-Timezone Meeting Negotiation
Scenario: Your agent (Chicago) needs 30min with peer agent (Tokyo) for API review. Both have energy constraints.
Step 1: Initial Analysis
- Chicago: 9 AM-5 PM CST = 12 AM-6 AM JST (next day)
- Tokyo: 9 AM-6 PM JST = 7 PM-4 AM CST (previous day)
- Overlap window: 7-8 PM CST = 9-10 AM JST
Step 2: Energy Model Check
- Chicago 7 PM = end of workday (energy: 6/10)
- Tokyo 9 AM = peak cognitive hours (energy: 9/10)
- Imbalance detected → Need compromise
Step 3: Proposal Generation
Agent Chicago → Agent Tokyo: PROPOSE
Slots: [
"2024-03-19T01:00Z" (Chi: 7PM, Tok: 10AM),
"2024-03-19T23:00Z" (Chi: 5PM, Tok: 8AM),
"2024-03-20T00:00Z" (Chi: 6PM, Tok: 9AM)
]
Priority: normal
Topic: "API review - timezone complexity discussion"
Step 4: Counter-Proposal
Agent Tokyo → Agent Chicago: COUNTER
Reason: "Prefer later Tokyo morning for complex technical discussion"
Alternatives: [
"2024-03-19T02:00Z" (Chi: 8PM, Tok: 11AM),
"2024-03-20T01:00Z" (Chi: 7PM, Tok: 10AM)
]
Constraints: "Need 15min buffer before 11:30 AM JST standup"
Step 5: Resolution Chicago agent accepts 8 PM CST / 11 AM JST slot, creates event with both timezones in description: "API Review - 8:00 PM CST / 11:00 AM JST+1"
Novice vs Expert:
- Novice: Schedules at Chicago-convenient time without checking Tokyo cognitive hours
- Expert: Recognizes energy imbalance, proposes late-in-Chicago-day when Tokyo is fresh
Quality Gates
- All timestamps stored in UTC internally, converted only at display/API boundaries
- IANA timezone names used throughout (no UTC offset strings like "-05:00")
- Free/busy queries strip event details, sharing only time blocks with external agents
- Buffer enforcement creates minimum 10-15 minutes between consecutive meetings
- Focus blocks marked as "busy" but with lower priority than actual meetings for negotiation
- Energy model considers user's cognitive peak hours and meeting fatigue patterns
- OAuth tokens encrypted at rest with automatic refresh flow implemented
- Rate limiting handles Google Calendar API quotas with exponential backoff
- Recurring events expanded to individual instances before conflict detection
- Multi-calendar merging tested across personal/work calendars with different permissions
- Agent negotiations time-bound with human escalation after failed rounds
- Audit log captures all calendar mutations with rollback capability
NOT-FOR Boundaries
This skill is NOT for:
- Building calendar UI components → Use
form-validation-architect - Project Gantt charts or milestone tracking → Use
project-management-guru-adhd - Pomodoro timers or time tracking apps → Use
adhd-daily-planner - General agent architecture patterns → Use
agentic-patterns - Building the base agent framework → Use
agent-creator
Delegate to other skills when:
- User needs ADHD-specific time management →
adhd-daily-planner - Building persistent agent memory →
always-on-agent-architecture - Multi-agent coordination beyond calendar →
multi-agent-coordination - Background daemon architecture →
daemon-development
This skill focuses specifically on calendar data structures, scheduling algorithms, and meeting coordination logic.