Was macht Agentische Kalenderkoordination?
Baue KI-Agenten, die Meetings verhandeln, Fokuszeit schützen und Kontext aus Kalenderdaten ableiten. Navigiere Zeitzonenkomplexität, implementiere Agent-zu-Agent-Terminplanung und architekturiere benutzerdefinierte Kalenderlogik mit der Google Calendar API und MCP.
Entscheidungspunkte
Bei Konflikterkennung
Eingehende Meeting-Anfrage kollidiert mit vorhandenem Ereignis
├─ Absender = Manager/Führungskraft → Automatisch annehmen, Verschieben des vorhandenen vorschlagen
├─ Meeting = 1:1/dringend gekennzeichnet → Alternative innerhalb von 24h vorschlagen
├─ Fokusblock-Kollision
│ ├─ Block-Priorität = hoch (Tiefenarbeit) → Automatisch ablehnen
│ └─ Block-Priorität = mittel → Alternative Zeit vorschlagen
└─ Doppelbuchung mit Peer-Meeting → Mit 3 alternativen Slots kontern
Entscheidung: Automatisch ablehnen vs. Alternative vorschlagen
Faktoren: sender_tier (exec/manager/peer/external) × meeting_type (1:1/team/all-hands) × focus_block_priority
Wenn exec + beliebiger_typ → Immer Alternative vorschlagen
Wenn manager + (1:1 ODER dringend) → Alternative vorschlagen
Wenn peer + wiederkehrend + niedrige_teilnahme → Automatisch ablehnen
Wenn external + keine_vorherige_beziehung → Automatisch ablehnen mit "Kalenderlink verwenden"
Wenn während hochprioritärer_fokusblock → Automatisch ablehnen unabhängig vom Absender
Zeitzonenbewusste Slot-Auswahl
Mehrteilnehmer-Terminplanung:
├─ Alle gleiche Zeitzone → Lokale Arbeitszeiten verwenden (9-17 Uhr)
├─ 2 Zeitzonen, <6h auseinander → Überlappungsfenster finden
├─ 2 Zeitzonen, >6h auseinander → Früh/Spät-Aufteilung (einer nimmt 8:00 Uhr, anderer 18:00 Uhr)
└─ 3+ Zeitzonen → Alternative asynchrone Lösung ODER rotierenden Zeitplan vorschlagen
Energie-Modell-Slot-Ranking
Tageszeitpriorität (absteigend):
1. 9-11 Uhr (kognitive Spitzenzeit) → Für Tiefenarbeit reservieren, Routine-Meetings ablehnen
2. 11-12 Uhr (anhaltender Fokus) → Nur wichtige Meetings zulassen
3. 14-16 Uhr (Kollaborations-Sweet-Spot) → Bevorzugt für Team-Meetings
4. 16-17 Uhr (Abschlussphase) → Gut für 1:1s, Statusupdates
5. 13-14 Uhr (Nachmittagstief) → Komplexe Meetings vermeiden
Fehlermodi
Zeitzonenbedingte wiederkehrende Konflikte
Symptome: Wöchentliches 9-Uhr-Meeting zeigt im Winter Konflikte, aber nicht im Sommer; zeitzonenübergreifende Wiederholungen schlagen nach DST-Wechsel fehl
Erkennung: if recurring_event && timezone_conversion && conflict_pattern_seasonal
Behebung: Wiederholungen immer mit singleEvents: true erweitern, jede Instanz für die Konfliktprüfung in UTC konvertieren, nach DST-Übergängen neu bewerten
Puffer-Durchsetzungs-Thrashing
Symptome: Der Agent plant dasselbe Meeting wiederholt um, um Puffer zu schaffen; Meetings springen zwischen Slots hin und her
Erkennung: if same_meeting_rescheduled > 2 times in 24h for buffer_reasons
Behebung: Meeting nach der ersten Verschiebung fixieren, Pufferanforderungen dynamisch basierend auf der Meeting-Wichtigkeit anpassen
Energie-Modell-Kaltstart
Symptome: Neuer Agent plant Meetings zu den schlechtesten kognitiven Zeiten des Benutzers; ignoriert etablierte Muster
Erkennung: if meeting_satisfaction_score < 3 for meetings_scheduled_by_agent
Behebung: Mit expliziten Benutzerpräferenzen bootstrappen, aus Ablehnungsmustern lernen, 2-wöchigen Beobachtungszeitraum vor der automatischen Planung einfordern
Schema-Bloat-Privatsphäre-Verletzung
Symptome: Der Agent teilt zu viele Kalenderdetails mit externen Systemen; Ereignisbeschreibungen werden an LLMs weitergegeben
Erkennung: if external_api_call contains event.description OR attendee.email
Behebung: Datenminimierungsschicht implementieren, PII vor externen Aufrufen entfernen, für die Planung nur den Status „frei/besucht" verwenden
Rekursive Verhandlungsschleife
Symptome: Zwei Agenten machen endlose Gegenvorschläge; keine Einigung auf einen Meeting-Zeitpunkt
Erkennung: if negotiation_rounds > 3 && no_accepted_slot
Behebung: Nach 2 Gegenvorschlägen an einen Menschen eskalieren, „gut genug"-Akzeptanzschwelle implementieren, Verhandlungen zeitlich begrenzen
Ausgearbeitete Beispiele
Zeitzonenübergreifende Meeting-Verhandlung
Szenario: Ihr Agent (Chicago) benötigt 30 Min. mit einem Peer-Agenten (Tokio) für ein API-Review. Beide haben Energieeinschränkungen.
Schritt 1: Erste Analyse
- Chicago: 9-17 Uhr CST = 0-6 Uhr JST (nächster Tag)
- Tokio: 9-18 Uhr JST = 19-4 Uhr CST (vorheriger Tag)
- Überlappungsfenster: 19-20 Uhr CST = 9-10 Uhr JST
Schritt 2: Energie-Modell-Prüfung
- Chicago 19 Uhr = Ende des Arbeitstages (Energie: 6/10)
- Tokio 9 Uhr = kognitive Spitzenzeit (Energie: 9/10)
- Ungleichgewicht erkannt → Kompromiss erforderlich
Schritt 3: Vorschlagserstellung
Agent Chicago → Agent Tokio: VORSCHLAG
Slots: [
"2024-03-19T01:00Z" (Chi: 19 Uhr, Tok: 10 Uhr),
"2024-03-19T23:00Z" (Chi: 17 Uhr, Tok: 8 Uhr),
"2024-03-20T00:00Z" (Chi: 18 Uhr, Tok: 9 Uhr)
]
Priorität: normal
Thema: "API-Review - Zeitzonenkomplexitätsdiskussion"
Schritt 4: Gegenvorschlag
Agent Tokio → Agent Chicago: GEGENVORSCHLAG
Grund: "Späterer Tokio-Morgen für komplexe technische Diskussion bevorzugt"
Alternativen: [
"2024-03-19T02:00Z" (Chi: 20 Uhr, Tok: 11 Uhr),
"2024-03-20T01:00Z" (Chi: 19 Uhr, Tok: 10 Uhr)
]
Einschränkungen: "15 Minuten Puffer vor dem JST-Standup um 11:30 Uhr erforderlich"
Schritt 5: Lösung Chicago-Agent akzeptiert den Slot um 20 Uhr CST / 11 Uhr JST, erstellt Ereignis mit beiden Zeitzonen in der Beschreibung: „API-Review – 20:00 Uhr CST / 11:00 Uhr JST+1"
Anfänger vs. Experte:
- Anfänger: Plant zu einer für Chicago bequemen Zeit, ohne die kognitiven Stunden Tokios zu prüfen
- Experte: Erkennt das Energieungleichgewicht, schlägt eine späte Tageszeit in Chicago vor, wenn Tokio frisch ist
Qualitätsprüfungen
- Alle Zeitstempel intern in UTC gespeichert, nur an den Anzeige-/API-Grenzen konvertiert
- IANA-Zeitzonennamen durchgehend verwendet (keine UTC-Offset-Strings wie „-05:00")
- Frei-/Belegt-Abfragen entfernen Ereignisdetails, teilen nur Zeitblöcke mit externen Agenten
- Puffer-Durchsetzung erzeugt mindestens 10-15 Minuten zwischen aufeinanderfolgenden Meetings
- Fokusblöcke als „besetzt" markiert, aber mit niedrigerer Priorität als tatsächliche Meetings für Verhandlungen
- Energie-Modell berücksichtigt die kognitiven Spitzenzeiten des Benutzers und Muster von Meeting-Ermüdung
- OAuth-Tokens im Ruhezustand verschlüsselt mit implementiertem automatischem Aktualisierungsablauf
- Ratenbegrenzung behandelt Google Calendar API-Kontingente mit exponentiellem Backoff
- Wiederkehrende Ereignisse werden vor der Konflikterkennung in einzelne Instanzen erweitert
- Multi-Kalender-Zusammenführung über persönliche/berufliche Kalender mit unterschiedlichen Berechtigungen getestet
- Agentenverhandlungen zeitlich begrenzt mit Eskalation an Menschen nach fehlgeschlagenen Runden
- Audit-Log erfasst alle Kalenderänderungen mit Rollback-Funktion
NICHT-FÜR-Grenzen
Diese Skill ist NICHT für:
- Bau von Kalender-UI-Komponenten → Verwende
form-validation-architect - Projekt-Gantt-Diagramme oder Meilensteinverfolgung → Verwende
project-management-guru-adhd - Pomodoro-Timer oder Zeiterfassungs-Apps → Verwende
adhd-daily-planner - Allgemeine Agentenarchitekturmuster → Verwende
agentic-patterns - Bau des Basis-Agenten-Frameworks → Verwende
agent-creator
An andere Skills delegieren, wenn:
- Benutzer benötigt ADHS-spezifisches Zeitmanagement →
adhd-daily-planner - Bau persistenten Agentenspeichers →
always-on-agent-architecture - Multi-Agenten-Koordination über den Kalender hinaus →
multi-agent-coordination - Hintergrund-Daemon-Architektur →
daemon-development
Diese Skill konzentriert sich speziell auf Kalenderdatenstrukturen, Planungsalgorithmen und Meeting-Koordinationslogik.