Bloom : personne n'annule, on cesse simplement de venir. Bloom lit le rythme de visite propre à chaque client, signale ceux qui s'en écartent, et écrit une note personnelle à chacun. Les règles décident QUI, Gemini décide QUOI DIRE.

L'architecture est l'idée

Les règles décident QUI. Gemini décide QUOI DIRE. Le moteur de risque est déterministe, et délibérément. Il calcule l'écart médian entre les vraies visites d'un client (médiane, pas moyenne, parce qu'un écart de six mois pour une blessure tirerait une moyenne assez loin pour cacher une vraie rupture), puis les note contre leur propre cadence. C'est exact, auditable, reproductible, et ça n'hallucine jamais : le même carnet produit toujours le même verdict, ce qui compte quand la sortie est « cette personne vaut 1 295 $ par an et elle s'en va ». Gemini fait ensuite ce qu'une règle ne peut pas : lit une histoire humaine désordonnée (ce qu'ils ont fait en dernier, à quelle fréquence ils viennent normalement, à quel point ils sont au-delà de leur propre rythme) et leur écrit une note courte dans la voix de marque du propriétaire. Le propriétaire revoit, édite n'importe quelle ligne s'il le veut, et approuve avant que Bloom n'envoie depuis le domaine vérifié de l'entreprise. Jamais en masse : un message, une personne, une fois.

Rien à migrer : ce que le propriétaire utilise déjà

Le propriétaire exporte un CSV de ce qu'il utilise déjà (Fresha, Square, Vagaro, Booksy, même Google Calendar) et l'upload. Rien à migrer, rien à installer. Le parser trouve les colonnes par mot-clé plutôt que par nom d'en-tête, donc les exports de plateformes que Bloom n'a jamais vues fonctionnent quand même. Les lignes du même jour sont fusionnées en une visite, parce que ces plateformes exportent une ligne par ligne de service. Cette partie est gratuite, parce que ça ne coûte rien de montrer à quelqu'un ses propres pertes. Ce que le propriétaire voit est un radar client qui note chaque client contre sa propre cadence, avec ce que chacun vaut par an attaché ; à partir de là, le propriétaire déclenche un win-back un client à la fois. La livraison est plafonnée par entreprise et globalement, avec un send-claim atomique comme filet de sécurité pour qu'un cron relancé ne double jamais un message. La sauvegarde est mesurée sur les propres données du propriétaire : ré-upload d'un export frais, et si le client a re-réservé après le départ de la note, Bloom le compte.

L'agent hebdomadaire autonome, qui ship encore

Bloom a commencé comme un agent de contenu marketing et a pivoté vers la rétention. Le pivot est arrivé parce que le contenu est une commodité : n'importe quel propriétaire peut obtenir des légendes d'un chatbot en trente secondes, et je vendais quelque chose de gratuit. Ce qu'aucun d'eux ne pouvait obtenir, c'était une réponse à une question plus difficile : lequel de mes clients suis-je sur le point de perdre. C'est là que la rétention vit maintenant. Séparément, l'agent de contenu hebdomadaire original tourne toujours entièrement autonome sur un sidecar cron. Chaque lundi il choisit l'angle de la semaine, génère trois publications sociales et une infolettre dans la voix de marque du propriétaire, exécute une porte self-QA qui rejette et réécrit ses propres brouillons s'ils notent en dessous d'un seuil, et en Pro envoie l'infolettre depuis le domaine vérifié. Chaque action atterrit dans un fil d'agent public en direct (`/agent`) qu'un juge (ou n'importe qui) peut regarder en temps réel. Ce n'est plus le titre, mais c'est la raison pour laquelle AI-Native Operations, un tiers du score de ce hackathon, est vraiment satisfait plutôt que joué.