De l'interface de chat à la plateforme d'agent

Chaque plateforme commence comme une fonctionnalité

Google a commencé comme une boîte de recherche. Slack a commencé comme une salle de chat. AWS a commencé comme une location de serveurs.

LikeClaw a commencé comme une interface de chat. Vous tapiez un message. Une IA répondait. C’était tout.

Quatre-vingt-quatre jours plus tard, c’est une plateforme d’agents autonomes avec exécution en bac à sable, support multi-modèle, un marché de compétences, planification de tâches en arrière-plan, et un pipeline CI auto-réparateur.

C’est l’histoire de cette évolution — non pas comme une feuille de route planifiée, mais comme une série de décisions architecturales, chacune ouvrant des portes que nous ne savions pas qu’elles existaient.

Étape 1 : Chat (21-22 novembre)

Les deux premiers jours ont produit une interface de chat. Pas un jouet. Un vrai système de chat avec :

• Gestion des sessions (plusieurs conversations, chacune préservée)
• Réponses en streaming (les tokens apparaissent en temps réel)
• Changement d’agent (différentes personnalités IA pour différentes tâches)
• Intégration du système de fichiers (l’IA peut lire et écrire des fichiers)

À ce stade, LikeClaw était un meilleur ChatGPT. Même modèle d’interaction — l’humain demande, l’IA répond — mais avec des fichiers persistants et des agents spécialisés.

Ce qui a fait que cette fondation a fonctionné pour tout ce qui est venu après : la séparation entre la couche de chat et la couche d’agent. L’interface utilisateur de chat ne savait ni ne se souciait de ce que l’agent faisait en arrière-plan. Elle affichait simplement des messages. Cela signifiait que nous pouvions rendre les agents beaucoup plus capables sans toucher au code de chat.

Étape 2 : Espace de travail (22-28 novembre)

À la fin de la première semaine, nous avions des espaces de travail. Un espace de travail est un environnement persistant : conversations, fichiers, agents, paramètres, tous regroupés ensemble.

Cela semble simple. C’était en réalité la décision architecturale la plus importante du projet.

Sans espaces de travail, chaque conversation est éphémère. L’IA ne se souvient pas du contexte entre les sessions. Les fichiers ne sont pas organisés. Il n’y a pas de concept de “projet sur lequel je travaille.”

Avec des espaces de travail, les utilisateurs créent des contextes durables. Un espace de travail “Marketing” a des fichiers marketing, des agents marketing, et un historique de conversations marketing. Un espace de travail “Développement” a des fichiers de code, des agents de codage, et des conversations techniques. Chaque espace de travail est un monde.

L’idée clé : les espaces de travail sont l’unité de contexte. Tout le reste — agents, fichiers, plannings, paramètres — vit à l’intérieur d’un espace de travail. Cela a rendu les fonctionnalités ultérieures triviales à définir. “Ajouter la planification” est devenu “ajouter la planification par espace de travail.” “Ajouter des paramètres” est devenu “ajouter des paramètres par espace de travail.” La limite de l’espace de travail contenait la complexité.

Étape 3 : Multi-agent (12-27 décembre)

Le deuxième mois a apporté l’explosion des agents. Au lieu d’une personnalité IA, nous avons construit des agents spécialisés :

• Agent de chat : Conversations généralistes avec conscience des fichiers
• Agent UX : Axé sur le design avec intégration de Perplexity pour la recherche
• Agent PM : Gestion de projet avec capacités de délégation de tâches
• Agent Studio : Travail créatif avec outils de génération d’images
• Maître de l’image : Spécialisé dans la création de contenu visuel

Chaque agent a son propre prompt système, ses propres outils, et sa propre personnalité. Le composant de l’interface de chat n’a pas changé — il affichait toujours simplement des messages. Mais les agents derrière sont devenus beaucoup plus capables.

Le gain architectural : les agents sont une configuration, pas du code. Ajouter un nouvel agent ne nécessite pas de changer la plateforme. Cela nécessite de définir un prompt système, de sélectionner des outils, et de configurer le comportement. Nous stockons les agents dans la base de données. Les utilisateurs peuvent éventuellement créer les leurs. La plateforme ne se soucie pas du nombre d’agents existants ou de ce qu’ils font.

Étape 4 : Autonome (2 décembre - 31 janvier)

C’est là que les choses sont devenues intéressantes. Chaque étape précédente supposait qu’un humain était assis devant un clavier, regardant l’IA travailler. L’étape 4 a supprimé cette hypothèse.

La planification est venue en premier. Les utilisateurs définissent des tâches qui s’exécutent selon un calendrier. L’IA se réveille, charge l’espace de travail, exécute la tâche, enregistre les résultats, et notifie l’utilisateur. Aucun humain présent.

Les tâches en arrière-plan sont venues ensuite. Pendant une conversation, l’IA peut déléguer un travail de longue durée à un agent en arrière-plan. “Analyse ce code” peut prendre 20 minutes. L’utilisateur n’a pas besoin d’attendre. L’agent en arrière-plan fonctionne dans son propre bac à sable E2B, et les résultats apparaissent quand ils sont prêts.

L’architecture orientée événements a tout relié. Chaque action — tâche terminée, fichier créé, agent terminé — génère un événement. Les événements apparaissent dans la boîte de réception de l’utilisateur. Les événements déclenchent des notifications. Les événements sont le tissu conjonctif entre les agents autonomes et les humains qui les gèrent.

La partie difficile n’était pas de construire les fonctionnalités. C’était de repenser les hypothèses. Quand un utilisateur est présent, les erreurs peuvent être affichées dans une boîte de dialogue. Quand aucun utilisateur n’est présent, les erreurs doivent être capturées, enregistrées, et affichées plus tard. Quand un utilisateur regarde, le progrès partiel est informatif. Quand personne ne regarde, seul le résultat final compte.

Étape 5 : Plateforme (1-13 février)

L’évolution finale : d’un produit que nous contrôlons à une plateforme qui s’étend elle-même.

Les bacs à sable E2B ont rendu l’exécution sûre et évolutive. Chaque tâche s’exécute en isolation. Nous pouvons exécuter une centaine de tâches simultanément sans qu’elles interfèrent les unes avec les autres.

Le marché des compétences permet aux utilisateurs (et éventuellement aux tiers) de créer des paquets d’automatisation réutilisables. Les compétences sont examinées pour la sécurité avant publication — contrairement aux marchés ouverts avec des problèmes de sécurité documentés.

Le CI auto-réparateur signifie que la plateforme corrige littéralement ses propres bugs. Claude lit les problèmes GitHub, écrit des corrections, crée des PR, et révise le code. Le processus de développement est partiellement automatisé.

Le cadre d’évaluation mesure la qualité des agents de manière systématique. Nous ne faisons pas que espérer que les agents fonctionnent bien — nous le mesurons à travers des dizaines de scénarios et suivons la qualité au fil du temps.

Le schéma derrière l’évolution

En regardant en arrière, le schéma est clair : chaque étape a élargi les frontières de ce que signifie “agent IA”.

Étape 1 : L’IA répond à l’entrée humaine.
Étape 2 : L’IA travaille dans des contextes durables.
Étape 3 : L’IA se spécialise pour différentes tâches.
Étape 4 : L’IA travaille sans supervision humaine.
Étape 5 : L’IA étend la plateforme elle-même.

Aucune de ces étapes n’a nécessité de réécrire les précédentes. L’interface de chat de la première semaine fonctionne toujours. Le modèle d’espace de travail de la deuxième semaine organise toujours tout. Le système d’agents du deuxième mois alimente toujours toutes les interactions.

Une bonne architecture ne consiste pas à prédire l’avenir. Il s’agit de construire des fondations qui peuvent soutenir un avenir que vous n’avez pas encore imaginé.

Nous avons commencé avec une interface de chat. Nous avons terminé avec une plateforme. Et la fondation que nous avons construite le premier jour est toujours là pour tout soutenir.