Coordenação de Calendário com Agentes

O que Coordenação de Calendário com Agentes faz?

Crie agentes de IA que negociam reuniões, protegem o tempo de foco e inferem contexto a partir de dados de calendário. Navegue pela complexidade de fusos horários, implemente agendamento agente-a-agente e arquitete lógica de calendário personalizada usando a API do Google Calendar e MCP.

Pontos de Decisão

Quando um Conflito é Detectado

Solicitação de reunião recebida conflita com evento existente
├─ Remetente = gerente/executivo → Aceitar automaticamente, sugerir mover existente
├─ Reunião = 1:1/urgente marcada → Propor alternativa dentro de 24h
├─ Colisão com bloco de foco
│  ├─ Prioridade do bloco = alta (trabalho profundo) → Recusar automaticamente
│  └─ Prioridade do bloco = média → Propor horário alternativo
└─ Dupla reserva com reunião de colegas → Contrapor com 3 horários alternativos

Decisão entre Recusar Automaticamente ou Propor Alternativa

Fatores: nível_remetente (exec/gerente/colega/externo) × tipo_reunião (1:1/time/all-hands) × prioridade_bloco_foco
Se exec + qualquer_tipo → Sempre propor alternativa
Se gerente + (1:1 OU urgente) → Propor alternativa
Se colega + recorrente + baixa_presença → Recusar automaticamente
Se externo + sem_relação_prévia → Recusar automaticamente com "use link de calendário"
Se durante bloco_foco_alta_prioridade → Recusar automaticamente independentemente do remetente

Seleção de Horário com Consciência de Fuso Horário

Agendamento com múltiplos participantes:
├─ Todos no mesmo fuso → Usar horário comercial local (9-17)
├─ 2 fusos, diferença <6h → Encontrar janela de sobreposição
├─ 2 fusos, diferença >6h → Divisão cedo/tarde (um pega 8h, outro pega 18h)
└─ 3+ fusos → Propor alternativa assíncrona OU escala rotativa

Classificação de Horários com Modelo de Energia

Prioridade do horário do dia (decrescente):
1. 9-11h (pico cognitivo) → Reservar para trabalho profundo, recusar reuniões rotineiras
2. 11h-12h (foco sustentado) → Permitir apenas reuniões importantes
3. 14-16h (ponto ideal para colaboração) → Preferir para reuniões de time
4. 16-17h (encerramento) → Bom para 1:1s, atualizações de status
5. 13-14h (queda pós-almoço) → Evitar reuniões complexas

Modos de Falha

Conflitos Recorrentes com Consciência de Fuso Horário

Sintomas: Reunião semanal às 9h mostra conflitos no inverno, mas não no verão; reunião recorrente entre fusos falha após mudança de horário de verão (DST) Detecção: if evento_recorrente && conversao_fuso_horario && conflito_recorrente_sazonal Correção: Sempre expandir eventos recorrentes com singleEvents: true, converter cada instância para UTC para verificação de conflitos, reavaliar após transições de DST

Oscilação na Aplicação de Buffer

Sintomas: Agente reagenda repetidamente a mesma reunião para criar buffers; reuniões saltam entre horários Detecção: if mesma_reuniao_remarcada > 2 vezes em 24h por_motivos_de_buffer Correção: Fixar a reunião após a primeira remarcação, ajustar requisitos de buffer dinamicamente com base na importância da reunião

Inicialização a Frio do Modelo de Energia

Sintomas: Novo agende agenda reuniões nos piores horários cognitivos do usuário; ignora padrões estabelecidos Detecção: if pontuacao_satisfacao_reuniao < 3 para reunioes_agendadas_pelo_agente Correção: Inicializar com preferências explícitas do usuário, aprender com padrões de recusa, exigir período de observação de 2 semanas antes de agendamento automático

Vazamento de Privacidade por Inchaço de Esquema

Sintomas: Agente compartilha muitos detalhes de calendário com sistemas externos; descrições de eventos vazam para LLMs Detecção: if chamada_api_externa contém evento.descricao OU participante.email Correção: Implementar camada de minimização de dados, remover PII antes de chamadas externas, usar apenas livre/ocupado para agendamento

Loop de Negociação Recursiva

Sintomas: Dois agentes contrapropõem infinitamente; sem convergência para um horário de reunião Detecção: if rodadas_negociacao > 3 && nenhum_horario_aceito Correção: Escalar para humano após 2 contrapropostas, implementar limite de aceitação "bom o suficiente", negociar com limite de tempo

Exemplos Práticos

Negociação de Reunião entre Fusos Horários

Cenário: Seu agente (Chicago) precisa de 30min com agente colega (Tóquio) para revisão de API. Ambos têm restrições de energia.

Passo 1: Análise Inicial

• Chicago: 9h-17h CST = 0h-6h JST (próximo dia)
• Tóquio: 9h-18h JST = 19h-4h CST (dia anterior)
• Janela de sobreposição: 19h-20h CST = 9h-10h JST

Passo 2: Verificação do Modelo de Energia

• Chicago 19h = final do dia de trabalho (energia: 6/10)
• Tóquio 9h = pico cognitivo (energia: 9/10)
• Desequilíbrio detectado → Necessário compromisso

Passo 3: Geração de Proposta

Agente Chicago → Agente Tóquio: PROPOR
Horários: [
  "2024-03-19T01:00Z" (Chi: 19h, Tok: 10h),
  "2024-03-19T23:00Z" (Chi: 17h, Tok: 8h),
  "2024-03-20T00:00Z" (Chi: 18h, Tok: 9h)
]
Prioridade: normal
Tópico: "Revisão de API - discussão sobre complexidade de fusos horários"

Passo 4: Contraproposta

Agente Tóquio → Agente Chicago: CONTRA
Motivo: "Preferir início da manhã em Tóquio para discussão técnica complexa"
Alternativas: [
  "2024-03-19T02:00Z" (Chi: 20h, Tok: 11h),
  "2024-03-20T01:00Z" (Chi: 19h, Tok: 10h)
]
Restrições: "Precisa de buffer de 15min antes da daily às 11:30 JST"

Passo 5: Resolução Agente Chicago aceita horário 20h CST / 11h JST, cria evento com ambos os fusos na descrição: "Revisão de API - 20h CST / 11h JST+1"

Novato vs Especialista:

• Novato: Agenda em horário conveniente para Chicago sem verificar horário cognitivo de Tóquio
• Especialista: Reconhece desequilíbrio de energia, propõe horário no final do dia em Chicago quando Tóquio está descansado

Gates de Qualidade

• Todos os timestamps armazenados em UTC internamente, convertidos apenas nas fronteiras de exibição/API
• Nomes de fuso horário IANA usados em todo o sistema (sem strings de offset UTC como "-05:00")
• Consultas de livre/ocupado removem detalhes de eventos, compartilhando apenas blocos de tempo com agentes externos
• Aplicação de buffer cria mínimo de 10-15 minutos entre reuniões consecutivas
• Blocos de foco marcados como "ocupado", mas com prioridade menor que reuniões reais para negociação
• Modelo de energia considera horários de pico cognitivo do usuário e padrões de fadiga de reuniões
• Tokens OAuth criptografados em repouso com fluxo de renovação automática implementado
• Limitação de taxa lida com cotas da API do Google Calendar com backoff exponencial
• Eventos recorrentes expandidos para instâncias individuais antes da detecção de conflitos
• Mesclagem de múltiplos calendários testada em calendários pessoais/profissionais com permissões diferentes
• Negociações de agentes com limite de tempo e escalada para humano após rodadas malsucedidas
• Log de auditoria captura todas as mutações de calendário com capacidade de reversão

Limites NÃO-PARA

Esta skill NÃO é para:

• Construir componentes de UI de calendário → Use form-validation-architect
• Gráficos de Gantt de projeto ou rastreamento de marcos → Use project-management-guru-adhd
• Temporizadores Pomodoro ou aplicativos de rastreamento de tempo → Use adhd-daily-planner
• Padrões gerais de arquitetura de agentes → Use agentic-patterns
• Construir a estrutura base do agente → Use agent-creator

Delegar para outras skills quando:

• Usuário precisa de gerenciamento de tempo específico para TDAH → adhd-daily-planner
• Construindo memória persistente de agente → always-on-agent-architecture
• Coordenação multi-agente além de calendário → multi-agent-coordination
• Arquitetura de daemon em segundo plano → daemon-development

Esta skill foca especificamente em estruturas de dados de calendário, algoritmos de agendamento e lógica de coordenação de reuniões.