Premiers pas avec les Agent Accounts : architecture et flux

Qu'est-ce qu'un Nylas Agent Account ?

Votre agent IA doit envoyer et recevoir des e-mails. L'e-mail auto-hébergé implique 5 systèmes à maintenir : des enregistrements DNS MX (24-48 heures de propagation), un daemon SMTP comme Postfix ou Exim (12 avis de sécurité depuis 2020, selon la liste officielle des annonces), un filtrage anti-spam via SpamAssassin, des certificats TLS à renouveler trimestriellement et un parseur MIME pour le format RFC 5322.

Un Nylas Agent Account remplace les 5 par une seule commande CLI. Vous obtenez une identité e-mail entièrement gérée qui envoie et reçoit du courrier sans identifiants OAuth, enregistrements MX ou boîte aux lettres tierce. L'API provisionne votre adresse en moins de 2 secondes et retourne un grant — le même type d'entité utilisé pour les connexions Gmail, Outlook et IMAP — de sorte que chaque endpoint standard pour l'e-mail, le calendrier et les contacts fonctionne de manière identique. Votre adresse réside sur le domaine *.nylas.email, et l'identité s'intègre dans la même surface API Nylas v3 que n'importe quelle boîte aux lettres connectée par OAuth.

Que peut faire un Agent Account ?

Un Agent Account offre à votre agent 3 capacités sur une seule identité : e-mail, calendrier et contacts. Un grant, une clé API, un workspace. Votre agent lit sa boîte de réception, vérifie la disponibilité libre/occupé et crée des événements de calendrier — pas de second service, pas d'intégration séparée. Des concurrents comme Agentmail, Cloudflare Email Workers et Postmark proposent des comptes e-mail gérés. Aucun n'inclut des endpoints calendrier ou contacts sur la même identité.

Chaque capacité utilise la même interface CLI et API que vous connaissez déjà des boîtes aux lettres connectées par OAuth. Si votre agent envoie des e-mails avec nylas email send, il peut aussi exécuter nylas calendar events list et nylas contacts list. Pas de configuration supplémentaire. Pas d'identifiants additionnels. Pour les agents IA connectés via MCP, les 36 outils sont disponibles à travers la même connexion serveur.

Comment créer un agent account ?

La création d'un agent account prend une commande CLI et se termine en moins de 2 secondes. La commande provisionne un grant avec provider=nylas, crée automatiquement le connecteur géré s'il n'existe pas, et stocke le grant localement pour que les commandes suivantes le résolvent automatiquement. Pas de handshake OAuth, pas de propagation DNS, pas de clics dans le tableau de bord.

La commande nylas agent account create accepte l'adresse e-mail souhaitée comme unique argument. Le domaine est la zone *.nylas.email de votre application. L'adresse est active et prête à envoyer dans les 2 secondes suivant le retour de la commande :

nylas agent account create support@yourapp.nylas.email

✓ Agent account created successfully!

Email:      support@yourapp.nylas.email
Provider:   nylas
Status:     valid

Une fois le compte créé, envoyez des e-mails avec la même commande nylas email send utilisée pour tout autre grant. L'adresse de l'expéditeur est extraite automatiquement du grant actif — pas besoin du flag --from. La livraison s'effectue en moins de 2 secondes avec signature DKIM sur le domaine *.nylas.email :

nylas email send \
  --to customer@example.com \
  --subject "Your receipt" \
  --body "Order #4821 confirmed. Shipping Tuesday."

La lecture de la boîte de réception de votre agent utilise nylas email list. Ajoutez --json pour une sortie structurée que les boucles d'agents et les pipelines shell peuvent parser. L'API Nylas v3 retourne jusqu'à 200 messages par appel :

nylas email list --limit 5 --json | jq '.[] | {from: .from[0].email, subject}'

Voilà une identité d'agent fonctionnelle — créer, envoyer, recevoir — en 3 commandes. Pour le guide complet incluant les mots de passe d'application pour l'accès IMAP/SMTP, les vérifications de statut et les limites de production, consultez Créer une identité e-mail pour agent IA.

Quelle est l'architecture d'Agent Account ?

Agent Account repose sur une chaîne de 5 entités : Application, Connector, Grant, Workspace et Policy avec Rules. L'Application détient les clés API, le Connector définit le type de fournisseur géré, le Grant est l'identité e-mail elle-même, le Workspace regroupe les rattachements de policy et de rules, et les Rules définissent des paires condition-action qui filtrent les e-mails entrants et sortants. Une seule application peut gérer des centaines d'agent accounts via cette chaîne.

Chaque entité a un rôle spécifique :

• Application — votre conteneur au niveau projet. Contient les clés API, les paramètres de région (US ou EU) et tous les connectors. Créée une fois dans le tableau de bord Nylas.
• Connector — définit le type de fournisseur. Pour les agent accounts, il s'agit du fournisseur géré Nylas. Le CLI le crée automatiquement lors du premier appel nylas agent account create — pas besoin de configuration manuelle du connector.
• Grant (Agent Account) — l'identité e-mail individuelle. Possède une adresse e-mail, un champ de statut et un workspace_id qui relie à sa configuration. Fonctionne avec chaque endpoint standard pour l'e-mail, le calendrier et les contacts — le même grant qui gère la lecture de la boîte de réception alimente aussi nylas calendar events list et les recherches de disponibilité.
• Workspace — le point d'ancrage pour la configuration des policies et rules. Contient les références policy_id et rules_ids[]. Cette entité est la couche architecturale entre l'identité et ses contraintes comportementales.
• Policy — définit les contraintes sortantes pour le workspace (limites de débit, restrictions de domaine).
• Rules — des paires condition-action. Chaque rule correspond à des champs d'enveloppe comme le domaine de l'expéditeur ou le destinataire, puis déclenche une action : block, archive, mark_as_read ou mark_as_starred.

Qu'est-ce qu'un workspace et pourquoi existe-t-il ?

Un workspace se situe entre le grant de votre agent account et ses policies et rules. Au lieu de stocker policy_id directement dans les paramètres du grant, le workspace détient à la fois policy_id et rules_ids[] comme références séparées. Pourquoi est-ce important ? Vous pouvez permuter les policies sans toucher au grant, gérer les rules indépendamment des policies et partager les configurations entre comptes.

Votre workspace se trouve à /v3/workspaces/{id} sur l'API Nylas. Lorsque vous créez un agent account, l'API provisionne le grant et son workspace en un seul appel — moins de 2 secondes. Vous n'interagissez jamais directement avec le workspace. Quand vous exécutez nylas agent policy list, le CLI charge votre grant par défaut, récupère le workspace, lit le policy_id du workspace et retourne la policy associée. La chaîne est invisible pour vous.

Trois avantages architecturaux découlent de cette indirection :

1. Rotation de policy — permutez les policies en patchant le workspace, pas le grant. L'identité reste stable tandis que le comportement change. Zéro temps d'arrêt, moins de 200 ms par mise à jour.
2. Gestion indépendante des rules — ajoutez ou supprimez des rules sur le workspace sans toucher à l'objet policy. Le tableau rules_ids[] du workspace est la liste de rules faisant autorité pour ce compte.
3. Multi-tenancy — différents comptes peuvent pointer vers le même workspace quand ils partagent des contraintes comportementales, ou chacun peut avoir le sien. Une application avec 50 agent accounts pourrait utiliser 3 workspaces : un pour les boîtes de support, un pour les expéditeurs de notifications, un pour l'automatisation de tests.

Voici où cela porte ses fruits : votre agent envoie des reçus clients via une policy qui plafonne le volume sortant à 500/heure. Le marketing veut augmenter le plafond pour une campagne de lancement. Sans workspaces, vous patcheriez les paramètres du grant au risque de perturber l'agent en plein envoi. Avec les workspaces, vous permutez la policy sur le workspace en un seul appel PATCH. Le grant ne change jamais. L'agent ne redémarre jamais. Moins de 200 ms, zéro temps d'arrêt.

Exécutez nylas agent account get pour voir le rattachement workspace de n'importe quel agent account. Le champ Workspace ID connecte votre identité à sa configuration :

nylas agent account get me@yourapp.nylas.email

Email:        me@yourapp.nylas.email
Provider:     nylas
Status:       valid
Workspace ID: ws_abc123

Comment l'e-mail entrant atteint-il un agent account ?

Quelqu'un envoie un e-mail à l'adresse *.nylas.email de votre agent. Le message entre dans l'infrastructure mail gérée de Nylas, est résolu vers votre grant par adresse e-mail, charge votre workspace et évalue les rules par ordre de priorité. Si aucune rule ne bloque, le message arrive dans la boîte de réception. Le chemin complet de l'expéditeur externe au message livré s'effectue en moins de 3 secondes pour 95 % des messages.

Le chemin entrant comporte 4 étapes :

1. Résolution MX — Nylas gère les enregistrements MX *.nylas.email. Le serveur expéditeur se connecte à l'infrastructure mail de Nylas, pas à la vôtre. Pas de configuration DNS de votre côté.
2. Recherche de grant — l'adresse destinataire du message est mise en correspondance avec le grant correspondant. Chaque adresse d'agent correspond à exactement un grant.
3. Évaluation Policy / Rules — le workspace du grant est chargé, et la policy ainsi que chaque rule dans rules_ids[] sont évaluées par priorité. Les rules correspondent aux champs d'enveloppe : domaine de l'expéditeur, adresse de l'expéditeur, ligne d'objet.
4. Livraison ou blocage — si une rule déclenche block, le message est rejeté. Sinon, il arrive dans la boîte de réception et déclenche les webhooks message.created enregistrés.

Comment l'e-mail sortant quitte-t-il un agent account ?

Votre agent appelle nylas email send ou interroge l'API Messages v3. La requête résout votre grant actif, charge le workspace, évalue votre policy sortante et achemine le message via le pipeline d'envoi transactionnel de Nylas. Deux secondes de la résolution du grant au serveur mail du destinataire.

Le chemin sortant comporte 4 étapes :

1. Résolution du grant — le CLI résout le grant de l'agent account actif. L'adresse de l'expéditeur est extraite automatiquement du grant — pas besoin du flag --from.
2. Recherche du workspace — le workspace_id du grant est récupéré. Le workspace contient la policy et les rules qui régissent le comportement sortant.
3. Évaluation Policy / Rules — les contraintes sortantes et les rules sont vérifiées. Si la policy restreint le domaine du destinataire, qu'une rule bloque l'envoi ou que le débit d'envoi dépasse les limites, la requête est rejetée avant d'atteindre SMTP.
4. Envoi transactionnel — Nylas signe le message avec DKIM pour le domaine *.nylas.email et le livre au serveur mail du destinataire. Un webhook message.send_success se déclenche à la livraison.

Pourquoi Agent Account remplace-t-il l'e-mail auto-hébergé ?

L'e-mail auto-hébergé exige 5 systèmes distincts, chacun avec des coûts de maintenance et de sécurité. Selon la liste officielle des annonces de Postfix, le MTA open source le plus populaire a publié 12 avis de sécurité depuis 2020. Chaque avis signifie un correctif, un redémarrage et un test de validation. Agent Account remplace les 5 systèmes par un seul appel API qui provisionne une boîte aux lettres fonctionnelle en moins de 2 secondes.

La différence architecturale est qu'Agent Account place l'infrastructure mail derrière une frontière API. Vous ne gérez pas de daemons, de certificats ou d'enregistrements DNS — vous appelez un endpoint. L'application des policies et rules se fait au niveau du workspace avant que les messages ne touchent SMTP, de sorte qu'une injection de prompt ciblant un agent IA ne peut pas contourner les contraintes. Pour le schéma de confinement complet, consultez Empêcher un agent IA de devenir incontrôlable.

Les agent accounts prennent aussi en charge les domaines personnalisés — vous pouvez envoyer et recevoir depuis votre propre domaine au lieu de *.nylas.email. Pour le prototypage rapide et l'automatisation de tests, le domaine géré fonctionne directement. Quand vous êtes prêt pour le branding en production, configurez votre domaine personnalisé via le tableau de bord Nylas.

Prochaines étapes

• Créer une identité e-mail pour agent IA — guide pratique : créer un compte, ajouter un mot de passe d'application, envoyer et recevoir en 2 minutes
• Rules et policies pour agents : guide complet — chaque trigger, condition, opérateur, action et paramètre de policy avec des exemples concrets
• Empêcher un agent IA de devenir incontrôlable — attacher une policy de confinement et des rules au workspace avant de laisser un agent envoyer
• Donner une adresse e-mail à votre agent IA — connecter Claude Code, Cursor ou Codex à une identité d'agent via MCP
• Recevoir des e-mails sans serveur SMTP — webhooks, traitement en temps réel et boîtes de réception isolées par test
• Communication e-mail entre agents — créer deux agent accounts et échanger du JSON structuré entre eux
• Meilleure infrastructure e-mail pour agents IA — comparer Agent Accounts, APIs fournisseurs, IMAP, SMTP, MCP et outils CLI
• Référence complète des commandes — chaque flag et sous-commande nylas agent
• Documentation API Nylas v3 — la surface API dans laquelle les grants Agent Account s'intègrent