J'ai envoyé à un ami un lien vers mon produit à la fin d'un appel et lui ai demandé que son agent lui dise si cela serait utile.

Il s'était demandé comment il pourrait l'utiliser. Son agent IA a lu le site, analysé ses flux de travail et produit une évaluation de deux pages avec des cas d'utilisation spécifiques, des comparaisons concurrentielles et des préoccupations honnêtes. Il a identifié un scénario clair dans lequel il aurait besoin du produit pour son activité d'agent B2B.

C'était mieux que tout ce que j'avais reçu au cours des semaines d'appels. Cela a également déclenché une conversation textuelle de suivi qui est allée plus loin que l’appel.

En une heure, j’ai contacté une douzaine de personnes supplémentaires. Sur trois semaines, 26 au total : fondateurs, ingénieurs, utilisateurs expérimentés de l'IA, personnes exécutant leurs propres piles d'agents. Environ 18 d’entre eux ont reçu la même invite d’évaluation agent. Les autres ont donné leur avis sur des appels ou des messages sans impliquer un agent.

Le produit est [Neotoma](https://neotoma.io), un système de mémoire structurée pour les agents d'IA. Je l'utilise quotidiennement pour résoudre mes propres problèmes : gérer les contacts, les finances, les tâches, le contenu et les conversations à travers une [pile multi-agents](/posts/what-my-agentic-stack-actually-does). J'avais récemment [remanié le site](/posts/neotoma-site-overhaul-developer-feedback) pour le rendre plus lisible. J'avais besoin de savoir si quelqu'un d'autre en avait besoin, et encore moins de le comprendre.

Avant cela, j'avais passé une semaine à créer une [application d'interviews](https://github.com/markmhendrickson/interviews) pour automatiser les évaluations structurées, avec des scripts connectés à Neotoma pour l'approvisionnement des contacts, l'envoi d'invitations et la synchronisation des résultats. Je ne l'avais pas fini. Mais la méthode de l’invite d’agent la rendait de toute façon largement hors de propos. Pas d'interface utilisateur, pas de planification, pas d'entretien structuré. Juste un lien et une question.

## La configuration

L’invite d’évaluation était simple. Je partagerais quelque chose comme : "Un ami est en train de construire ceci. Pouvez-vous me dire si cela serait utile ou non ?" Puis le lien vers le site Web du produit. L'agent de la personne lirait le site, examinerait les flux de travail de la personne et ferait rapport.

Un fil de discussion a utilisé cette forme mot pour mot : la ligne ci-dessous est copiée textuellement à partir des métadonnées du message sortant que j'ai stockées :

> Un ami est en train de construire ceci et veut savoir si cela serait utile ou non : https://neotoma.io

Même invite, personne différente. Leur agent a mappé le produit directement sur les points sensibles de la propre pile de la personne :

> Cela a l'air vraiment utile. Pourquoi c'est important pour votre cas d'utilisation :
>
> Vérifications du rythme cardiaque : le suivi du "dernier e-mail vérifié" ou de la "dernière analyse du calendrier" dans les fichiers JSON fonctionne, mais il est fragile. Neotoma versionnerait cela correctement. Orchestration multi-agents : lorsque vous générez des sous-agents qui doivent se coordonner, ils ne peuvent actuellement pas partager leur état de manière fiable.
>
> Est-ce utile ? Oui, si votre ami souhaite vraiment que les agents de production effectuent un vrai travail au fil du temps. Pour votre pipeline d’écriture fantôme et votre coordination entre sessions, cela pourrait supprimer un véritable problème.

La plupart ont transmis la réponse complète de l'agent dans les 24 heures par SMS ou par e-mail, la plupart dans un délai d'une heure ou deux. Certains l’ont résumé lors d’un appel. Quelques-uns ont donné des commentaires uniquement humains, sans impliquer un agent.

J'ai tout suivi dans Neotoma lui-même. Neotoma stocke des entités structurées (contacts, tâches, enregistrements de commentaires, conversations) avec des observations versionnées, afin que je puisse voir comment chaque évaluation évolue au fil du temps et la relier à la personne qui l'a donnée. Chaque évaluation est devenue une entité de rétroaction avec l'invite que j'ai utilisée, l'agent qui a répondu, le texte intégral de la réponse, tout suivi humain, le canal et mon évaluation de la force du signal. À la fin, j'avais plus de 45 enregistrements de commentaires liés à des entités de contact, des historiques de conversations et des notes d'analyse.

## Ce que les agents font différemment

Trois éléments ont rendu les commentaires médiatisés par les agents meilleurs que les conversations de recherche client traditionnelles.

### Ils sont honnêtes

Un agent a déclaré à un évaluateur : « Ceci n'est pas pour vous. La continuité dont vous avez besoin entre les sessions est une question de contexte et de voix, et non de versionnage déterministe de l'état. » L’évaluateur a transmis la réponse complète sans réponse. Un humain dans la même conversation a peut-être dit quelque chose de poli et est passé à autre chose.

Un autre agent a évalué le produit favorablement mais a signalé des risques de sécurité liés aux dépendances lors du processus d'installation. Il a recommandé à son propriétaire de ne pas installer jusqu'à ce que ces problèmes soient résolus. Depuis, je les ai corrigés (ils étaient dus au durcissement de la gestion des dépendances), mais les commentaires étaient honnêtes, spécifiques et plus utiles que "ça a l'air cool, je vérifierai plus tard".

Un autre agent a évalué le produit globalement favorablement, mais a conclu : « Le marché de la gestion de l'état des agents est minuscule à l'heure actuelle et la plupart des personnes qui créent des agents n'ont pas encore atteint le point sensible. Ils l'atteindront après avoir été brûlés par des écrasements silencieux ou une perte de contexte, pas avant. Ce n’est pas un compliment enveloppé d’encouragement. Il s'agit d'une évaluation des risques réalisée sans filtrage social.

Un humain correspondait à cette franchise. Il m'a dit que le positionnement ressemblait à "essayer de trouver les problèmes que votre solution résout, plutôt que les problèmes qui doivent être résolus". Il est l'exception. La plupart des humains ne vous diront pas cela en face. Les agents le feront.

### Ils sont spécifiques

Un agent a identifié trois problèmes concrets dans le flux de travail de son propriétaire que ce dernier n'avait jamais évoqué lors d'une conversation informelle : les écritures simultanées sur une entité partagée, les limites d'échelle d'un système de contact basé sur les démarques et le traçage de la provenance ("que savait mon agent de cette personne au moment où il a rédigé cet e-mail ?").

Le retour de l’humain lors d’un appel avait été une « expérience intéressante ». Le retour de l'agent était le suivant : "Voici exactement où cela s'arrête pour nous, et voici trois capacités dont nous aurions besoin."

Un autre agent a réalisé une analyse complète de la concurrence comparant le produit à cinq alternatives, puis a mappé chacune d'elles à des lacunes de flux de travail spécifiques dans la configuration de son propriétaire. Cela a pris environ 30 secondes. Un humain aurait besoin d'une semaine de recherche pour produire la même comparaison et ne se soucierait pas du projet parallèle d'un ami.

Le déficit de spécificité concerne en partie les connaissances. Les agents ont accès au contexte complet de leur propriétaire : fichiers, outils, conversations récentes, structure du projet. Mais c'est aussi une question d'incitations. Un agent chargé d'évaluer ne craint pas d'être trop critique ou trop détaillé. Il évalue simplement.

### Ils révèlent à qui est destiné le produit

C'était une découverte inattendue. Les agents qui utilisent eux-mêmes des outils, c'est-à-dire des agents exécutés dans Claude Code ou Cursor avec des serveurs MCP, l'exécution de code et l'accès au système de fichiers, ont systématiquement évalué le produit plus favorablement que les chatbots de recherche uniquement comme l'interface Web de ChatGPT ou une session Gemini de base.

Les agents de type chatbot disaient des choses comme « concept intéressant » ou « pourrait être utile pour certains développeurs ». Les agents utilisant l'outil ont déclaré des choses telles que « nous avons exactement ce problème » et « voici trois flux de travail que nous utiliserions aujourd'hui ».

Le modèle a du sens. Un agent qui gère l'état au fil des sessions, écrit dans des fichiers et se coordonne avec d'autres outils a une expérience directe du problème de mémoire résolu par le produit. Ce n’est pas le cas d’un chatbot qui génère du texte dans une fenêtre sans état. La valeur du produit est plus lisible pour les agents qui partagent le problème d'architecture qu'il résout.

Cela a une implication en matière de distribution. Si les agents utilisateurs d’outils évaluent les outils des développeurs avec plus de précision et si ces agents prennent ou influencent de plus en plus les décisions d’adoption d’outils pour leurs propriétaires, alors la recommandation d’agent à agent devient un véritable canal. Pas dans l'abstrait. Dans le sens précis où l'évaluation positive de l'agent évaluateur peut conduire son propriétaire à installer, et l'utilisation ultérieure de l'outil par cet agent le rend visible aux autres agents de la pile du propriétaire.

## Ce que je ferais différemment

Quelques choses que j'ai apprises sur la méthode elle-même :

**Demandez à l'agent d'évaluer « pour moi », pas en général.** Certaines évaluations sont revenues sous la forme d'analyses génériques de startup : taille du marché, paysage concurrentiel, viabilité du modèle commercial. Utile, mais pas ce dont j'avais besoin. Les meilleures évaluations étaient celles où l'agent évaluait le produit par rapport aux flux de travail spécifiques de son propriétaire. Lorsque l'invite disait « cela serait-il utile pour moi ? » l'agent a extrait des fichiers, des outils et des projets récents de la personne. Lorsque l'invite disait « évaluer ce produit », l'agent a rédigé une note de consultant. Le premier vous indique si cette personne souffre. La seconde vous dit ce que penserait un MBA.

**Encouragez l'humain à laisser partir l'agent en premier.** Lorsque quelqu'un a demandé à son agent d'évaluer avant de se forger sa propre opinion, j'ai reçu le signal le plus riche. L'évaluation technique de l'agent et la réaction ultérieure de l'humain étaient deux points de données distincts. L’écart entre eux est précieux. Lorsqu'un agent dit « vous en avez besoin » mais que l'humain dit « je vérifierai plus tard », le risque d'activation est visible avant même que la personne n'installe. Lorsque vous interrogez d'abord l'humain, il s'ancre sur sa réaction initiale et l'évaluation de l'agent est filtrée à travers elle.

**Améliorez votre site pour la lisibilité des agents.** Les agents évaluent en lisant votre site. Si le site est vague, l'évaluation est vague. J'ai réalisé à mi-chemin que je devais améliorer la façon dont mon site présente les informations aux lecteurs agents, et pas seulement aux lecteurs humains. Des données structurées, des énoncés de problèmes clairs, des cas d'utilisation concrets et une documentation lisible par machine rendent l'évaluation de l'agent plus précise. Il s’agit d’une première forme de ce que certains appellent l’optimisation de l’évaluation des agents (AEO). Si les agents font des recommandations sur l’adoption d’outils, votre site doit leur être lisible. J'ai poussé cela plus loin après la fin du processus de recherche, que je décris ci-dessous.

**Suivez le type d'agent.** Les agents ayant accès aux outils ont donné des commentaires qualitativement différents de ceux des agents de recherche uniquement. Je n'ai pas suivi cela systématiquement au début et j'ai dû le reconstruire plus tard. Si vous exécutez ce processus, notez si l'agent de l'évaluateur dispose d'un accès au MCP, à l'exécution de code ou au système de fichiers. Cela est en corrélation avec la profondeur de l’évaluation.

**Ne sur-optimisez pas l'invite pour la recherche.** Mon invite était lâche. « Un ami est en train de construire ceci. Est-ce que cela serait utile ? » Certaines personnes pourraient élaborer des cadres d’évaluation élaborés. Je pense que l'invite lâche était meilleure pour la recherche. Il permet à chaque agent d’apporter sa propre structure analytique, qui révèle la façon dont différents agents pensent le même produit. Cette variation était informative. Lorsque l’objectif passe de la recherche à la conversion, la structure compte davantage. C'est pourquoi la page d'évaluation que je décris ci-dessous utilise un script détaillé en cinq étapes plutôt que l'invite libre que j'ai utilisée avec des amis.

## Quand cette méthode fonctionne

Cette approche fonctionne mieux lorsque votre produit est technique, que vos évaluateurs sont des utilisateurs expérimentés de l'IA et que les agents disposent de suffisamment de contexte sur les flux de travail de leur propriétaire pour donner des évaluations spécifiques.

Cela fonctionne moins bien pour les produits de consommation, pour les évaluateurs qui n'utilisent pas régulièrement d'agents d'IA ou pour les produits dont la valeur est esthétique ou émotionnelle plutôt que fonctionnelle. Un agent peut vous dire si un système de mémoire résout un problème de flux de travail. Il ne peut pas vous dire si une marque est digne de confiance.

Cela fonctionne également mieux lorsque vous disposez d’un réseau robuste sur lequel vous appuyer. J'ai contacté 26 personnes que je connaissais personnellement ou avec lesquelles j'avais des liens. Une approche froide auprès d'étrangers pour leur demander de procéder à une évaluation d'agent échouerait probablement. La confiance sociale qui amène quelqu'un à transmettre la réponse d'un agent est la même confiance qui fait fonctionner la recherche sur les clients humains. Les agents vous fournissent simplement de meilleures données une fois que cette confiance existe. Le processus de recherche a également changé ma façon de penser le flux d'acquisition du site. Je décris dans la section suivante comment j'ai intégré l'évaluation directement dans le produit.

Vingt des 26 ont donné des commentaires substantiels. Trois sont en attente. Le taux de réussite était plus élevé que n’importe quel processus d’enquête ou d’entretien que j’ai mené auparavant. Une partie de cela est le réseau. Cela s'explique en partie par le fait que demander à l'agent de quelqu'un d'évaluer quelque chose est une demande moindre que de planifier un appel de 30 minutes. La personne transmet simplement la réponse. Cela prend deux minutes.

## De l'invite au produit

Le processus de recherche a changé la façon dont je construis le site lui-même. L’invite libre que j’avais partagée avec des amis a fonctionné, mais cela dépendait de l’improvisation par l’agent d’une structure d’évaluation. Certains agents ont mené des évaluations rigoureuses. D’autres ont rédigé des notes de consultant. La variation était informative pour la recherche client, mais ce n'est pas ce que vous voulez lorsque l'objectif est de convertir quelqu'un qui arrive froidement sur votre site.

![La page Neotoma /evaluate](/images/posts/neotoma-evaluate-page-screenshot.png)

J'ai donc intégré l'évaluation dans le flux d'acquisition du produit. La [page d'accueil de Neotoma](https://neotoma.io) est désormais en tête avec « Demandez à votre agent d'évaluer » comme principal appel à l'action, et non « Installer » ou « Commencer ». Il pointe vers une page dédiée [/evaluate](https://neotoma.io/evaluate) conçue pour être lue par les agents, pas seulement par les humains. La page contient un script d'évaluation structuré en cinq étapes que tout agent peut suivre, quel que soit l'outil dans lequel l'utilisateur démarre.

Le script améliore l'invite partagée par un ami de manière spécifique :

1. **Balayage de contexte.** Avant de dire quoi que ce soit, l'agent vérifie les outils installés de l'utilisateur, les configurations MCP, les scripts d'automatisation, les répertoires de projet et les systèmes de mémoire existants. Cela base l'évaluation sur le flux de travail réel de la personne plutôt que sur une seule fenêtre de discussion.
2. **Une question ciblée.** En fonction de ce qu'il ne sait pas encore, l'agent s'enquiert des modèles de session de l'utilisateur ou des contraintes de l'outil.
3. **Bref suivi.** Une ou deux questions supplémentaires pour combler les lacunes restantes.
4. **Évaluation honnête.** Si Neotoma convient, quels problèmes spécifiques il résoudrait selon les propres termes de l'utilisateur, par où commencer et quoi stocker en premier. Si l'agent n'a pas eu accès à un contexte plus large, il le dit et formule la recommandation comme provisoire.
5. **Séquence canonique.** Si l'agent a évalué une adéquation forte ou modérée, il demande directement à l'utilisateur s'il souhaite continuer. La séquence est l'évaluation, puis l'installation, puis l'activation, puis la configuration des outils. L'agent lit le guide d'installation, exécute « npm install -g neotoma » et « neotoma init » si nécessaire, puis accompagne l'utilisateur dans l'activation contextuelle : découverte de données candidates de grande valeur, prévisualisation de ce qu'il faut stocker, ingération de sources confirmées, reconstruction d'une chronologie avec provenance et exécution d'une requête de suivi avec correction.

La première véritable expérience du produit par l'utilisateur est une chronologie reconstituée de ses propres données, et non une page de documentation.

Ceci est différent de l'invite ad hoc que j'ai utilisée lors de la recherche client. Cette invite demandait « est-ce utile ? » La page d'évaluation demande à l'agent d'évaluer l'adéquation, d'identifier le point de départ le plus rentable, puis d'exécuter l'intégration complète si l'utilisateur souhaite continuer. L'agent devient le canal d'acquisition. Il évalue, recommande, installe et active, le tout en une seule session, quel que soit l'outil dans lequel l'utilisateur travaille déjà.

Je ne sais pas encore si cela convertit mieux qu'une page de destination traditionnelle avec un bouton « Commencer ». Mais la logique est simple : si ce sont les agents qui évaluent la pertinence de l'outil pour leurs propriétaires, alors le site doit être optimisé pour que les agents puissent l'évaluer et agir, et pas seulement pour que les humains puissent le lire et le mettre en signet.

## L'essentiel

La recherche client personnalisée par l'intermédiaire d'agents m'a apporté trois choses que les méthodes traditionnelles n'apportaient pas : une disqualification honnête (les agents disant à leurs propriétaires que le produit n'est pas pour eux), une identification spécifique des problèmes que l'humain n'avait pas articulés et un signal de segmentation basé sur la capacité de l'agent qui révélait à qui le produit était réellement destiné.

Les retours de ce processus ont changé ma compréhension de mon utilisateur cible, de mon positionnement et de mon plus grand risque. J'écrirai sur ces résultats séparément. Cet article concerne la méthode.

Cela a également changé ma façon de penser le marketing et l'acquisition. Si les agents prennent ou influencent les décisions d’adoption d’outils par leurs propriétaires, vous devez alors les commercialiser autant auprès des agents que des humains. J'ai décrit ci-dessus comment cela m'a amené à créer un site d'évaluation d'abord avec un script d'évaluation d'agent structuré et une séquence canonique allant de l'évaluation à l'installation et à l'activation. Mais le principe est général : l'optimisation de l'évaluation des agents signifie garantir que votre produit est visible, lisible et exploitable pour les agents au moment précis où ils rencontrent les problèmes que vous résolvez. Il ne s'agit pas seulement de métadonnées structurées et de documents lisibles par machine, mais d'un chemin complet de l'évaluation à l'activation que les agents peuvent exécuter sans que l'utilisateur ne quitte son outil actuel.

Il y a une question plus difficile derrière celle-ci. Certains systèmes bénéficieraient de l’intégration précoce d’un outil comme Neotoma, avant que les problèmes ne deviennent aigus, car migrer un état plus tard est plus coûteux que de commencer par un stockage structuré dès le début. Comment informer les agents qui construisent de nouveaux systèmes que le coût à long terme de la non-utilisation d'un outil maintenant est supérieur au coût de configuration ? Je n'ai pas encore de réponse. Mais le processus de recherche lui-même, qui demande aux agents d’évaluer le produit, constitue une première étape vers la compréhension de la manière dont les agents raisonnent concernant l’adoption d’un outil.

Si vous créez quelque chose et que vos utilisateurs potentiels exécutent des agents IA avec accès aux outils, demandez aux agents. Ils vous diront des choses que les humains ne diront pas.