AgentDock : un framework TypeScript pour doser la part de déterminisme dans un agent

Le problème visé : reprendre la main sur la part imprévisible d'un agent

Un agent LLM classique laisse le modèle décider de l'enchaînement des appels. Le README d'AgentDock part d'un constat inverse : les AgentNodes sont par nature non déterministes, puisque le modèle peut produire une réponse différente à chaque exécution. La réponse du projet consiste à déplacer le curseur. On garde l'inférence là où elle apporte quelque chose, on la retire là où elle n'apporte que du bruit, et les chemins d'exécution des outils deviennent fixes. Le public visé est précis : une équipe qui écrit du TypeScript côté serveur, qui veut déployer un agent sans dépendre d'un fournisseur de modèle unique, et qui accepte de décrire elle-même ses enchaînements plutôt que de les dessiner dans une interface. Le README parle d'un framework backend-first, framework-agnostic et provider-independent. C'est une promesse de contrôle, pas de simplicité d'accès.

Tout est nœud, et les outils sont des nœuds spécialisés

L'architecture repose sur une idée unique, répétée dans les principes de conception : toute capacité est un nœud. Les outils ne forment pas une catégorie séparée, ce sont des nœuds étendus. Un agent est donc un assemblage de nœuds, et le workflow est la façon dont ces nœuds s'enchaînent. Les exemples du dépôt montrent cette composition à l'œuvre. L'agent Dr. Gregory House orchestre search, deep_research et pubmed dans un workflow multi-étapes. Cognitive Reasoner combine sept outils nommés search, think, reflect, compare, critique, brainstorm et debate. History Mentor associe des connaissances historiques vectorisées, search et un rendu de diagrammes Mermaid. Calorie Vision combine vision par ordinateur et extraction structurée pour produire un décompte de macronutriments à partir d'une photo. Ces quatre agents vivent dans le même dépôt, sous agents/. Le README ne décrit pas le format de fichier qui les déclare, ni comment un nœud en appelle un autre. C'est la zone d'ombre principale du projet.

Deux briques, pas une : le cœur et le client Next.js

AgentDock se présente comme deux composants distincts. AgentDock Core est le framework backend, celui qu'on intègre dans sa propre application. Le second composant est un client Next.js complet, décrit comme une implémentation de référence et un consommateur du cœur. La vitrine hub.agentdock.ai tourne sur ce client. Cette séparation a une conséquence pratique : lire le code du client est probablement le moyen le plus rapide de comprendre comment le cœur s'utilise, puisque le README ne fournit pas de guide d'intégration. Elle a aussi une conséquence de périmètre. Si vous voulez seulement le moteur, vous devrez trier vous-même ce qui relève du framework et ce qui relève de l'application de démonstration, dans un dépôt dont la langue principale déclarée est MDX. Beaucoup de contenu, donc, et une part de code à isoler soi-même.

Le déterminisme configurable, concrètement

Le README décrit le mécanisme en plusieurs points. Les AgentNodes restent non déterministes. Les workflows, eux, peuvent être rendus plus déterministes par des chemins d'exécution d'outils définis. Le développeur contrôle le niveau de déterminisme en choisissant quelles parties du système passent par l'inférence. Le comportement global reste prévisible grâce à des interactions d'outils structurées. Le README affirme aussi que les workflows déterministes classiques, ceux des constructeurs visuels, sont pris en charge, avec ou sans inférence, et illustre cela par un schéma Mermaid minimal : Input vers Process, Process vers Database et vers Output. Ce schéma montre la forme générale, pas une syntaxe réelle. La question que tout lecteur se posera, à savoir comment on marque un nœud comme déterministe ou non, n'a pas de réponse dans le matériel fourni. Le concept est clair, la surface d'API ne l'est pas.

Mise en route : ce que le README donne, et ce qu'il ne donne pas

Il faut être direct : le README ne contient aucune commande d'installation. Pas de npm install, pas de pnpm, pas de git clone, pas de variable d'environnement, pas de clé de configuration. Les seuls chemins cités sont des liens vers les dossiers d'agents, par exemple agents/dr-house, agents/cognitive-reasoner, agents/history-mentor et agents/calorie-vision, ainsi que le dossier docs/i18n qui contient les traductions du README. La documentation renvoyée se trouve sur hub.agentdock.ai/docs. Le badge de statut indique Beta. Un lecteur qui veut évaluer le projet doit donc passer par le dépôt lui-même : ouvrir un dossier d'agent, lire le fichier qui le déclare, et remonter jusqu'au cœur. C'est un coût réel, et il faut le compter avant de s'engager. À l'inverse, la licence MIT est explicite, avec un fichier LICENSE à la racine. Elle autorise la réutilisation, la modification et la redistribution, y compris dans un produit propriétaire, à condition de conserver l'avis de licence. Ce n'est pas un avis juridique, seulement ce que le fichier de licence implique en pratique.

Là où AgentDock n'est pas le bon outil

Le projet est en beta, sans release publiée dans les informations disponibles. Le README consacre une part importante de sa surface à des annonces : AgentDock Pro présenté comme à venir, avec constructeur visuel de workflows, orchestration avancée et infrastructure cloud, plus une inscription pour un accès anticipé et des crédits de plateforme. Un livre sur les agents et une bibliothèque de prompts en construction sont également mentionnés. Rien de tout cela n'est dans le périmètre open source décrit ici. Si votre besoin est un enchaînement linéaire de deux appels de modèle avec un appel d'outil au milieu, AgentDock ajoute une couche de concepts (nœuds, outils comme nœuds, niveaux de déterminisme) pour un gain faible. Et si vous cherchez un produit fini avec interface graphique, la réponse du README est justement de renvoyer vers une offre cloud non disponible. Le framework open source s'adresse à ceux qui veulent écrire l'orchestration, pas à ceux qui veulent la cliquer.

Face à LangChain : décrire l'enchaînement plutôt que le laisser émerger

La comparaison la plus utile est LangChain, autre framework d'agents en TypeScript et en Python. La différence porte sur le point de départ. LangChain fournit un large catalogue d'abstractions et d'intégrations, et l'orchestration émerge souvent de la composition de ces briques. AgentDock part d'un seul type de brique, le nœud, et place la question du déterminisme au centre : quelles étapes passent par le LLM, lesquelles suivent un chemin fixe. Le README revendique explicitement l'indépendance vis-à-vis du fournisseur de modèle et du framework. En contrepartie, LangChain dispose d'un écosystème d'intégrations bien plus large, là où AgentDock documente quatre agents d'exemple et un client Next.js. Le choix se joue donc entre un catalogue étendu et un modèle d'exécution resserré. Aucun des deux n'est meilleur dans l'absolu, mais si votre contrainte principale est de savoir exactement ce qui s'exécute à chaque étape, la proposition d'AgentDock est plus lisible.

Ce qu'il faut vérifier avant de s'engager

Le coût de maintenance d'AgentDock dépend d'un point que le README ne tranche pas : la stabilité de l'API du cœur. Un projet en beta, sans release publiée, peut modifier ses conventions de nœuds entre deux commits, et chaque changement se répercute sur tous les agents que vous avez écrits. La bonne première étape est donc de lire un agent existant du dépôt, par exemple sous agents/cognitive-reasoner, pour voir combien de code vous devrez réécrire en cas de changement. Vérifiez aussi ce que le client Next.js importe réellement du cœur : c'est la frontière entre le framework et l'application de démonstration, et c'est elle qui déterminera ce que vous pouvez réutiliser. Enfin, gardez à l'esprit que le README est la principale source disponible ici. La documentation hébergée sur hub.agentdock.ai/docs n'a pas été consultée, et c'est probablement là que se trouvent les clés de configuration absentes du dépôt.

Conclusion éditoriale

AgentDock convient aux équipes TypeScript qui veulent un cœur d'agent backend autonome et écrivent déjà du code applicatif, pas à celles qui cherchent un constructeur visuel prêt à l'emploi. Avant d'adopter, vérifiez dans le dépôt le fichier de configuration d'un agent existant, par exemple sous agents/dr-house, et les clés réellement lues au démarrage, car le README ne les détaille pas.

Sources officielles

1. AgentDock/AgentDock on GitHub
2. Issues
3. License: MIT
4. Project website
5. README