Flue 2 veut faire pour les agents ce que React a fait pour l’interface

Flue se présente aujourd’hui comme un framework TypeScript d’agent harness : autrement dit, une structure qui branche un grand modèle de langage sur des sessions (conversations persistantes), des tools (fonctions appelables), des skills (blocs d’expertise réutilisables), un sandbox (bac à sable isolé pour exécuter du code) et des connecteurs comme MCP (Model Context Protocol, protocole ouvert pour relier des outils et services à un agent). Le dépôt GitHub résume bien la promesse : « Not another SDK », avec une fonction TypeScript comme centre de l’agent, et des appels comme useModel, useSandbox, useSkill et useTool pour assembler son environnement. Flue documente aussi son approche comme “harness-first” : pour l’équipe, un agent est avant tout un modèle dans un harness, pas une simple suite d’appels API. (github.com)

Ce qui change concrètement

La clé de lecture de l’article source, confirmée par les éléments publics du projet, est là : Flue pousse l’idée que la vraie complexité d’un agent est dans son assemblage plutôt que dans le prompt seul. Dans l’exemple du README, l’agent est littéralement une fonction ; on y déclare le modèle, le sandbox local, deux skills et deux tools, puis on retourne l’instruction principale. Cela ressemble à React non pas côté interface, mais côté composition déclarative : on décrit ce dont l’agent a besoin, au lieu d’écrire un gros orchestrateur impératif rempli d’états cachés et de branchements ad hoc. Le dépôt mentionne en outre des briques utiles pour des agents de production : durabilité (reprise après panne ou redémarrage), subagents (agents spécialisés délégués), observabilité (traces et télémétrie via OpenTelemetry, Braintrust ou Sentry) et déploiement sur Node.js, Cloudflare Workers, GitHub Actions ou GitLab CI/CD. (github.com)

Pourquoi c’est intéressant pour une équipe dev

Pour une équipe qui utilise déjà des assistants de code, l’intérêt n’est pas d’avoir « encore un framework agent », mais d’obtenir une surface de code plus stable pour industrialiser des agents internes : triage de tickets, revue de code assistée, exécution de playbooks d’exploitation, support interne, ou agents branchés sur Slack et GitHub. Flue documente déjà des channels (canaux d’entrée) pour recevoir des événements vérifiés depuis Slack, Teams, Discord, GitHub et d’autres services, ainsi qu’un système de skills pour empaqueter des consignes expertes réutilisables. En clair : au lieu de recopier les mêmes prompts et garde-fous dans plusieurs scripts, on centralise ces capacités dans des modules versionnés. C’est particulièrement cohérent avec les pratiques d’équipe où l’on veut relier un agent à un dépôt, à un sandbox, à des outils de ticketing et à des règles de sécurité sans réécrire toute la plomberie à chaque fois. (github.com)

À quoi ça ressemble dans le code

Le cœur de l’idée Flue est déjà visible publiquement :

'use agent';
import { useModel, useSandbox, useSkill, useTool } from '@flue/runtime';
import { local } from '@flue/runtime/node';

export function Triage() {
  useModel('anthropic/claude-sonnet-4-6');
  useSandbox(local());
  useSkill(triage);
  useTool(openIssue);

  return `Triage a bug report end-to-end.`;
}

Ce style a deux effets utiles. D’abord, il rend la configuration lisible au premier coup d’œil : quel modèle, quels droits, quels outils, quelles règles. Ensuite, il ouvre la voie à des composants d’agent réutilisables, comme React l’a fait pour l’interface. Si Flue 2 généralise vraiment cette logique via une Agent Hooks API (API de hooks pour agents), l’impact concret pour les développeurs sera moins du côté du « raisonnement magique » que du côté de la maintenabilité : moins de glue code (code de raccord fragile), plus de conventions, et une meilleure séparation entre orchestration fiable et autonomie laissée au modèle. Cette orientation colle d’ailleurs à la doctrine officielle de Flue : quand une tâche est sensible ou demande de la fiabilité, il faut la sortir du libre arbitre du modèle et la mettre dans des Actions déterministes (étapes contrôlées par l’application). (github.com)

Ce qu’il faut retenir

Le point important n’est pas seulement « des hooks comme React ». Le vrai message de Flue est plus profond : les agents sont définis par leur harness — leur environnement, leurs permissions, leurs outils, leur mémoire et leurs mécanismes de reprise — bien plus que par un prompt brillant. Pour un développeur, c’est une bonne nouvelle : cela rapproche la construction d’agents d’un terrain familier, celui de l’architecture logicielle, des abstractions réutilisables et de l’outillage observable. En revanche, sur l’article source de Latent Space lui-même, je n’ai pas pu ouvrir directement la page fournie depuis l’outil web ; j’ai donc limité cet article aux faits vérifiables dans les sources publiques accessibles : dépôt GitHub de Flue, documentation officielle et billet Flue 1.0 Beta, plus l’aperçu indexé de Latent Space qui confirme l’angle « hooks » et « harnesses ». (github.com)