Apache Burr : créer des agents et applications IA fiables

• Apache Burr est un framework Python pour construire des applications d’IA décisionnelles, du simple chatbot aux systèmes multi-agents complexes
• Les applications sont définies comme un ensemble d’actions et de transitions, écrites avec des fonctions Python et des décorateurs, sans DSL ni YAML
• Burr UI fournit des fonctions de monitoring, débogage et traçabilité à chaque étape d’exécution, avec visualisation en temps réel des changements d’état
• L’état peut être sauvegardé sur disque, en base de données ou dans un backend personnalisé, puis repris à partir d’un point d’arrêt ; l’attente d’une intervention humaine et l’exécution parallèle sont aussi prises en charge
• Le framework s’intègre aux outils existants comme OpenAI, Anthropic, LangChain, FastAPI et PostgreSQL, sans effet de verrouillage ni wrappers

---

Créer des agents et applications IA fiables

• Apache Burr est un projet Apache Incubating qui facilite le développement d’applications capables de prendre des décisions
• Son périmètre va du simple chatbot aux systèmes multi-agents complexes
• L’implémentation repose sur du Python pur, avec une approche revendiquée comme « no magic »
• Les indicateurs publics affichés sont 1 641 étoiles sur GitHub, 379k+ téléchargements sur PyPI et 457+ membres sur Discord

Une API Python simple et puissante

• Burr propose une interface composable pour construire aussi bien des chatbots que des systèmes multi-agents
• Le code d’exemple utilise action, State et ApplicationBuilder de burr.core pour définir l’action chat
• @action(reads=["messages"], writes=["messages"]) indique les états lus et écrits
• ApplicationBuilder() configure les actions, les transitions, l’état initial et un tracker local avant de construire l’application
• L’exemple d’exécution passe un client LLM en entrée sous la forme app.run(halt_after=["chat"], inputs={"llm_client": client})

Les éléments nécessaires à la construction d’applications IA

• Simple Python API définit l’application comme un ensemble d’actions et de transitions, en utilisant uniquement des fonctions Python et des décorateurs, sans DSL ni YAML
• Built-in Observability permet de monitorer, déboguer et tracer en temps réel toutes les étapes de l’application via Burr UI
• Persistence & State Management enregistre automatiquement l’état sur disque, en base de données ou dans un backend personnalisé, et permet de reprendre à partir d’un point d’interruption
• Human-in-the-Loop permet d’arrêter l’exécution à n’importe quelle étape et d’attendre une intervention humaine, ce qui convient aux workflows d’approbation et aux agents interactifs
• Branching & Parallelism prend en charge l’exécution parallèle d’actions, le fan out / fan in, la construction de DAG complexes et la composition de sous-applications
• Testing & Replay renforce la confiance dans les systèmes IA grâce à la relecture d’exécutions passées, aux tests unitaires par action et à la vérification des transitions d’état

Intégration à la stack existante

• Burr s’intègre aux outils et frameworks déjà utilisés, sans exiger d’effet de verrouillage ni de wrappers
• Les intégrations LLM mentionnées sont OpenAI, Anthropic et Instructor
• Les intégrations frameworks mentionnées sont LangChain, Hamilton et Haystack
• Les intégrations UI et serving mentionnées sont Streamlit et FastAPI
• Les intégrations validation et stockage mentionnées sont Pydantic et PostgreSQL
• La liste complète des intégrations est disponible dans la documentation

Retour d’expérience des développeurs et des équipes

• D’après Peanut Robotics, après avoir évalué plusieurs frameworks LLM, la gestion d’état de Burr s’est révélée une réponse solide pour déployer des robots fondés sur la prise de décision par IA
• Watto.ai estime qu’il est facile de créer des applications IA modulaires avec Burr, et que son UI simplifie le débogage
• Paxton AI souligne que Burr n’adopte pas de concepts étranges ou inutilement obscurs sous prétexte qu’il s’agit d’IA
• Provectus juge la gestion d’état de Burr utile pour créer des snapshots d’état, déboguer, rejouer des exécutions et construire des cas d’évaluation
• CognitiveGraphs estime que, comparé à plusieurs plateformes LLM agentiques comme LangChain, CrewAi, AutoGen ou Agency Swarm, Burr fournit un framework plus robuste pour concevoir des comportements complexes
• TaskHuman explique avoir démarré en quelques heures après être passé de LangChain à Burr, puis avoir migré l’ensemble de sa base de code vers Burr

Communauté et état du projet

• La communauté est présentée comme un espace pour demander de l’aide, partager des projets et contribuer à l’avenir de Burr
• Les canaux de participation proposés sont Discord, GitHub et Twitter / X
• Les ressources du projet renvoient vers la documentation, des exemples, YouTube, la feuille de route et le journal des modifications
• Apache Burr est un projet en incubation au sein de l’Apache Software Foundation, parrainé par l’Apache Incubator
• Le statut d’incubation ne reflète pas nécessairement le niveau d’achèvement ou de stabilité du code, mais indique que le projet n’a pas encore reçu l’approbation complète de l’ASF

[GN⁺]

Avis sur Hacker News

• Je réserve encore mon jugement sur les frameworks d’agents, et leur utilité dépend du type d’agent. Par exemple, il y a une différence entre un cas où il faut renvoyer une réponse suffisamment bonne en moins de 3 secondes et un autre où il faut résoudre un problème pendant 3 heures.
  Au final, un agent se résume à la construction du contexte, aux appels au LLM, à l’exécution des appels d’outils demandés, au parsing de la sortie finale du modèle, puis au retour au frontend. Il existe des extensions comme la mémoire ou les appels d’outils asynchrones, mais du point de vue du génie logiciel traditionnel, ce n’est pas si complexe.
  Tout le monde veut créer son propre framework d’agents, mais si l’on doit construire un agent précis, du code sur mesure pour cet agent est bien plus simple et se maintient mieux. Les abstractions du framework masquent souvent la logique essentielle et deviennent gênantes, et au bout du compte il faut se plier aux abstractions choisies par le framework, même quand elles s’écartent de l’objectif réel.

  • Le cœur d’un système agentique n’est pas d’utiliser des agents, mais de ne les utiliser que quand c’est vraiment nécessaire. Un système qui fonctionne a besoin de pipelines/recettes pour exprimer des flux en plusieurs étapes, d’un système d’exploitation capable d’exécuter de façon fiable des étapes de modèle et d’intervention humaine dans plusieurs pools de workers agents, d’une gestion, d’un déploiement, d’une sécurité et de permissions pour des compétences épaisses qui traitent un maximum de choses en code, ainsi que d’une gestion du contexte qui injecte le bon contexte dans la bonne session.
    Il faut aussi de la gestion de projet pour les tickets, dépendances, progrès et redémarrage des tickets bloqués, le stockage de l’historique des conversations et des fonctions de mémoire, de rêverie et d’apprentissage cumulatif, de l’observabilité sur les coûts et l’usage, l’évaluation et l’ajustement automatique des prompts, la possibilité de changer de fournisseur de modèle et d’épingler une version de modèle, ainsi qu’un sandbox pour exécuter les vraies sessions.
    Il n’est pas nécessaire d’obtenir tout cela auprès d’un seul fournisseur, mais dans la plupart des cas il ne faut pas se retrouver enfermé chez un unique fournisseur de modèles, et il faut posséder en direct son propre contexte et son apprentissage cumulatif.
  • Le problème le plus grave dans la plupart des frameworks d’agents, c’est qu’ils masquent la logique centrale. Il faut voir clairement ce qui est réellement envoyé au modèle de langage et ce qui en revient.
    Tout, dans une application agentique, finit par se matérialiser sous forme de séquences de tokens ou d’appels au fournisseur, donc cela devrait être explicite dans presque toutes les couches de l’application.
  • J’avais une réflexion similaire sur les dizaines de frameworks frontend. Ils imposent d’énormes abstractions et de la complexité en échange d’une récompense censée arriver dans le futur, mais qui n’arrive jamais.
    Cela dit, les gens ont besoin de travail à faire ou de jouets amusants, et la « personne suivante » n’est généralement pas jugée très importante, donc beaucoup semblent estimer qu’il n’y a pas de mal à refiler le résultat de leur temps de jeu rémunéré.
  • Je suis assez d’accord avec l’idée de faire du code sur mesure pour un agent donné. Mais quand on crée une nouvelle technique ou une nouvelle approche dans un nouvel agent, la question de savoir comment mettre à jour les anciens agents — et si on veut vraiment le faire — reste un vrai sujet de maintenance.
    Par exemple, il semble qu’Apache Burr prenne en charge, ou prendra en charge, un système vectoriel RAG enfichable, mais ce dont j’ai besoin, c’est d’une méthode qui ajoute des documents au contexte, les conserve comme partie du system prompt mis à jour, et introduit dans ce processus des ajustements très spécifiques. C’est une utilisation personnalisée de la notion existante de RAG, donc cela s’adapte mal à un framework donné.
    Pour mon usage, une implémentation sur mesure est la bonne solution, mais les choix d’ingénierie pour faire évoluer les anciens agents restent entiers.
  • L’avantage d’un framework n’est pas vraiment de faciliter l’écriture de l’agent lui-même, mais de fournir des outils et de l’observabilité. LangChain a beau être critiqué à juste titre sur bien des points, il l’a montré très clairement dès le début.
    Construire un chatbot from scratch peut être facile, voire plus facile, mais dès qu’il faut ajouter de l’observabilité ou du tracing, la donne change. Si l’on peut ajouter une seule variable d’environnement et parcourir toutes les traces dans une UI avec presque aucun travail supplémentaire, une solution maison a du mal à rivaliser.

• Je me demande si cette page a été faite avec https://vorpus.github.io/performativeUI/.
  Elle coche autant que possible tous les clichés typiques des landing pages générées par IA. Ou alors c’est peut-être une satire volontaire.

• J’utilise volontiers ce framework dans mes projets personnels comme professionnels. J’ai apprécié d’y trouver des workflows stateful fiables pour les modèles d’IA, ainsi qu’une observabilité gratuite.
  J’ai assemblé un outil qui monte une machine à états Burr sur MCP, ce qui donne à l’agent des rails à suivre tout en limitant l’outil MCP à l’exploration de la machine à états, même si celle-ci devient très complexe : https://github.com/msradam/theodosia
  Je travaille maintenant à transformer des skills en machines à états. Beaucoup de skills populaires sont déjà écrits sous forme d’étapes à suivre par les modèles d’IA, donc j’ai l’impression qu’en exploitant les capacités explicites de Burr, on peut les rendre plus fiables.

• Je me demande comment cela se compare à https://strandsagents.com/. Je m’intéresse aux outils de cet espace et je ne suis pas encore lié à l’un d’eux, mais Bedrock + Serverless on Agent Core donne l’impression d’être une « voie guidée facile ». En revanche, la dépendance à la plateforme ne me plaît pas.

  • Je serais curieux d’avoir d’autres retours d’expérience. J’utilise cette stack et je me demande encore si Strands apporte une sauce secrète particulière avec Agent Core.
    Jusqu’ici, je n’en ai pas l’impression, et parfois on dirait même que les deux se gênent mutuellement.

• On voit ici le builder pattern et des décorateurs. Il y a aussi des décorateurs en Python, mais ils sont à mon avis surtout adaptés comme des « filtres » appliqués à une fonction ou une méthode. Du genre : mettre cette fonction en cache, toujours sérialiser la sortie de cette fonction, préparer cette fonction comme outil pour un moteur d’exécution orienté agent
  Je ne pense pas qu’ils servent à l’enregistrement ou au contrôle de flux. On peut ne pas être d’accord, mais il fallait bien que quelqu’un le dise. FastAPI a beaucoup trop tiré l’usage moderne des décorateurs dans une mauvaise direction
  Le builder pattern est plus une convention née du fait que Rust n’a pas d’arguments nommés au sens strict, alors qu’une fonction Python expose déjà un contrat nommé. Il y a rarement une bonne raison de passer des paramètres de configuration dans l’ordre via des appels de méthodes chaînés
  S’il faut ajouter un état qui n’existe pas encore dans le constructeur ou la factory, ce n’est pas un builder pattern mais de l’enregistrement. Le seul endroit où le builder pattern me paraît acceptable, c’est un query builder. On y empile de façon répétée des concepts, et les emplacements de métadonnées que sont les noms de méthodes et les arguments nommés y sont réellement utiles. Utiliser des méthodes qui prennent un paramètre unique à la place d’arguments nommés me paraît être une erreur

  • Ici, les décorateurs servent plus précisément à attacher des métadonnées aux fonctions pour en faire des composants réutilisables, et le builder sert à construire le workflow. Dans Hamilton, la composition est purement déclarative, donc tout passe par des décorateurs, mais la réutilisabilité est en réalité une question distincte
  • Le builder pattern ne s’utilise pas qu’en Rust, mais je suis d’accord pour dire qu’en Python c’est assez disgracieux

• Cela ressemble à une version assez naïve de ce qu’est un agent IA fiable
  La fiabilité signifie « peut-il terminer la tâche qu’on lui confie », pas quelque chose qui a vraiment à voir avec une machine à états

• Je découvre Burr, et je me demande pourquoi il a été incubé chez Apache

  • Il n’y a pas de raison que ce ne soit pas le cas. L’ASF a une longue histoire d’incubation de nouveaux projets libres open source
    Certains obtiennent leur diplôme et deviennent des noms connus de tous, d’autres échouent et finissent dans l’attic. L’ASF apporte un soutien organisationnel et aide en général à faire grandir de bonnes communautés
  • Parce que c’est moi qui l’ai soumis. Le processus a été lent, car j’apprenais les procédures Apache tout en menant d’autres activités, mais il y a maintenant une certaine dynamique, et nous commençons à publier plus régulièrement

• La page a l’air d’un déchet jetable fait avec Claude Code, et elle n’essaie même pas de fonctionner sans JavaScript. Au moins, il y a une cohérence de marque

• Je n’ai pas trouvé d’explication explicite du nom, mais pour les curieux voici un exemple Hamilton : https://github.com/apache/burr/tree/main/examples/multi-agen...

  • Burr tire son nom de Aaron Burr, père fondateur des États-Unis, 3e vice-président, meurtrier et rival juré d’Alexander Hamilton
    Le lien avec Hamilton vient du fait qu’il s’agit de la deuxième bibliothèque open source publiée par DAGWorks après la bibliothèque Hamilton. Le nom imagine ce qu’il se serait passé si Burr et Hamilton avaient coexisté en harmonie et bâti une meilleure fédération en dépassant leurs différences
    À l’origine, Burr a été créé comme mécanisme pour gérer l’état entre les exécutions de DAG Hamilton. Un DAG n’a pas de cycles. Ils se sont ensuite rendu compte que le champ d’application était plus large et l’ont publié plus largement
    https://pypi.org/project/burr/

• Je me demande s’il existe des outils ou plateformes d’orchestration d’agents de codage que vous recommanderiez. J’aimerais exécuter, gérer et superviser des agents codex ou claude sur plusieurs machines
  Si possible, j’aimerais quelque chose d’auto-hébergeable ou open source. Je sais que claude code a déjà beaucoup de ces fonctions en interne, mais c’est spécifique à Claude

  • D’après la documentation, Burr a un cookbook d’agents pour démarrer avec ça, et peut aussi gérer des workflows multi-machines. Je me demande si ce n’est pas justement ce que vous cherchez
    Je ne sais pas exactement comment cela s’intègre avec des compétences et autres, mais à première vue cela semble pouvoir fonctionner
    https://burr.apache.org/docs/examples/agents/