Assistants agentiques: intégrations sûres de calendrier et Gmail

Mon affirmation: la création d'assistants agentiques sûrs et utilisables qui agissent sur les calendriers, Gmail et les applications connectées nécessite de concevoir un environnement d'exécution basé sur les permissions, de séparer la planification de l'action, et d'intégrer les flux d'audit et de réversion dès le premier jour. Cet article fournit une liste de contrôle d'ingénierie concise et des invites utilisables pour y parvenir.

CONCEPTION DES PERMISSIONS POUR LES ASSISTANTS AGENTIQUES

Commencez par OAuth par utilisateur et des portées minimales. Utilisez OAuth lié à l'utilisateur plutôt qu'un compte de service partagé, sauf si un administrateur exige explicitement une délégation de domaine. La documentation de Google sur les portées granulaires est la base; cartographiez chaque capacité de l'agent à une seule portée OAuth et documentez l'intention lisible pour l'homme pour cette portée. Évitez d'inclure des jetons dans les invites. Conservez-les dans un coffre-fort et injectez les identifiants uniquement au moment de l'appel à l'intérieur d'un service d'exécution qui applique la politique.

Nous avons observé que les équipes qui traitent les permissions comme une UX produit, avec des écrans de consentement clairs et des aperçus de portées, reçoivent beaucoup moins de tickets de support. Un problème que nous avons rencontré est la prolifération des jetons due à une logique de rafraîchissement naïve; centralisez le rafraîchissement et faites tourner les jetons de rafraîchissement régulièrement.

PLANIFICATION CONTRE ACTION

Divisez l'assistant en un planificateur et un actionneur. Le planificateur produit un plan d'action discret: lire des fils récents, proposer deux horaires de réunion, rédiger un brouillon d'e-mail. L'actionneur n'exécute qu'après un contrôle de politique et, pour les actions sensibles, une étape de confirmation humaine. Ce schéma empêche le modèle d'improviser des opérations privilégiées et rend l'autorisation auditable.

Compromis pratique: une latence plus longue pour l'approbation humaine contre un risque plus faible. Pour de nombreuses actions de calendrier et d'e-mail, une pause de 30 à 60 secondes avec un humain dans la boucle est acceptable. Pour les tâches à haute fréquence, les approbations en lot fonctionnent mieux que les clics par action.

TESTS, JOURNAUX ET RÉCUPÉRATION

Chaque action doit produire une entrée d'audit immuable contenant l'intention demandée, la sortie du planificateur, la décision politique, l'appel de l'acteur et la réponse API retournée. Conservez un format de commande rejouable afin que vous puissiez rejouer et annuler. Fournissez un système d'annulation en un clic pour les N dernières actions et un flux de récupération qui crée des événements de compensation, par exemple annuler un événement et envoyer un suivi correctif.

Nous avons observé que les garde-fous au niveau des invites échouent sans un moteur de politique externe. En pratique, les modèles suggéreront des changements qui semblent plausibles mais enfreignent la politique. Une porte d'exécution qui refuse toute écriture lorsque la confiance est inférieure à un seuil calibré réduit ces incidents.

LISTE DE CONTRÔLE POUR LE PRODUIT ET L'INGÉNIERIE

1. OAuth par utilisateur avec des portées minimales et un texte de consentement explicite. 2. Coffre-fort pour les jetons et service d'exécution qui injecte les identifiants au moment de l'exécution. 3. Séparation planificateur/actionneur avec contrôles de politique. 4. Escalade avec un humain dans la boucle pour les actions sensibles. 5. Journaux d'audit immuables et format d'action rejouable. 6. Flux de réversion et de compensation avec des affordances UI claires.

Liez l'UX produit aux modèles de flux de travail décrits dans Conception de flux de travail humain-AI et utilisez le guide sur les différences d'agents dans Agents AI vs chatbots pour justifier la séparation planificateur/actionneur.

Essayez-le vous-même. Les invites ci-dessous démontrent la sortie du planificateur par rapport aux instructions sécurisées de l'actionneur. Attendez-vous à des plans au format JSON concis de la part du planificateur et à de courtes confirmations de la part de l'actionneur.

Cette invite demande au modèle de produire un plan contraint d'horaires de réunion candidats et une justification; utilisez-la comme planificateur. Attendez-vous à 2 à 3 créneaux candidats et une justification en une phrase.

Vous êtes un planificateur de réunion. L'utilisateur a 3 créneaux libres aujourd'hui: 10h00, 14h30, 16h00. Retournez exactement trois horaires de réunion candidats au format ISO avec une justification en une ligne pour chacun, et une note de confidentialité en une ligne indiquant si l'invitation touche des e-mails externes.

Cette invite est pour l'actionneur. Elle s'attend à un jeton de confirmation humaine et à un passage de vérification de politique explicit avant de créer l'événement.

Actionneur: donné le jeton de confirmation utilisateur X et le plan du planificateur Y, appeler Calendar.CreateEvent avec les champs {start,end,attendees,summary} uniquement si policy_check(policy_id:calendar_write) retourne pass. Si policy_check échoue, retourner le code d'échec et l'action humaine requise.

Un contre-argument est que des contrôles stricts ralentissent l'adoption. Mon estimation est que lorsque les équipes appliquent ces schémas, la rétention initiale des utilisateurs s'améliore car la confiance grandit, même si l'activation initiale est plus lente. Le compromis est clair: un déploiement plus rapide sans ces contrôles crée un risque mesurable et des coûts de remédiation plus élevés.