Patrick Colm Audley

Le problème récurrent des agents personnels vraiment utiles tient à ceci : le contexte dont ils ont besoin existe déjà, mais non dans le lieu bien rangé qu'une démonstration aimerait exhiber.

Il est dans le courrier.

Pas seulement dans les messages, d'ailleurs. Il est dans les libellés, les pièces jointes à demi oubliées, les vieux fils de projet, les factures, les changements de vol, les avis de compte, les décisions prises par des canaux de traverse, les introductions, les engagements ponctuels, et toutes ces bribes de « vous souvenez-vous quand... » qui font d'une boîte aux lettres quelque chose de plus proche d'une mémoire institutionnelle que d'une correspondance. Pour un agent au travail, Gmail n'est pas une boîte de réception. C'est un substrat.

gmeow est ma tentative de rendre ce substrat utile en local, sans le muer en quelque nouveau pipeline d'importation infonuagique.

Le dessein est volontairement banal là où il doit l'être : s'authentifier auprès de Gmail, hydrater la boîte aux lettres, mettre en cache localement la structure utile, exposer une API en loopback, et offrir aux agents un endpoint MCP qu'ils peuvent interroger sans recevoir les clefs de tout le compte. Sous le capot, il tient un catalogue PostgreSQL des libellés, fils, en-têtes, structures MIME, catégories, triples de graphe, travaux, états de synchronisation et fragments d'embeddings ; il range les charges utiles dans un magasin objet adressé par contenu BLAKE3 ; il bâtit des sidecars pour les pièces jointes ; puis il superpose recherche lexicale, recherche sémantique et parcours de graphe.

La frontière importante est celle-ci : gmeow n'est pas un service hébergé d'intelligence du courrier.

Il s'adresse à des systèmes locaux, mono-utilisateur, de confiance. Par défaut, il se lie à 127.0.0.1. Il ne prétend pas être une application exposée à Internet avec une couche d'authentification à moitié cuite qu'on aurait agrafée après coup. Si vous l'exposez à un réseau non fiable, vous sortez du modèle de menace. Cette contrainte n'est pas un inconvénient ; c'est le point même.

La surface destinée aux agents est la part qui m'importe le plus. Un agent local de codage ou de recherche devrait pouvoir poser des questions comme :

• « Trouve le fil où nous avons arrêté le plan de migration. »
• « Montre-moi les pièces jointes de ce fournisseur qui mentionnent le renouvellement. »
• « Quelles personnes, quels projets et quels sujets sont reliés à ce message ? »
• « Résume les messages récents non lus dans cette catégorie. »
• « Archive ceci après avoir enregistré les métadonnées pertinentes. »

Cela diffère moult de la construction d'un client de messagerie. Un client de messagerie est une interface pour un humain assis devant la vitre. gmeow est de la tuyauterie pour des agents oeuvrant aux côtés de l'humain : recherche, lectures, libellés, contacts, catégories, métadonnées de pièces jointes, état d'archive, recherche sémantique et exploration de graphe par REST et MCP.

La pièce graphe est l'endroit où l'affaire devient intéressante. Le courrier regorge de structure latente : personnes, organisations, projets, documents, obligations, motifs opérationnels récurrents. Une part de cette structure est explicite dans les en-têtes et les libellés. Une autre n'apparaît qu'une fois le texte extrait, les catégories classées, les fragments embarqués et les relations laissées à s'accumuler. Je ne veux pas d'un agent qui ne ferait que de la recherche par mot-clef dans ma boîte. Je veux qu'il bâtisse une carte locale utilisable.

Il y a aussi là un motif archivistique. Je n'ai jamais aimé les systèmes où la seule copie complète d'un dossier de travail vit derrière la frontière de produit de quelqu'un d'autre. gmeow garde en tête le chemin RFC822 brut, expose un service IMAP en lecture seule au-dessus des objets d'archive mis en cache, et traite les pièces jointes comme des objets locaux de premier ordre plutôt que comme des blobs opaques pendus à la réponse d'une API. Si une boîte aux lettres fait partie de votre mémoire longue, il devrait être possible de la préserver avec quelque dignité.

C'est le premier membre d'un motif que je m'attends à réemployer sur toute la surface Google. Gmail est le point de départ évident, parce que le courrier est dense en contexte, mais la même forme local-first devrait convenir à Drive, Calendar et aux autres services que les agents doivent sans cesse raisonner. Chaque service reçoit son petit démon, son cache local, son modèle objet, ses outils MCP et une frontière de confiance volontairement étroite.

État actuel : précoce, opiniâtre, et assez utile pour commencer à manger ma propre cuisine. Python, PostgreSQL, des bords façon FastAPI, pgvector pour les fragments d'embeddings, stockage objet local, secrets optionnels adossés à SOPS, délégation par compte de service ou OAuth utilisateur, et réponses TOON compactes par défaut pour les clients MCP qui n'ont pas besoin de cérémonial au format JSON.

Si vous bâtissez des agents locaux qui doivent raisonner sur du vrai courrier plutôt que sur des corpus-jouets, venez éprouver la chose. Le dépôt est ouvert, aspérités comprises : gmeow.