Cette page t'a-t-elle aidé ?
Cette page t'a-t-elle aidé ?
Concepts
Gilbert retient deux choses distinctes : ce qu'il sait de toi, et ce qu'il a fait pour toi. Les deux sont strictement per-user et jamais lisibles workspace-wide.
Dernière mise à jour : 27 juin 2026
On confond souvent « mémoire d'un assistant » avec une seule chose. Gilbert en distingue deux, parce qu'elles répondent à des questions différentes :
| Mémoire | Répond à | Source |
|---|---|---|
| Narrative | « Qui es-tu ? », « De quoi a-t-on parlé ? » | Tes conversations (chat web, Telegram) |
| Opérationnelle | « Tu as envoyé mon mail ? », « Qu'as-tu fait ? » | Les actions proposées et exécutées |
La mémoire narrative est gérée par le pipeline personal. Elle s'empile en trois couches, du court terme au long terme :
rolling_summary). La fenêtre vive injecte tes derniers messages tels quels ; tout ce qui en sort est condensé dans un résumé court-terme stocké sur personal_sessions.rolling_summary. Le résumé s'étend par lots quand assez de messages tombent hors fenêtre, pas à chaque tour, pour ne pas cramer un appel LLM inutilement.personal_memories). Après une turn humaine, un extracteur LLM identifie 0 à 3 faits durables et les classe par kind : identity (qui tu es), preference (comment tu aimes travailler), ongoing (projet en cours), commitment (engagement daté), fact (autre fait durable). Dédup par contenu normalisé, cap par user avec purge LRU sur les fact uniquement.identity_card_md). Une synthèse markdown régénérée à partir des memories L2, injectée en bas du prompt sous [Fiche d'identite]. C'est le condensé long-terme de qui tu es, que Gilbert relit à chaque conversation.Shippée le 9 juin 2026. Gilbert se souvient désormais cross-canal de ce qu'il a fait, actions proposées et exécutées, quel que soit le canal d'origine (Telegram, chat web, email). Avant, demander « tu as envoyé mon mail à Delphine ? » sur le chat web pouvait obtenir un « je ne retiens pas l'historique » pour une action lancée depuis Telegram. Plus maintenant.
trace_id cross-canal. Un identifiant de trace est propagé bout-en-bout sur la même interaction : il relie l'action en attente (col. sur personal_pending_actions), le message qui l'a portée (personal_messages) et les événements du journal (personal_events). C'est ce qui permet de recoller une proposition faite sur un canal à son exécution sur un autre.[Ce que tu as fait recemment]. Gilbert le consulte d'abordavant de répondre au statut d'une action.recall_actions. Pour les actions au-delà de la fenêtre du bloc, le LLM appelle recall_actions avec des filtres optionnels query (texte sur l'outil et le contenu), status (executed, pending, aborted, expired…) et days(fenêtre, défaut 30, max 90). Lecture pure : aucun INSERT/UPDATE, pas de gate de confirmation.Le bloc injecté ressemble à ceci, libellés humains, datés en heure Europe/Paris, avec la provenance canal quand elle est connue :
[Ce que tu as fait recemment]
- gmail_send à delphine@acme.fr : exécuté le 8 juin à 18:42 (demandé le 8 juin à 18:40 via Telegram)
- calendar_respond (invit evt_92ab…) : confirmé le 8 juin à 09:05 (demandé le 8 juin à 09:04 via le chat web)
- publish_linkedin_post « Retour sur Q2 » : en attente de ta confirmation (expire dans 4 min) (demandé le 9 juin à 11:00 via email)Et l'outil de recall, déclenché par le LLM dès qu'une question porte sur une action hors fenêtre récente :
// Le LLM appelle recall_actions quand l'user demande
// le statut d'une action passée hors fenêtre récente.
{
"name": "recall_actions",
"input": {
"query": "delphine",
"status": "executed",
"days": 30
}
}
// Réponse rendue (extrait) :
// gmail_send → delphine@acme.fr « Relance facture Q2 » :
// exécutée : proposée le 02/06/2026 14:10, exécutée le 02/06/2026 14:12La page /personal/activityte donne la vue brute de tout ce que Gilbert a fait pour toi : les personal_events triés du plus récent au plus ancien et groupés par trace : une interaction qui a généré une proposition puis un envoi apparaît regroupée, pas en lignes éparpillées. Les events sans trace_id restent des entrées individuelles.
Tu y accèdes depuis ta page Intégrations (« Pour voir ce que Gilbert fait avec ces accès… »). La RLS est strictement user-scoped : la policy n'autorise la lecture que si auth.uid() = user_id : aucun accès cross-user, même pour un admin.
C'est l'invariant non négociable des deux mémoires, et il tient au niveau de la base :
user_id ET workspace_id. Le journal d'activité filtre sur auth.uid() = user_id. Un admin ne voit que ses propres actions et events, pas ceux des autres membres.memory_enabled. Quand tu coupes la mémoire, l'extraction narrative s'arrête (statut disabled), et une pause temporaire est aussi possible (memory_paused_until). Tu peux purger tes memories à tout moment (wipe RGPD), ce qui reset aussi ta fiche d'identité.