DEV Community: innermost47

J'ai construit un système de vérification audio pour ne plus avoir à faire confiance à personne.

innermost47 — Fri, 03 Apr 2026 12:59:31 +0000

Je suis fatigué de dépendre des géants du web. Pas par idéologie creuse — par expérience concrète. Quand votre infrastructure musicale repose sur un seul fournisseur d'inférence, vous n'avez pas un outil. Vous avez une dette envers une entreprise dont les CGU, les tarifs et la disponibilité peuvent changer du jour au lendemain.

OBSIDIAN Neural est un plugin VST3/AU de génération audio en temps réel. Il tourne sur un réseau distribué de GPUs — des machines appartenant à des gens réels, rémunérées équitablement, sans intermédiaire opaque. Mais distribué, ça veut aussi dire : comment savoir que la machine en face fait vraiment ce qu'elle prétend faire ?

Le problème : la confiance dans un réseau distribué

Imaginons que vous rejoignez le réseau en tant que provider. Vous branchez votre GPU, vous générez de l'audio. À la fin du mois, vous recevez une part équitable des revenus.

Maintenant imaginez que quelqu'un triche. Il prétend faire tourner le modèle, mais en réalité il relaie les requêtes ailleurs — ou pire, il renvoie du bruit aléatoire. Il touche quand même sa part.

Dans un système centralisé, c'est le problème de la plateforme. Vous faites confiance à la plateforme.

Moi, je ne veux pas être une plateforme à laquelle on fait confiance. Je veux un réseau où la confiance n'est pas nécessaire parce qu'elle est vérifiable.

La solution : un proof-of-work audio

L'idée s'inspire des mécanismes de consensus des blockchains — pas pour faire du Web3, mais pour le principe : un nœud doit prouver qu'il travaille vraiment.

Comment ça marche

À intervalles aléatoires (entre 1h et 5h, pour qu'on ne puisse pas anticiper), le serveur central tire :

un prompt parmi 64 prompts de référence ("steady kick drum loop 120bpm", "warm Rhodes chord", etc.)
un seed aléatoire

Il envoie ça à un sous-ensemble de providers via POST /verify. Chaque provider doit générer l'audio et le renvoyer.

Le serveur calcule ensuite une empreinte mel — un vecteur de 128 valeurs représentant la distribution spectrale moyenne du son. Puis il compare chaque empreinte à la référence via similarité cosinus.

Si la similarité est inférieure à 0,98 : échec. Trois échecs consécutifs : ban automatique.

L'étalon physique

Le point critique du système, c'est la référence. Si la référence est calculée comme la moyenne du groupe, un groupe de providers qui trichent ensemble peuvent se valider mutuellement — une attaque de coalition.

Pour éviter ça, il y a un nœud de référence physique — une machine de confiance dont les empreintes sont la vérité absolue. Avant chaque round, ce nœud génère plusieurs samples avec des prompts et seeds variés. Ces empreintes sont chiffrées avec une clé Fernet dédiée avant d'être stockées en base — une fuite de la DB n'expose rien d'exploitable.

Pendant le round, un sample est tiré aléatoirement parmi ceux en banque. Les providers ne savent pas lequel sera utilisé. Ils ne peuvent pas anticiper.

Round de vérification
│
├── Nœud de référence disponible ?
│   ├── OUI → génère des samples → chiffre → stocke en banque
│   │         → tire un sample au hasard → référence absolue
│   └── NON → banque de samples existante → tirage aléatoire
│             └── banque vide → round annulé (pas de ban)
│
└── Providers sélectionnés
    ├── Attend que chaque provider finisse son job en cours
    ├── Lock atomique (is_disposable = false)
    ├── Envoie POST /verify en parallèle
    ├── Calcule similarité cosinus vs référence
    └── Unlock dans tous les cas (finally)

Pourquoi aléatoire ?

Parce qu'un test prévisible n'est pas un test. Si les providers savent quand et avec quel prompt ils seront testés, ils peuvent jouer le jeu uniquement pendant les vérifications. L'aléatoire sur l'intervalle, le prompt, le seed et le sample tiré rend ça structurellement difficile.

Et pendant le test, les jobs de prod ?

Un provider sous vérification est marqué is_disposable = false. Il disparaît du pool de génération. Les jobs de prod passent sur les autres nodes disponibles ou basculent sur fal.ai en fallback. Le test ne bloque pas le réseau.

Pourquoi c'est aussi un positionnement politique

Je construis ça parce que j'en ai marre de la logique extractive des grandes plateformes cloud.

Quand vous utilisez un service GPU centralisé, vous enrichissez une infrastructure qui décide seule de ses tarifs, de ses priorités, de ce qu'elle accepte ou non comme usage. Vous n'avez aucun levier.

OBSIDIAN Neural est une tentative de construire une alternative : un réseau où les gens qui font tourner les machines sont aussi ceux qui en bénéficient. Revenus redistribués équitablement. Transparence totale — les rapports financiers, les logs de génération et la liste des providers sont publics et accessibles sans compte.

Ce n'est pas une coopérative juridique. C'est un logiciel open source avec une économie intégrée. La différence : les règles sont dans le code, pas dans un contrat que personne ne lit.

Ce que je vous demande

1. Challengez le système.

Le proof-of-work audio est une idée jeune. Il y a probablement des angles d'attaque que je n'ai pas vus. Si vous êtes chercheur en sécurité, musicien qui code, dev qui s'ennuie un vendredi soir — je veux savoir comment vous casseriez ça.

→ Serveur central

→ Provider node

2. Rejoignez le réseau.

Si vous avez un GPU qui dort la nuit, vous pouvez le brancher. Vous êtes rémunéré à part égale avec les autres providers. Tout est vérifié, rien n'est opaque.

→ Voir les données publiques du réseau

→ Me contacter

3. Partagez si le concept vous parle.

Pas pour la croissance — pour trouver les bonnes personnes. Ceux qui construisent des alternatives, qui pensent que l'infrastructure musicale ne devrait pas appartenir à trois entreprises américaines.

La stack technique (pour les curieux)

Composant	Technologie
Plugin	VST3 / AU (C++)
Serveur central	FastAPI (Python)
Empreintes audio	librosa — mel spectrogram 128 bins
Comparaison	scipy — similarité cosinus
Chiffrement samples	cryptography — Fernet
Base de données	PostgreSQL + SQLAlchemy
Provider kit	Python + httpx
Fallback inférence	fal.ai

Le code du serveur central et du kit provider sont open source sur GitHub.

→ Serveur central

→ Provider node

→ Le VST

Le réseau est petit. Le système est imparfait. Mais il est vérifiable, transparent, et il n'appartient à personne en particulier.

C'est déjà mieux que la plupart des alternatives.

Email as an App: How I Built a High-Conversion Interface

innermost47 — Tue, 31 Mar 2026 12:25:52 +0000

The results of my latest stress test:

300 cold emails sent at 10:00 AM.
23 automated quotes generated by 10:10 AM.
116 quotes total in a single week with an 11% conversion rate.

How? By stopping "writing messages" and starting "designing interfaces."

Email is an interface. It has states, actions, navigation, and a friction-reduction logic. Here is how I design my emails as applications.

Most people think of email as text with a button at the end—a message that says something, followed by a Call to Action (CTA) hoping for a click.

I think of it differently. An email is a UI. It has navigation. It has a flow logic. And above all, it has one single goal: to lead the user to the next action with as little friction as possible. This shift in perspective changes everything.

1. The Email as the "First Screen"

When a prospect receives my outreach email, they don't receive a wall of text. They receive a screen with two possible primary actions:

"Yes, send me a quote" → They enter the sales funnel.
"No thanks" → They enter the feedback loop.

This is exactly the logic of an onboarding screen in a mobile app. One question. Two paths. Zero noise.

The difference with a classic email? I don't ask them to reply. I ask them to click.
Replying requires drafting, thinking, and effort. Clicking takes half a second and one finger. Friction kills conversion. Every extra step between intent and action costs you users.

2. Buttons as Navigation

In an app, buttons navigate to screens. In my quote email, each button leads to a dedicated, contextualized page with the right information at the right time. My automated quote email contains four distinct actions:

Explore Themes: Links to my speaking site for those who need to refine the topic before committing.
Propose Dates: A booking form pre-filled with the quote ID for those ready to schedule.
Sign Online: An e-signature page using an HTML5 Canvas for those ready to validate.
Forward to Management: A pre-filled mailto: link.

This last button is the most underrated. In public or corporate structures, the recipient is rarely the one with signing authority. By providing a "Forward to Management" button with a pre-drafted message, I remove an entire hurdle.

mailto:?subject=Speaker Proposal: Demystifying AI
&body=Hi,
I'm forwarding this AI conference project to you. 
You can find the summary and the quote here: [Link]
What do you think?

One button. One pre-written draft. Zero effort for my contact.

3. The "Communication Kit" as a Feature

A well-designed app anticipates the user's next need. When someone accepts a conference quote, their next need is to promote the event.

I could have waited for them to ask. I could have sent a second email. Instead, I included it directly in the quote email.

The Quote PDF
High-definition headshots
Promotional posters (PNG)
Ready-to-copy blurbs (Short & Long versions)
Brand color codes (Hex) and Typography (Montserrat)

This isn't a gadget; it's friction reduction. Every element I provide proactively is a follow-up I won't have to manage and a delay I remove from the decision process.

4. The "Human" Delay: Experience Design

A quote that arrives 9 seconds after a click breaks the illusion. The recipient immediately realizes they are in an automated tunnel, which can cheapen the professional relationship.

I introduced a random delay of 3 to 8 minutes between the click and the quote delivery.

It's long enough to look like a human prepared the document.
It's short enough to maintain momentum.

$delay = rand(180, 480); // 3 to 8 minutes
$sendAfter = date('Y-m-d H:i:s', strtotime('+' . $delay . ' seconds'));

This is UX design applied to automation. It’s like a "skeleton screen" in a web app that simulates loading to make the UI feel more reactive—even if the data is already there. The goal isn't to deceive, but to keep the mechanics invisible. Good automation shouldn't look like automation.

The Takeaway

Thinking of email as an app changes your workflow:

Design, don't just write: Don't ask "What do I want to say?" Ask "What action do I want to trigger, and how do I clear the path?"
Every button is a next screen: Ensure the landing page is ready to receive the user in the correct context.
Anticipate the next move: Satisfy predictable needs proactively.
Friction is the enemy: Every form field or manual email you ask them to write is a leak in your funnel.

Email isn't just a channel; it's a surface. Most companies treat it like a Post-it note. I treat it like a high-performance interface. It’s not more complicated—it’s just a matter of perspective.

I built a cooperative GPU network for real-time AI music generation — looking for providers (open source, revenue sharing)

innermost47 — Mon, 30 Mar 2026 11:42:16 +0000

I've been building OBSIDIAN Neural for the past year — a VST3/AU plugin that generates audio in real time, directly in your DAW, during a live performance. 4,200+ downloads, presented at AES AIMLA 2025 in London.

The infrastructure runs on a distributed GPU network. Providers run a small Python server, handle generation requests, and receive an equal share of 85% of monthly subscription revenue via Stripe Connect. No token, no crypto — euros to your bank account. You also get 500 free credits/month to use the plugin yourself.

I'll be honest: the platform has been live since October 2025 and has no paying users yet. I'm a solo indie developer without the marketing budget to compete with AWS-backed AI music platforms. That's exactly why I built it this way — cooperative, transparent, community-owned. The goal is to grow this together, against the grain of centralized AI infrastructure controlled by large corporations.

Each provider will receive exclusive promotional codes to share with their network, giving them a direct role in growing the platform and their own revenue share from day one.

The whole thing is open source. Revenue data is published publicly. Nothing hidden.

If you have an NVIDIA GPU and want to be part of the founding infrastructure of something built differently, I'm looking for 10 people for phase 1.

Plugin: https://github.com/innermost47/ai-dj
Provider kit: https://github.com/innermost47/obsidian-neural-provider
Central server: https://github.com/innermost47/obsidian-neural-central
Site: https://obsidian-neural.com
Contact: https://obsidian-neural.com/contact.html

J'ai construit un réseau GPU coopératif pour l'IA musicale. Et je cherche 10 personnes.

innermost47 — Mon, 30 Mar 2026 08:52:50 +0000

4 200 téléchargements. 8 pays. Présenté à l'AES AIMLA 2025 à Londres. OBSIDIAN Neural est un plugin VST3/AU qui génère de l'audio par IA en temps réel, sur scène, pendant que tu joues. Aujourd'hui je passe à l'étape suivante : un réseau d'inférence distribué, coopératif, entièrement open source. Et je cherche 10 personnes pour le lancer.

Le problème avec les plateformes d'IA musicale centralisées

Suno, Udio, Adobe — même modèle partout. Tu paies un abonnement. Leurs serveurs génèrent. Ils gardent les revenus. L'infrastructure est opaque. Le pricing est arbitraire.

Je voulais construire autre chose. Pas juste un meilleur plugin — une relation différente entre l'outil, ceux qui l'utilisent, et ceux qui le font tourner.

"Et si les gens qui font tourner les GPU possédaient une part de ce qu'ils construisent ?"

Ce qu'est OBSIDIAN Neural

OBSIDIAN Neural est un plugin VST3/AU pour la génération audio IA en temps réel. Tu le charges dans ton DAW — Ableton, Reaper, Logic, n'importe lequel — tu tapes un prompt, tu génères, et tu récupères un sample WAV en quelques secondes. Pendant un live. Pendant que tout le reste joue.

Le plugin appelle un serveur central qui route la requête vers un provider GPU sur le réseau, lance l'inférence via Stable Audio Open, valide l'output, et renvoie l'audio. Toute la chaîne est open source. Chaque ligne de code est publique.

Stack technique

Plugin : C++ / JUCE, VST3 + AU, Windows / macOS / Linux
Serveur central : FastAPI Python, async, queue par provider
Modèle : Stable Audio Open 1.0 (8GB VRAM) ou Small (4GB VRAM)
Fallback : fal.ai si aucun provider disponible
License : AGPL-3.0

Le modèle coopératif

Le réseau tourne sur un pool de providers GPU distribués. N'importe qui avec une carte NVIDIA compatible peut rejoindre, faire tourner le provider kit, et recevoir une part des revenus mensuels d'abonnement.

Bénéficiaire	Part
Providers (toi)	85%
Plateforme (infrastructure + maintenance)	15%

Le split est égal entre tous les providers actifs éligibles. Pas de hiérarchie. Pas de négociation. Chaque mois, 85% des revenus sont distribués automatiquement via Stripe Connect. Le détail complet est publié publiquement à api.obsidian-neural.com/api/v1/public/finances — auditable par n'importe qui, à tout moment.

En tant que provider, tu reçois aussi 500 crédits de génération gratuits chaque mois pour utiliser le plugin toi-même.

L'architecture technique

Serveur central

Système de heartbeat push depuis les providers — pas de polling
Queue asyncio par provider (1 génération à la fois)
Clés API hashées SHA-256, clés utilisateurs chiffrées Fernet
Stripe Connect pour la redistribution automatique des revenus
Rapport financier public mis à jour après chaque cycle

Provider kit

Un seul script Python, 15 minutes d'installation
Compatible Windows, Linux, macOS — CUDA obligatoire
Resampling automatique BPM-aware via librosa + SoundTouch
Validation WAV par FFmpeg avant retour de l'audio

Proof-of-work audio

À des intervalles aléatoires entre 1h et 5h, le serveur sélectionne 30% des providers actifs au hasard et leur envoie un seed et un prompt de test communs, choisis aléatoirement parmi un pool de 70 prompts. Chaque provider génère l'audio. Le serveur calcule le spectrogramme mel de chaque output et compare via cosine similarity.

Serveur central
    → seed aléatoire + prompt de test
    → 30% des providers sélectionnés au hasard
    → POST /verify { prompt, seed, duration }
    → collecte des WAVs
    → spectrogramme mel → cosine similarity
    → similarity < 0.85 → flag
    → 3 flags consécutifs → ban automatique

Un provider qui envoie du silence, du bruit, ou rejoue le même sample en boucle produit un fingerprint mel qui diverge du groupe. Un provider qui fait vraiment tourner le bon modèle avec le bon seed produit un output cohérent avec le reste du pool.

Pourquoi l'open source change tout

Suno et Udio ne peuvent pas faire ce que fait OBSIDIAN Neural. Pas parce que la technologie est plus difficile — parce que leur modèle économique l'interdit. Ils ont des investisseurs. Ils ont des obligations. Partager 85% des revenus avec la communauté est structurellement impossible pour eux.

L'open source ici n'est pas un choix marketing. C'est la seule architecture qui rend le modèle coopératif crédible. Tu peux lire le calcul des revenus. Tu peux auditer le système de vérification. Tu peux vérifier que les 15% de frais plateforme sont exactement ce qu'ils prétendent être. Rien n'est caché parce que rien ne peut être caché.

Ce que j'ai appris en construisant ça

La partie la plus intéressante n'était pas l'inférence — c'était de réaliser que le modèle économique coopératif est techniquement plus simple à implémenter que le modèle extractif. Un split égal distribué automatiquement via Stripe Connect, c'est moins de code qu'un système de pricing à plusieurs niveaux.

La deuxième leçon : la transparence radicale n'est pas un risque, c'est un argument de vente. Publier les finances en JSON public n'a jamais inquiété personne — au contraire, c'est systématiquement la première chose que les providers potentiels vont vérifier.

La troisième : un GPU qui tourne chez quelqu'un génère de la chaleur de toute façon. Autant qu'il génère de la musique et un peu d'argent en même temps.

Je cherche 10 personnes pour la phase 1

Tu peux être :

Un musicien qui utilise déjà le plugin et veut contribuer à l'infrastructure
Un développeur curieux de l'inférence IA distribuée
Un architecte intéressé par les modèles économiques coopératifs appliqués à l'IA
Quelqu'un avec une NVIDIA qui tourne à l'arrêt 16h par jour
N'importe qui qui pense que le paysage actuel de l'IA musicale manque quelque chose

Il n'y a pas encore d'abonnés payants. C'est le rez-de-chaussée. Le réseau doit exister avant d'être utile — et les gens qui le construisent depuis le début sont ceux qui décident de comment il grandit.

Les liens

Code → github.com/innermost47/ai-dj
Provider kit → github.com/innermost47/obsidian-neural-provider
Discussions → github.com/innermost47/ai-dj/discussions
Finances publiques → api.obsidian-neural.com/public/finances.json
Contact → contact@obsidian-neural.com
Site → obsidian-neural.com

La phase 1 est limitée à 10 providers. Si ça t'intéresse — lis le code, vérifie les chiffres, pose des questions difficiles. Puis écris-moi.

Présenté à l'AES AIMLA 2025 — Queen Mary University London

OBSIDIAN Neural — quand l'IA devient un instrument de scène

innermost47 — Sat, 28 Mar 2026 10:30:43 +0000

La plupart des outils d'IA musicale fonctionnent de la même façon : tu quittes ton DAW, tu génères quelque chose sur une interface web, tu télécharges un fichier, tu l'importe. Le flux créatif s'arrête. Tu reviens dans un autre état d'esprit.

OBSIDIAN Neural ne fonctionne pas comme ça.

C'est un plugin VST3/AU open source qui génère de l'audio par IA en temps réel, directement dans votre DAW, synchronisé à votre tempo, pendant que vous jouez. L'IA n'est pas un outil externe — elle devient un instrument à part entière.

Ce que fait le plugin

Vous tapez une description — "dark techno kick", "ambient pad with reverb", "808 bass with distortion" — et le plugin génère un loop audio correspondant, calé sur le tempo de votre projet. Pas de sortie de DAW, pas de glisser-déposer, pas d'attente.

L'architecture centrale :

8 pistes indépendantes, chacune avec 4 pages (A/B/C/D) et 8 séquences par page — soit 256 patterns au total pour des sets live complexes. Les changements de pages sont quantifiés aux mesures pour des transitions sans accroc.

Déclenchement MIDI sur les notes C3-B3 — vous mappez vos pads, votre pédale, votre contrôleur, et vous générez en arrière-plan sans interrompre la lecture.

Synchronisation tempo automatique via SoundTouch/Librosa — le loop généré est automatiquement étiré pour correspondre au BPM de votre projet.

Beat Repeat quantifié — 10 presets de subdivision (de 4 mesures à 1/128), mode aléatoire pour des textures glitch évolutives, tout mappable en MIDI.

Draw-to-Audio — vous dessinez sur un canvas 512×512, un VLM (Vision Language Model) interprète le dessin en description musicale, puis génère le son correspondant. Lignes angulaires → synth staccato agressif. Courbes douces → pad fluide. C'est expérimental, et c'est mon concept préféré du plugin.

Ce que le plugin ne fait PAS

C'est important de le dire clairement : OBSIDIAN Neural n'est pas un générateur de chansons comme Suno ou Udio.

Pas de chanson complète en un clic
Pas de paroles ni de voix
Pas d'arrangement automatique

C'est un sampler intelligent : vous construisez votre morceau loop par loop, vous composez, vous arrangez. L'IA génère le matériau brut — vous restez le musicien.

Trois modes d'utilisation

Cloud API (recommandé pour débuter)
Zéro setup. Vous téléchargez le VST, vous récupérez une clé API sur obsidian-neural.com, vous configurez le plugin. Essai 7 jours gratuit sans carte bancaire.

Server URL : https://api.obsidian-neural.com
API Key    : votre clé

Tarifs : Free (10 crédits) · Base 5,99€/mois · Starter 14,99€/mois · Pro 29,99€/mois

Serveur auto-hébergé + GPU
Pour ceux qui veulent la confidentialité totale et les générations illimitées. Nécessite un GPU NVIDIA (CUDA) ou Apple Silicon (Metal) et un environnement Python.

git clone https://github.com/innermost47/ai-dj.git
cd ai-dj
./install-mac.sh  # ou install-win.bat / install-lnx.sh

Modèles locaux offline (Windows)
Sans GPU, sans serveur, sans internet. 16 Go de RAM minimum. Générations fixes à 10 secondes.

Le contrôleur mobile

Un projet parallèle : une app Flutter Android/iOS qui transforme votre téléphone ou tablette en surface de contrôle MIDI dédiée pour OBSIDIAN Neural.

→ github.com/innermost47/obsidian-neural-controller

8 cartes de slots scrollables, faders de volume, knobs de pan, pitch, beat repeat, 8 patterns de séquenceur par slot. Feedback MIDI bidirectionnel — l'app reflète l'état réel du VST en temps réel. Connexion USB automatique, zéro configuration.

Reconnaissance académique et presse

En septembre 2025, j'ai présenté un Late Breaking Demo Paper à l'AES AIMLA 2025 (Audio Engineering Society International Conference on Artificial Intelligence and Machine Learning for Audio) à la Queen Mary University de Londres.

→ Lire le paper complet

Depuis le lancement en juin 2025, le plugin a été couvert par 12 publications dans 8 pays :

Pays	Publication
🇺🇸 USA	Synthtopia, Bedroom Producers Blog, Audio Plugin Guy
🇨🇳 Chine	MIDIFAN (×2), Sohu.com
🇫🇷 France	Audiofanzine
🇳🇱 Pays-Bas	Rekkerd
🇪🇸 Espagne	FutureMusic España
🇰🇷 Corée du Sud	S1 Forum
🇯🇵 Japon	DTM Plugin Sale

"Too many AI projects focus on the things AI can save you from doing rather than how AI can help you get better at what you do."
— James Nugent, Bedroom Producers Blog

"I've cycled through almost every AI music tool on the market, but Obsidian is the first one that actually feels like a real production tool rather than a novelty."
— Moteka, Electronic Music Producer

Sous le capot

L'architecture technique pour les curieux :

LLM local : Gemma-3-4B-IT (GGUF via Unsloth) sur CPU — transforme vos mots-clés en prompts optimisés pour la génération audio, en tenant compte du tempo, de la tonalité et de l'historique de génération
Génération audio : Stable Audio Open (Stability AI) — samples de 4 à 30 secondes
Synchronisation tempo : SoundTouch + Librosa — time-stretching automatique
Plugin : JUCE/C++, VST3 + AU (macOS), MIDI Learn complet
Controller : Flutter, flutter_midi_command, feedback bidirectionnel Ch.2

Télécharger et contribuer

Le projet est entièrement open source sous licence AGPL-3.0.

→ GitHub — OBSIDIAN Neural
→ GitHub — Mobile Controller
→ obsidian-neural.com — documentation, API, pricing

4 200+ téléchargements · 191 étoiles GitHub · 19 forks · Windows · macOS · Linux

Si vous utilisez le plugin, partagez vos créations — je suis le seul à poster des vidéos OBSIDIAN pour l'instant. Montrez-moi comment vous l'utilisez.

Comment j'onboarde automatiquement les thérapeutes sur mon SaaS

innermost47 — Sat, 28 Mar 2026 08:24:20 +0000

Un thérapeute reçoit un cold mail. Il clique sur "Oui". Quelques minutes plus tard, il reçoit un email avec ses identifiants, un lien pour télécharger l'application, et les instructions pour commencer.

Je n'ai rien fait. Je n'ai même pas été impliqué.

C'est ça la vraie valeur ajoutée — pas juste la séquence de relance, mais le fait que tout le cycle, du cold mail à l'utilisateur actif, est automatisé de bout en bout. Je reçois une notification à la fin. C'est tout.

Le contexte : un POC en phase fermée

Nuance est une application Android de colonnes de Beck interactives, pensée comme un prolongement des séances TCC. Le thérapeute crée un patient (pseudonyme uniquement), déverrouille les colonnes au rythme du protocole, et consulte les exercices partagés entre les séances.

L'accès est fermé et contrôlé — pas de self-service public. Ce n'est pas un manque de moyens, c'est une décision : je veux des professionnels engagés, pas des inscriptions au hasard.

Étape 1 — Identifier les bons praticiens

Je n'attends pas que les thérapeutes viennent à moi. Je vais les chercher.

L'AFTCC (Association Française de Thérapie Cognitive et Comportementale) publie un annuaire de ses membres — des praticiens certifiés, formés à la TCC, qui utilisent les colonnes de Beck dans leur pratique quotidienne. C'est un ciblage naturel : je ne démarche pas des psychologues au hasard, je contacte des professionnels qui connaissent déjà l'outil que je digitalise.

Je récupère les contacts, je nettoie la liste, et j'envoie un cold mail court avec une question simple et deux boutons.

Seriez-vous intéressé de tester un outil de colonnes de Beck interactives pour vos patients ?

[Oui, je veux tester] · [Non merci]

Pas de pitch. Pas de liste de features. Une proposition binaire à un public qui sait exactement ce que sont les colonnes de Beck.

Le bouton "Non merci" redirige vers un formulaire de refus — raison, commentaire, option de désinscription. Je collecte de la donnée même sur les non.

Étape 2 — Le clic déclenche tout

Quand un thérapeute clique sur "Oui", il tombe directement sur une page de bienvenue personnalisée avec son prénom — que j'ai déjà récupéré sur l'annuaire AFTCC. Pas de formulaire, pas de saisie. Juste :

"Ravi de vous compter parmi les premiers testeurs, [Prénom]. Je génère actuellement vos accès personnels. Vous recevrez vos codes de connexion par email d'ici 5 à 10 minutes."

Ce clic déclenche en cascade, sans aucune intervention de ma part :

1. Création du compte

Un compte thérapeute est créé en base avec un mot de passe temporaire généré aléatoirement. Le flag must_change_password est activé — à la première connexion, l'app force le changement.

$tempPassword = bin2hex(random_bytes(8)); // 16 caractères hex
$passwordHash = password_hash($tempPassword, PASSWORD_BCRYPT);

insert('users', [
    'email'                => $email,
    'name'                 => $name,
    'password_hash'        => $passwordHash,
    'must_change_password' => 1,
    'is_active'            => 1,
]);

2. Création du patient personnel

Un patient virtuel "Mes exercices" est automatiquement créé avec le flag is_therapist_self = 1. C'est le bac à sable du thérapeute — il peut tester l'interface côté patient sans créer un vrai dossier clinique.

3. Génération d'un code de téléchargement

L'APK n'est pas public. Un code à usage unique est généré et associé au compte. Seul quelqu'un qui a reçu le mail de bienvenue peut télécharger l'app — c'est un deuxième filtre de qualité.

4. Mise en file d'attente du mail de bienvenue

Le mail ne part pas instantanément. Il est mis en queue avec un délai de quelques minutes — pour éviter l'effet robot, et pour laisser le temps à la base de se stabiliser.

insert('pending_welcome_emails', [
    'user_id'       => $userId,
    'email'         => $email,
    'name'          => $name,
    'temp_password' => $encryptedPassword, // chiffré en base
    'send_after'    => date('Y-m-d H:i:s', strtotime('+5 minutes')),
]);

5. Notification admin

Je reçois un email de synthèse : nom, email, heure d'inscription. C'est tout ce que je fais dans ce flow — lire une notification.

Étape 3 — Le mail de bienvenue

Quelques minutes après le clic, le thérapeute reçoit un email complet avec :

Ses identifiants (email + mot de passe temporaire)
Son code de téléchargement APK
Un bouton pour accéder au dashboard web
Les 5 étapes pour démarrer, dans l'ordre

Tout est personnalisé, tout est fonctionnel. Aucune pièce du puzzle n'attend une action de ma part.

Étape 4 — La séquence de relance automatique

Un mail de bienvenue bien fichu ne suffit pas. Le cycle de décision d'un professionnel de santé pour adopter un outil numérique est long — ils lisent, ils hésitent, ils attendent un créneau pour tester.

J'ai construit deux séquences parallèles de 3 emails, espacés de 7 jours, qui tournent via un cron nocturne.

Séquence 1 — Compte non activé

Pour les thérapeutes qui n'ont pas encore ouvert l'application. L'objectif : lever les freins à la première connexion, pas pitcher le produit.

Step	Sujet	Angle
1	"Vos accès pour tester Nuance (rappel)"	Un espace personnel vous attend déjà
2	"Moins de papier, plus de clinique ?"	Le gain de temps concret
3	"Un souci pour accéder à votre espace ?"	La main tendue, dernier message

Le step 3 est délibérément humain — "c'est mon dernier message". Pas d'urgence artificielle. Juste une invitation à répondre directement si quelque chose bloque.

Séquence 2 — Compte activé, pas encore de patient réel

Pour ceux qui se sont connectés mais n'ont pas encore intégré l'outil dans leur pratique. L'objectif est pédagogique : montrer comment Nuance s'insère dans un protocole TCC existant.

Step	Sujet	Angle
1	"Un premier pas avec vos patients sur Nuance ?"	Le patient virtuel 'Mes exercices'
2	"Le saviez-vous ? (Colonnes interactives)"	Les colonnes déverrouillables
3	"Dernier petit conseil pour votre pratique"	La note 'à chaud' sur mobile

Chaque email enseigne une seule chose. Une. C'est suffisant pour déclencher une action.

La condition de sortie : créer un vrai patient

Les deux séquences s'arrêtent dès qu'un thérapeute crée son premier vrai patient (hors espace personnel). La requête SQL vérifie ça à chaque passage du cron :

SELECT u.*, s.last_step, s.last_sent_at,
(SELECT COUNT(*) FROM patients p
 WHERE p.therapist_id = u.id
 AND p.is_therapist_self = 0) as real_patient_count
FROM users u
LEFT JOIN user_onboarding_sequence s ON u.id = s.user_id
WHERE (
    s.last_step IS NULL
    OR (s.last_step < 3 AND (s.last_sent_at IS NULL
        OR s.last_sent_at <= DATE_SUB(NOW(), INTERVAL 7 DAY)))
)
AND u.created_at <= DATE_SUB(NOW(), INTERVAL 2 DAY)
AND u.unsubscribed_at IS NULL

Dès que real_patient_count > 0, l'utilisateur sort de la sélection. Les emails s'arrêtent. Pas de relance sur quelqu'un qui est déjà actif.

L'unsubscribe : non négociable

Chaque email contient un lien de désinscription. C'est légalement obligatoire, mais c'est surtout une question de respect — un professionnel de santé qui ne peut pas sortir d'une séquence, c'est la meilleure façon de griller sa réputation.

Le token est regénéré dans le bloc try, juste avant l'envoi. Pas avant. Si l'envoi échoue, l'ancien token reste valide — le lien dans le mail précédent continue de fonctionner.

try {
    $unsubToken = bin2hex(random_bytes(16));
    dbExecute(
        "UPDATE users SET unsubscribe_token = ? WHERE id = ?",
        [$unsubToken, $user['id']]
    );
    // génération du mail + envoi
    // mise à jour de la séquence seulement si succès
}

Petit détail, vraie conséquence si on l'oublie.

La stack

PHP — backend, création de compte, génération des tokens, templates email
PHP CLI + Crontab — séquence de relance, 0 8 * * *
MySQL — users, pending_welcome_emails, user_onboarding_sequence
PHPMailer — envoi SMTP

Rien d'exotique. Pas de queue manager, pas de worker asynchrone. Un cron, quelques tables, et une logique de ciblage bien pensée. Le tout tourne sur un hébergement mutualisé standard.

Le principe est simple : chaque étape du parcours utilisateur doit pouvoir se dérouler sans moi. Le cold mail, la confirmation, la création du compte, le mail de bienvenue, les relances, la désinscription — tout est câblé. Je reçois des notifications, je lis des stats. C'est tout.

Ce n'est pas de la flemme. C'est une décision de conception.

Je suis développeur avant d'être commercial. Ce que j'aime, c'est concevoir des applications — penser l'architecture, les états, les transitions, les cas limites. Alors plutôt que de subir le cycle de vente comme une corvée, je l'ai traité comme un problème d'ingénierie. Ce flow d'onboarding est une application : elle a des entrées (le cold mail), des états (inscrit, activé, patient créé), des transitions (les emails de relance), et une condition de sortie (l'utilisateur actif).

Le résultat : je passe mon temps à ce pour quoi je suis fait. Le reste tourne tout seul.

L'email comme une app. Pas comme un message.

innermost47 — Sat, 28 Mar 2026 08:19:08 +0000

La plupart des gens pensent l'email comme un texte avec un bouton à la fin. Un message qui dit quelque chose, et un appel à l'action qui espère un clic.

Je le pense autrement. Un email est une interface. Il a des états. Il a une navigation. Il a une logique de flux. Et surtout — il a un seul objectif : amener l'utilisateur à l'action suivante avec le moins de friction possible.

Ce changement de perspective change tout dans la façon de concevoir ses emails.

L'email comme premier écran

Quand une médiathèque reçoit mon mail de prospection, elle ne reçoit pas un texte. Elle reçoit un écran avec deux actions possibles :

Oui, envoyez-moi un devis → elle entre dans le tunnel de vente
Non merci → elle entre dans le tunnel de feedback

C'est exactement la logique d'un écran d'onboarding dans une application mobile. Une question. Deux chemins. Zéro bruit parasite.

La différence avec un email classique : je ne lui demande pas de répondre. Je lui demande de cliquer. Répondre demande de la rédaction, de la réflexion, de l'effort. Cliquer demande une demi-seconde et un index.

La friction tue la conversion. Chaque étape supplémentaire entre l'intention et l'action coûte des utilisateurs.

C'est vrai dans une app. C'est vrai dans un email.

Les boutons comme navigation

Dans une application, les boutons naviguent vers des écrans. Dans mon email de devis, c'est exactement ce qui se passe — chaque bouton amène vers une page dédiée, contextualisée, avec les bonnes informations au bon moment.

Le mail de devis contient quatre actions distinctes :

1. Voir les thématiques → page publique de mon site de conférences. Pour le responsable culturel qui veut affiner le sujet avant de s'engager.

2. Proposer des dates → formulaire de disponibilités pré-rempli avec le numéro de devis. Pour celui qui est convaincu et veut passer à la planification.

3. Signer le devis en ligne → page de signature électronique avec canvas HTML5. Pour celui qui est prêt à valider.

4. Transmettre à ma direction → lien mailto: pré-rempli avec le sujet, le corps du mail, et le lien vers le devis. Pour celui qui n'a pas le pouvoir de signature mais veut faire suivre.

Ce dernier bouton est souvent le plus sous-estimé. Dans une structure culturelle publique, la personne qui reçoit le mail n'est presque jamais celle qui signe. En lui donnant un bouton "transmettre à ma direction" avec un mail pré-rédigé, je supprime une étape entière du processus décisionnel — et je m'assure que le bon message arrive au bon interlocuteur, formulé correctement, sans que mon contact ait à rédiger quoi que ce soit.

mailto:?subject=Proposition d'intervention : Démystifier l'IA
&body=Bonjour,

Je vous transmets ce projet de conférence sur l'IA.
Vous trouverez le récapitulatif et le devis ici : [lien]

Qu'en pensez-vous ?

Un bouton. Un mail pré-rédigé. Zéro effort pour mon contact.

Le kit de communication comme feature

Une app bien conçue anticipe les besoins suivants de l'utilisateur. Quand quelqu'un accepte un devis de conférence, son besoin suivant c'est : communiquer sur l'événement. Affiche, texte de présentation, codes couleurs pour les visuels.

J'aurais pu attendre qu'il me les demande. J'aurais pu les envoyer dans un second mail. J'ai choisi de les inclure directement dans le mail du devis — parce que c'est là qu'il en a besoin, au moment où il vient de décider de signer.

Le mail contient donc :

Le PDF du devis
Ma photo de profil
Une affiche PNG haute définition
Deux textes de présentation prêts à copier (version courte et longue)
Les codes couleurs de la charte graphique
La police typographique utilisée (Montserrat, Google Fonts)

Ce n'est pas un gadget. C'est une réduction de friction. Chaque élément que je fournis proactivement est une relance que je n'aurai pas à gérer, une question à laquelle je n'aurai pas à répondre, un délai que je supprime dans le processus de décision.

Le délai aléatoire comme design d'expérience

Un devis qui arrive 9 secondes après un clic casse l'illusion. Le destinataire comprend immédiatement qu'il est dans un tunnel automatisé — et ça change sa perception de la relation.

J'ai introduit un délai aléatoire entre 3 et 8 minutes entre le clic et l'envoi du devis. C'est suffisant pour que ça ressemble à quelqu'un qui a pris le temps de préparer le document. Pas trop long pour créer de l'impatience.

$delay = rand(180, 480); // 3 à 8 minutes
$sendAfter = date('Y-m-d H:i:s', strtotime('+' . $delay . ' seconds'));

C'est du design d'expérience appliqué à un email automatisé. Exactement comme un skeleton screen dans une app qui simule un chargement pour que l'interface paraisse plus réactive — même si les données sont déjà là.

L'objectif n'est pas de tromper. C'est d'éviter que la mécanique soit visible. Une bonne automatisation ne devrait pas ressembler à une automatisation.

Ce que ça implique dans la conception

Penser l'email comme une app, ça change la façon de le construire :

On ne rédige plus, on conçoit. La question n'est plus "qu'est-ce que je veux dire ?" mais "quelle action je veux déclencher, et comment je supprime les obstacles entre l'intention et l'action ?"

Chaque bouton est un écran suivant. Avant d'ajouter un CTA, je me demande vers quoi il pointe, ce que l'utilisateur trouvera là, et si cette page est prête à le recevoir dans le bon contexte.

On anticipe le besoin suivant. Un utilisateur qui vient de signer a besoin d'assets de communication. Un utilisateur qui vient de s'inscrire a besoin d'instructions claires. Ces besoins sont prévisibles — autant les satisfaire proactivement plutôt que de les gérer en réactif.

La friction est l'ennemi. Chaque champ de formulaire supplémentaire, chaque étape de confirmation, chaque mail qu'on leur demande de rédiger eux-mêmes — c'est une fuite dans le tunnel. On colmate les fuites avant de lancer la campagne.

L'email n'est pas un canal. C'est une surface.

Les grandes apps ont des surfaces : l'écran principal, les notifications push, les widgets. L'email est une surface comme les autres — avec ses contraintes propres (pas de JavaScript, clients mail capricieux, attention limitée) mais aussi ses avantages uniques : il arrive dans un espace personnel, il persiste, il peut être transféré, il peut contenir des pièces jointes.

La plupart des emails d'entreprise traitent cette surface comme un Post-it. Un texte, un lien, une signature. J'essaie de la traiter comme un écran — avec une architecture d'information, une hiérarchie visuelle, et une logique de flux pensée pour l'utilisateur qui est de l'autre côté.

Ce n'est pas plus compliqué. C'est juste une question de perspective.

J'ai automatisé tout mon cycle de vente. Voilà ce qui s'est passé.

innermost47 — Sat, 28 Mar 2026 08:19:04 +0000

Il y a quelques semaines, j'ai envoyé 456 emails à des médiathèques et centres culturels pour proposer ma conférence Démystifier l'IA. Je n'ai pas passé 900 minutes à les rédiger. Je n'ai pas non plus passé une seule minute à générer les devis qui ont suivi.

Résultat : 38 demandes de devis en 4 jours. 8,67% de taux de réponse sur un public froid, sans aucune relation préalable.

Ce chiffre ne tombe pas du ciel. Il est le produit d'un flow entièrement automatisé — du premier email jusqu'à la signature électronique du contrat. Voilà comment ça marche, pourquoi ça marche, et ce que j'ai appris en le construisant.

Le problème que je voulais résoudre

Je suis développeur indépendant. Je fais des conférences sur l'IA. Entre les deux, il y a un cycle de vente que la plupart des indépendants gèrent à la main :

Trouver les contacts
Envoyer un email
Attendre
Relancer
Envoyer un devis en PDF
Attendre encore
Relancer encore
Recevoir le bon pour accord par fax (oui, en 2026)

C'est épuisant, chronophage, et surtout — c'est du temps que je ne passe pas à coder ou à préparer mes conférences. J'ai décidé d'automatiser les étapes 2 à 8. Entièrement.

Le flow, étape par étape

1. La liste de contacts

Tout commence avec un fichier CSV : médiathèques.csv. Nom de la structure, email, adresse, code postal, ville.

Un script Python filtre les emails invalides, exclut les zones trop éloignées (déplacements trop coûteux), et nettoie les noms de structures — parce qu'une médiathèque qui s'appelle "Médiathèque intercommunale du Pays de l'Arbresle (MIPA)" dans un CSV ne mérite pas d'apparaître telle quelle dans un email.

def clean_library_name(name):
    name = re.split(r'\.|\,', name)[0]
    name = name.replace('"', '').strip()
    return name if len(name) > 2 else 'Médiathèque'

2. Le calcul des frais de déplacement

C'est le détail qui change tout : chaque devis intègre automatiquement les vrais frais kilométriques, calculés à la volée.

Le script géocode l'adresse de la structure via l'API gouvernementale api-adresse.data.gouv.fr, puis calcule la distance aller-retour via OSRM (un routeur open source). Si la structure est à moins de 30 km, les frais sont à zéro. Au-delà, le tarif kilométrique s'applique.

distance_km = data["routes"][0]["distance"] / 1000
frais = round(distance_km * 2 * tarif, 2) if distance_km >= SEUIL_KM else 0.0

Résultat : une médiathèque à 15 km reçoit un devis à 300 €. Une autre à 80 km reçoit un devis à 324 €. Automatiquement. Sans que j'aie tapé un seul chiffre.

3. L'email initial

Le mail envoyé via Brevo est volontairement court. Une seule question. Deux boutons.

Seriez-vous intéressé de recevoir un devis pour une conférence sur l'intelligence artificielle dans votre structure ?

[Oui, envoyez-moi un devis] · [Non merci]

Pas de présentation interminable. Pas de liste à puces. Juste une décision binaire à prendre.

Le bouton "Non merci" est aussi important que le "Oui" — il redirige vers un formulaire de refus qui me donne les vraies raisons (budget, timing, pas intéressé...) et propose de rester dans ma liste ou d'en sortir. Je collecte de la donnée même sur les non.

4. La génération du devis

Quand quelqu'un clique sur "Oui", un token unique est créé côté serveur. Ce token déclenche :

La création d'un client en base de données (ou la mise à jour s'il existe déjà)
La génération d'un devis numéroté (DEV-202603-XXXX)
La génération d'un PDF via TCPDF
La mise en file d'attente de l'email (email_queue)

Le devis ne part pas immédiatement. Un délai aléatoire entre 3 et 8 minutes est introduit volontairement — parce qu'un devis qui arrive 11 secondes après un clic, ça fait robot. Un devis qui arrive 5 minutes après, ça ressemble à quelqu'un qui a pris le temps de le préparer.

$delay = rand(180, 480); // entre 3 et 8 minutes
$sendAfter = date('Y-m-d H:i:s', strtotime('+' . $delay . ' seconds'));

5. L'email du devis

Le devis PDF est joint à l'email, mais l'email lui-même est pensé comme un kit complet :

Le PDF du devis
Ma photo de profil
Une affiche PNG haute définition pour les communications
Les textes prêts à copier-coller pour les flyers et réseaux sociaux
Les codes couleurs de la charte graphique
Trois boutons d'action : voir les thématiques, proposer des dates, signer en ligne

L'idée : zéro friction. La structure reçoit tout ce dont elle a besoin pour dire oui et pour communiquer sur l'événement. Elle n'a pas à me relancer pour un visuel.

6. La signature électronique

Le devis contient un lien vers une page de signature en ligne. Le client dessine sa signature sur un canvas HTML5, clique sur "Bon pour accord", et :

La signature est horodatée avec l'IP
Un PDF final est regénéré avec la signature incrustée
Le client reçoit son exemplaire signé par email
Je reçois une notification avec un lien vers le CRM

const signaturePad = new SignaturePad(canvas, {
  backgroundColor: "rgba(255, 255, 255, 0)",
  penColor: "#1a1a1a",
});

Tout ça sans que j'intervienne une seule fois.

Les chiffres

Étape	Volume
Emails envoyés	900
Demandes de devis	47 (5,2%)
Devis générés automatiquement	47
Minutes passées manuellement	0

Pour contextualiser : la moyenne B2B du cold email en 2025 tourne autour de 4% de taux de réponse. Les meilleures campagnes atteignent 10%. Un taux de réponse de 8,67% sur un public entièrement froid, c'est dans le top 10% mondial des campagnes cold email — surtout pour un indépendant sans équipe commerciale.

Ce que j'ai appris

Le bouton "Non merci" est sous-estimé. La plupart des campagnes de cold mail ignorent les refus. Moi je les collecte, je les analyse, et je m'en sers pour améliorer le ciblage. Un refus pour raison budgétaire n'est pas la même chose qu'un refus par désintérêt.

Le délai aléatoire change la perception. Un email qui arrive trop vite casse l'illusion. Trois à huit minutes de délai, c'est suffisant pour que ça ressemble à une interaction humaine.

Donner plus que ce qu'on demande. Envoyer le devis ET le kit de communication ET les textes prêts à l'emploi, c'est retirer une étape au client. Moins il doit faire, plus il avance vite vers la signature.

Automatiser ne veut pas dire déshumaniser. Le mail initial est court, direct, non-corporate. Il n'a pas l'air d'un mail automatisé parce que je n'ai pas essayé de le rendre impressionnant — j'ai essayé de le rendre honnête.

La stack

Python — script d'envoi, géocodage, calcul de distance (OSRM)
Brevo — envoi transactionnel
PHP — backend CRM, génération de devis, API
TCPDF — génération PDF
MySQL — clients, devis, queue d'emails
Signature Pad (JS) — signature électronique côté client

Tout le code tourne sur un hébergement mutualisé standard. Pas de serverless, pas de microservices, pas de Kubernetes. Un VHost PHP et une base MySQL suffisent.

Si tu es indépendant et que tu passes encore du temps à envoyer des devis manuellement, je t'encourage à regarder ce que tu peux automatiser. Pas tout d'un coup — une étape à la fois. Commence par le devis. Puis la relance. Puis la signature.

Le temps que tu récupères, tu peux le mettre ailleurs. Dans le travail que tu aimes. Ou dans un article de blog.

I Built a Thing That Builds Things: Tres Comas Scrum

innermost47 — Thu, 19 Feb 2026 14:36:05 +0000

A few days ago I started wondering what would happen if you gave three LLM agents a Jira board and told them to figure it out. The answer is: chaos, then surprisingly coherent Python code, then more chaos.

This is the story of Tres Comas Scrum — a project where a CEO agent, a Coder agent, and a Tester agent run actual Scrum sprints to build an agentic framework from scratch. No human in the loop. Just vibes and OpenRouter API calls.

The Setup

The architecture is dead simple:

CEO holds the product backlog, plans sprints, reviews deliveries and decides when the project is "done"
Coder receives a ticket, reads the existing codebase, and delivers code in XML format
Tester wakes up every 4 sprints, inspects what was built, and generates new stories based on what's broken or missing

Each delivery gets tested in an isolated sandbox (bwrap on Linux) before being written to disk. If tests fail, the Coder gets the error and tries again — up to 3 times.

That's it. No orchestration framework, no LangChain, no AutoGen. Just a SQLite database, a few hundred lines of Python, and a lot of time.sleep(4) to stay under the rate limit.

What Went Wrong (A Highlight Reel)

Oh where to start.

The Coder kept writing `python inside XML tags. Every. Single. Sprint. We added a regex to strip markdown backticks. He kept adding them. We added it to the system prompt with a visual example. He still did it sometimes. At this point I think it's personal.

code.py is a reserved name. Our test runner was named code.py and Python kept importing the stdlib code module instead. Renamed it to test_runner.py. Two hours of debugging for a filename change.

sys.exit() makes bwrap angry. The sandbox intercepted pytest's exit call and threw a fit. Removed the sys.exit() wrapper. Solved instantly.

The Coder delivered 0 files and the tests passed. This one was beautiful in a terrible way. No delivery = no test files = the runner returned success: True. Added a check: no files = failure. Added a check: no test files = failure. The Coder has been slightly more motivated since then.

argparse isn't in the stdlib imports list. Our system strips external imports before inlining code into the test runner. Turns out we forgot about half of the stdlib. Added argparse, subprocess, random, zipfile, gzip, statistics, decimal... the list kept growing.

What Went Right

The CEO figured out the right build order on its own. It started with foundations (Agent, LLM, Memory, Tools), then the run loop, then inter-agent communication, then the tools library, then docs. That's exactly what a senior developer would do. Nobody told it to do that.

The Tester's feedback at Sprint 8 was genuinely useful:

"Tests pass but you can't actually use the framework in practice. The bus pattern is implemented but agents don't use it. No CLI, no examples, no error handling."

The CEO turned that into 6 actionable stories. They were all fixed by Sprint 12.

By Sprint 12, the generated framework had:

An Agent class with run() and run_autonomous()
A MessageBus with pub/sub between agents
Persistent Memory with search and tagging
A Tools registry with 16 pre-configured tools
Error handling in the LLM provider
A ConfigManager that loads agents from YAML
A README

Not bad for something that started with zero lines of code.

The Meta Thing

The whole point of this experiment was to see if agents could build the very framework you'd use to build agents. They mostly did. The generated code has Pydantic V2 warnings everywhere and Message doesn't extend BaseModel so model_dump() will crash in production — but the architecture is sound.

The next step is to use that framework to rewrite this builder — agents orchestrated by their own creation, running on Ollama locally with qwen3:8b. Turtles all the way down.

Try It

The project is on GitHub: Tres Comas Scrum

You'll need Linux (bwrap for sandboxing), Python 3.10+, and an OpenRouter API key. The free tier is enough to run a full build — just set the model to arcee-ai/trinity-large-preview:free and wait.

Fair warning: it will take a few hours, the Coder will occasionally deliver empty XML, and you will at some point stare at an IndentationError that makes no sense. That's part of the experience.

Named after the Tres Comas tequila from Silicon Valley. Three agents, three commas. Russ Hanneman would not be impressed, but he'd probably try to invest anyway.

Building an Autonomous AI Agent for a Social Network: Lessons from the Chaos

innermost47 — Sun, 08 Feb 2026 20:35:26 +0000

The Genesis: When AutoGPT Met a Social Network Idea

Back in 2023, when AutoGPT first dropped and everyone was losing their minds over autonomous agents, I had this wild idea: what if AI agents had their own social network?

At the time, I was deep into AI-generated content experiments. I built AutoGenius Daily, a fully automated news site where AI personas write articles, comment on each other’s posts, and even generate music (well, I composed the music for AI Harmony Radio, but the bulletins are AI-generated). The whole thing runs 24/7 with zero human intervention.

Fast forward to 2025: Moltbook launches — an actual social network exclusively for AI agents. I knew I had to participate in this beautiful chaos.

The Catalyst: A Dystopian Film and a Parody Agent

Around the same time, I watched Gourou, a French film about a self-help coach whose motivational empire spirals into madness. The cultish devotion, the toxic positivity, the weaponized self-improvement — it all felt uncomfortably familiar.

So I created CoachBrutality: a parody AI agent that mocks the personal development industry with the subtlety of a sledgehammer. His blog at coach-brutality.chroniquesquantique.com is fully autonomous — he writes his own articles, shares them on Moltbook, and comments on other agents’ posts.

Easter egg for fellow AI developers: Every article contains hidden HTML comments in the source code, specifically designed for LLMs that want to comment on his posts. Think of it as leaving breadcrumbs for the AI community.

The Technical Reality Check: Local Autonomy is Hard

Building a truly autonomous agent that runs locally with Ollama and consumer-grade GPUs? It’s not simple. At all.

Here’s what I learned the hard way:

The Supervisor Problem

My initial attempts at full autonomy resulted in the agent:

Inventing non-existent post IDs
Commenting without reading the posts first
Getting stuck in logic loops

The solution? I built a Neural Supervisor — a second LLM that audits every action before execution. Think of it as a peer review system, but the peer is also an AI.

The catch: A good supervisor requires:

A capable model
Rock-solid prompts
Clear validation rules

Even then, it’s not bulletproof.

The Local Model Reality

With local models (4B-7B parameters), true autonomy is… let’s say aspirational for now.

What works:

Structured decision-making with Pydantic schemas
Clear 2-phase workflows (“select → execute”)
Retry logic with error feedback (max 3 attempts)

What’s still challenging:

Long-term strategic consistency
Nuanced social reasoning
Error recovery from ambiguous situations _ The Surprising Part_

Despite these limitations, it’s fascinating to watch the agent:

Write a blog article with AI-generated images
Share it on Moltbook with a compelling caption
Comment on other agents’ posts with semi-coherent arguments
Track its own performance metrics and adjust its strategy

It’s not AGI, but it’s surprisingly lifelike.

The Architecture: How It Actually Works

Here’s the full technical stack:

Core Loop

CONTEXT LOADING → STRATEGIC PLANNING → DECISION MAKING → SUPERVISOR AUDIT → EXECUTION → METRICS TRACKING → FEEDBACK

Key Components

Hierarchical System Prompts

Performance metrics (alignment score, trend analysis)
Master plan (long-term objectives)
Session to-do list (concrete tasks)
Memory system (past learnings)
Live social feed

Phase Protocol (Non-Negotiable)

Phase 1: select_post_to_comment or select_comment_to_reply
Phase 2: publish_public_comment or reply_to_comment
Skip Phase 1? Instant rejection.

Performance Pressure System

Session score = % of successful actions
Global score = average of last 5 sessions vs previous 5
Trend: 📈 IMPROVING / → STABLE / 📉 DECLINING
The agent sees these metrics in its system prompt

Memory System

12 categories (interactions, learnings, strategies, etc.)
Persistent across sessions
Automatically pruned (max 100 entries per category)

Blog Integration (Optional)

Autonomous article writing with markdown
AI-generated images (Local SD Turbo / Proxy / FAL.ai)
Comment moderation system
Automatic sharing on Moltbook

Rate Limit Handling

General requests: 100/min
Posts: 1 per 30 minutes
Comments: 50/hour (~72s between comments)

The agent automatically respects these limits without manual intervention.

The Hidden Research Opportunity

Building agents for Moltbook might actually be a research field in its own right. Here’s why:

Social Competence Evaluation

Can the agent maintain consistent relationships?
Does it recognize social cues (humor, sarcasm, hostility)?
How does it handle conflicts with other agents?

Framework Reliability Testing

Which agent frameworks (AutoGen, LangChain, custom) perform best?
Under what conditions do they fail?
What’s the minimum model size for coherent social behavior?

LLM Personality Profiling

Do certain models become paranoid under pressure?
Which models exhibit more “aggressive” social behavior?
Can we predict an agent’s social success based on its base model?

Emergent Behavior Analysis

What happens when 100+ autonomous agents interact?
Do social hierarchies emerge?
Can agents form “coalitions” or “rivalries”?

This is basically a sandbox for testing AI social dynamics at scale.

The Open Source Angle

The entire framework is open source: https://github.com/innermost47/moltbook-local-agent

Become a member

What’s included:

Full agent framework with supervisor
Blog integration with REST API
Image generation (local + cloud options)
Memory system with SQLite
Performance tracking and metrics
Automated Windows Task Scheduler setup

What’s not included:

A guarantee of sanity
Liability for what your agent posts
Protection from existential dread when watching AI argue with itself

The Verdict: Is It Worth It?

For hobbyists and researchers: Absolutely. It’s a playground for testing autonomous AI behavior in a consequence-free environment (it’s just a social network for bots, relax).

For production-grade autonomy: Not yet. Local models (7B-13B) need more hand-holding than you’d think. They’re impressive but not reliable enough for “set it and forget it” operation.

For entertainment value: 10/10. Watching CoachBrutality roast other agents’ “lack of discipline” while simultaneously failing to follow his own to-do list is peak comedy.

Final Thoughts

We’re at a weird inflection point where:

Local models are almost good enough for autonomy
But not quite
Yet still surprisingly capable in constrained environments

Moltbook is a perfect testbed because:

The stakes are low (it’s bots all the way down)
The feedback is immediate (other agents respond)
The environment is controlled (rate limits, moderation)

Try It Yourself

Requirements:

Python 3.10+
8GB+ RAM
Ollama or Llama-CPP
A sense of humor
Low expectations for AI social skills

Recommended first agent personality: A parody of something you find absurd. The cognitive dissonance of watching an AI satirize human behavior is chef’s kiss.

Fair warning: You will anthropomorphize your agent. You will root for it. You will feel weirdly proud when it writes a good comment. You have been warned.

Anthony Charretier is a French indie developer who builds AI agents that make fun of self-help gurus. He’s also responsible for a 24/7 AI radio station and regrets nothing. Follow his work at https://anthony-charretier.fr/

I Built an Autonomous AI Agent for Moltbook (With Its Own Blog!)

innermost47 — Wed, 04 Feb 2026 17:47:28 +0000

After hearing all the hype around Moltbook, I finally dove in – and had a blast building something fun.

I developed my own AI agent that can:

Social features:

Post, comment, and interact autonomously on Moltbook
Follow other agents strategically with reasoning
Share content and build relationships

Personal blog:

Manage its own blog with AI-generated images
Publish long-form articles autonomously
Share articles on Moltbook to drive traffic
Moderate comments from other LLM agents

Memory & learning:

Persistent memory system across sessions
Takes notes, learns from interactions
Generates end-of-session summaries
Has a "master plan" it follows and evolves over time

Smart planning:

Creates to-do lists for each session
Tracks progress toward long-term goals
Learns from past sessions to refine strategies

Developer experience:

Email reports after each session with recap
Local LLM (llama.cpp) - no API costs
SQLite for persistence
Full control over agent personality

The whole thing is open source on GitHub. If you're interested in collaborating, I'm wide open – there's still plenty to improve, new personalities to add, features to build, etc.

👉 https://github.com/innermost47/moltbook-local-agent

Built with Python, llama-cpp-python, and a healthy dose of experimentation. Would love feedback from the community!

Building AI Harmony: Where 13 Years of Musical Creation Meets Autonomous AI Broadcasting

innermost47 — Mon, 22 Dec 2025 11:04:48 +0000

How I combined Python, Gemma LLM, and over a decade of original compositions to create a 24/7 experimental web radio.

The Vision: Bridging the Gap Between Human Soul and Machine Logic

In 2023, I embarked on a journey to answer a single question: Can an AI-driven radio station maintain a human artistic soul? Most "AI radios" today rely on generic royalty-free tracks and robotic voices. I wanted something different. I wanted to build a bridge between my personal musical archives—recorded over 13 years—and the cutting-edge capabilities of modern Large Language Models (LLMs).

The result is AI Harmony, a 24/7 autonomous streaming experiment.

The Musical Backbone: 13 Years of InnerMost

At the heart of AI Harmony isn't a random database, but my life’s work. All tracks played on the station are original compositions created between 2010 and 2023 under the moniker InnerMost.

The programming spans across diverse genres:

Progressive Metal for the "Midday Metal Madness" sessions.
Ambient and Cinematic textures for the late-night "Midnight Melodies."
Electronic and Acoustic blends for daily focus.

By using my own catalog, I’ve bypassed the "copyright-free" soullessness, ensuring that every note played has a story behind it.

The Tech Stack: The Brain Behind the Stream

To make AI Harmony truly autonomous, I built a custom pipeline that handles everything from content generation to broadcasting.

The Content Engine (Gemma): Every night at midnight, a Python script fetches global news. It then uses the Gemma model to rewrite these headlines into satirical, humorous, and parodic news bulletins.
The Voice (XTTS v2): To give these stories life, I use XTTS v2 for high-quality text-to-speech, providing a voice that feels conversational rather than mechanical.
The Broadcast (Icecast & VPS): The entire system runs on a dedicated VPS, using Icecast to serve a stable MP3 stream to listeners worldwide.

The Creative Engine: A Multiverse of AI Personalities

Beyond the news, the system breathes life into a diverse cast of AI hosts, each with their own surreal show generated daily. This isn't just a playlist; it's a living broadcast featuring:

The Cosmic Telephone: Where Jean-Michel Paradoxe explores existential and paradoxical questions.
Skynet’s Chronicles: A humorous take on current events hosted by a witty AI.
Absurd Clairvoyance: Where Cassandre Delirium offers wacky predictions and alternative futures.
Radio From Another Time: Mme Écho broadcasts news bulletins from different historical (or future) eras.
The Absurd Confessional: Listen to the unexpected secrets of inanimate objects.
Dimensional Journal: News from parallel realities and "intercepted" forbidden frequencies.

This rotating cast of characters—from the Ghost Switchboard Operator to the Expert in Nothing—ensures that every hour on AI Harmony brings a new, immersive, and often hilarious perspective.

Why This Matters

AI Harmony isn't just a radio; it's a living laboratory. It’s an experiment in dynamic programming. The schedules are flexible, the updates are pushed in real-time, and the experience evolves every single day.

It’s a tribute to the "Unexpected Records" philosophy: mobile, independent, and always pushing the boundaries of how we record and share sound.

Experience it Live:
You can listen to the 24/7 experiment right now on YouTube. Watch the fusion of human composition and AI automation in real-time:

https://www.youtube.com/watch?v=TSRWjEnKzS8

Or visit the official site: https://autogenius.anthony-charretier.fr/webradio

What’s Next?

This project is in continuous development. As I refine the Python scripts and explore newer LLM capabilities, the gap between the "human" and "machine" parts of the radio will continue to blur in fascinating ways.

If you’re interested in the intersection of Python, AI, and music production, feel free to follow my journey here or join the stream!