Un post sur The Beach montre un agent complet écrit en 100 lignes de Common Lisp : boucle récursive, appel au modèle, exécution des tools. Aucune dépendance au-delà de HTTP et JSON. L’ensemble de la boucle tient en 8 lignes : cas de base (le modèle répond), cas récursif (il veut des tools, les exécute, rappelle). L’état de l’agent n’est que l’argument qui traverse la récursion.

Pourquoi ça te concerne : si tu as suivi les leçons du cours sur le premier agent ou si tu as téléchargé les scaffolding minimalistes, cette implémentation est le squelette nu de ce qu’il y a dessous. Le tool est unique : eval. Le modèle écrit du code Lisp sous forme de chaîne, l’agent l’exécute et retourne le résultat. Pas de catalogue de tools, pas de framework : le langage lui-même devient l’interface. Pour Fibonacci(30), le modèle a écrit la fonction récursive, l’a exécutée avec eval, et a retourné 832040. Deux appels, zéro prompts préconfigurés.

C’est une expérience en sandbox (eval ouvert est un risque de sécurité clair), mais l’idée est instructive : Lisp est homoïconique (le code est fait de la même structure de données que le programme), donc un programme peut construire et modifier d’autre code comme s’il s’agissait d’une liste d’épicerie. C’est la propriété qui, il y a 25 ans, rendait Lisp « le langage de l’IA symbolique ». Aujourd’hui, cette promesse se matérialise différemment : le modèle génère le code, Lisp l’exécute, et la boucle récursive tient tout ensemble. 114 points sur Hacker News indiquent que l’idée a fait mouche.

En détail

Le contexte

Aux alentours de 2000, Lisp était considéré comme le langage de l’intelligence artificielle symbolique : systèmes experts, démonstrateurs de théorèmes, programmes qui manipulaient des symboles et des règles. Puis les méthodes statistiques ont gagné, le deep learning les a enterrées, et Lisp est devenu une curiosité historique pour la plupart des développeurs. L’auteur du post raconte avoir appris Lisp dans un cours d’IA à l’Université de Guelph, sans jamais le voir utilisé après.

Aujourd’hui, il construit une plateforme d’agents IA et se demande : Lisp pourrait-il encore être utile pour une boucle d’agent ? La réponse est oui, mais pour des raisons différentes de celles de 2000.

L’anatomie de l’agent

L’implémentation complète (disponible sur The Beach) utilise SBCL (Steel Bank Common Lisp), deux bibliothèques (dexador pour HTTP, shasht pour JSON), et rien d’autre. La boucle récursive :

lisp (defun agent-loop (messages) (let* ((message (ref (call-model messages) choices 0 message)) (tool-calls (gethash tool_calls message))) (if (and tool-calls (plusp (length tool-calls))) (agent-loop (append messages (list message) (map list # execute tool-calls))) (append messages (list message)))))

Huit lignes. Si le modèle répond, il retourne l’historique. S’il demande des tools, les exécute, ajoute les résultats, et se rappelle lui-même. L’état n’est que la liste des messages qui traverse la récursion. Pas de state machine, pas de variables globales.

Le truc : eval comme unique tool

La plupart des agents ont un catalogue de tools (recherche web, lecture de fichiers, exec Python). Cet agent a un seul tool : eval. Le modèle écrit une forme Lisp sous forme de chaîne, l’agent la lit (read-from-string), l’exécute (eval), et retourne le résultat imprimé.

lisp (defun lisp-eval (form-string) (handler-case (format nil “~s” (eval (read-from-string form-string))) (error (e) (format nil “ERROR: ~a” e))))

C’est possible parce que Lisp est homoïconique : le code est écrit dans la même structure de données (listes) que le langage manipule. Un programme Lisp peut construire et modifier d’autre code Lisp aussi facilement qu’il construit une liste d’épicerie. Dans la transcription du post, l’agent a calculé Fibonacci(30) en deux étapes : d’abord il a défini la fonction dans le runtime, puis l’a appelée.

Limites déclarées

L’auteur le dit clairement : eval ouvert est un risque de sécurité. Le modèle exécute du code arbitraire sur la machine. C’est une expérience en sandbox, pas une recette pour la production. L’auteur lui-même l’a seulement exécuté dans un conteneur Docker local.

Mais l’idée tient comme outil didactique : elle montre ce qu’il y a sous un agent sans framework, sans abstractions, sans dépendances. C’est l’équivalent d’écrire un serveur HTTP en 50 lignes pour comprendre ce qu’Express ou Flask font en coulisse.

Pourquoi aujourd’hui

La promesse originale de Lisp était « des programmes qui manipulent des programmes ». En 2000, cela signifiait des règles symboliques écrites à la main. En 2026, cela signifie : le modèle écrit le code, Lisp fournit le substrat où ce code s’exécute, et la boucle récursive tient tout ensemble. Le travail symbolique a été externalisé au modèle, mais la propriété homoïconique de Lisp rend l’exécution immédiate.

Si tu construis des agents ou si tu suis le parcours builder du cours, ce post vaut la lecture : c’est une anatomie propre, sans fioritures, de comment fonctionne une boucle. Et si tu t’es jamais dit « j’aimerais vraiment comprendre ce qu’il y a dessous avant d’utiliser un framework », c’est ce type de code qui te le montre.