AG-UI: l'agent qui diffuse une interface, pas une transcription

Agents qui s’arrêtent à la boîte de chat

La plupart des “agents IA” en production aujourd’hui sont des interfaces de chat avec un prompt système. L’interface est un flux de texte. L’utilisateur voit des tokens. L’agent voit des tokens en retour. Rien d’autre n’existe dans ce monde : pas d’état, pas de structure, pas de notion de l’endroit où vous vous trouvez dans un processus.

Mais le vrai travail n’est pas une conversation. C’est un processus avec une interface utilisateur, des approbations et des outils. Un parcours d’intégration de patrimoine n’est pas “parlez-moi de vous”. C’est une vérification d’identité, puis une évaluation des risques, puis un routage DMN, puis une révision par un conseiller, puis l’ouverture d’un compte. Chaque étape a un état, produit un résultat et se termine par une décision. Aplatir cela en une transcription de chat supprime précisément la structure qui rend le travail auditable.

AG-UI est un protocole conçu pour combler cette lacune. Au lieu de diffuser du texte, le backend diffuse des événements d’interface utilisateur typés vers le frontend : cartes génératives, états d’appel d’outil, tâches d’humain dans la boucle. L’agent affiche une interface vivante, pas une transcription. L’épisode 2 de Agents, Orchestrated montre ce qui se passe lorsque vous dirigez ce protocole vers un moteur de processus au lieu d’un framework de chat.

Ce que j’ai construit : AURUM Private Bank

La démo est un concierge d’intégration pour une banque privée fictive, AURUM Private Bank. Un client postule. L’agent orchestre l’ensemble du flux, de la vérification d’identité à l’ouverture du compte, tandis que l’opérateur observe la même exécution comme une instance de processus en direct dans Camunda Operate.

Trois couches, et chacune a sa raison d’être.

L’expérience. Le client ne regarde pas un chatbot taper. Des cartes sont diffusées dans l’interface une par une à mesure que le processus avance : identité vérifiée, risque évalué, portefeuille recommandé, révision par le conseiller signalée. Chaque carte est un événement AG-UI typé rendu par le frontend React. Cela se lit comme une interface utilisateur vivante, pas une transcription, parce que c’en est une. Le frontend n’a pas de logique métier, il rend ce que le backend émet.

Le backend. Le flux est un processus BPMN exécuté sur Camunda 8.9, et vous pouvez voir le token se déplacer : Intake, puis Identity, puis Risk, puis routage DMN, puis Advisor Review, puis l’agent IA, puis compte ouvert. L’étape Advisor Review est une USER_TASK, et c’est le détail qui m’importe le plus. Lorsque le token l’atteint, le processus se met en pause et attend un humain. Pas un hack de polling, pas un trampoline de webhook. L’état d’attente natif du moteur. Chaque étape de l’exécution est visible dans Camunda Operate au fur et à mesure qu’elle se produit.

L’agent. La couche de raisonnement est multi-modèle. Les modèles Claude sur Amazon Bedrock et Gemini raisonnent sur les données du client, déclenchent l’un des 13 outils et émettent des événements AG-UI nativement pendant leur travail. Différents modèles se trouvent derrière différentes parties du même processus, et le moteur de processus les maintient honnêtes : un modèle peut proposer, mais le token n’avance que lorsque l’étape est terminée.

Une note d’implémentation importante : il n’y a pas de CopilotKit ni de ChatKit dans cette version. AG-UI est implémenté directement contre le backend Camunda 8 en utilisant le protocole AG-UI EventSource, du SSE simple d’un backend-for-frontend Node.js vers l’application React. Le protocole est suffisamment simple pour que l’implémentation directe ait nécessité moins de code que l’adoption d’un framework, et cela prouve que le pattern n’est pas couplé à un kit frontend particulier.

Pourquoi le moteur de processus est essentiel

L’idée clé, et la raison d’être de cet épisode : lorsqu’un moteur de processus est l’orchestrateur, l’expérience utilisateur agentique acquiert des propriétés que les architectures natives de chat ne peuvent pas avoir. Pas “n’ont pas encore”. Ne peuvent pas avoir, structurellement, parce que les architectures de chat conservent l’état dans la fenêtre de contexte du modèle.

Fiable. Si l’agent plante en plein milieu du flux, le processus BPMN reprend là où le token s’est arrêté. L’état réside dans Camunda, pas dans la fenêtre de contexte du LLM. Une connexion interrompue ou un appel de modèle échoué est une nouvelle tentative, pas une intégration perdue.

Mettable en pause. Une User Task peut mettre le flux en pause et attendre une décision humaine, pendant une minute ou une semaine. L’agent ne tourne pas en boucle, ne fait pas de polling, ne maintient pas une fenêtre de contexte ouverte. Le processus attend, à coût zéro, et reprend lorsque le conseiller agit.

Auditable. Chaque transition d’état, chaque appel d’outil, chaque décision est enregistrée dans Camunda Operate. La piste d’audit existe sans une seule ligne de code de journalisation personnalisé. Lorsque quelqu’un demande “pourquoi ce client a-t-il été acheminé vers la révision par un conseiller”, la réponse est une instance de processus que vous pouvez ouvrir, pas une requête de journal que vous espérez avoir été instrumentée.

Le pattern ici est l’orchestration d’abord, et il est agnostique au moteur. Camunda est ce avec quoi je livre, mais l’argument vaut pour Temporal ou tout moteur avec un état durable et des états d’attente natifs. Ce que vous ne pouvez pas faire, c’est faire du LLM l’orchestrateur.

C’est à cela que se résume la thèse : un processus, trois modèles, zéro code de “glue”. Le processus BPMN est la seule couche de coordination. Les modèles s’y branchent. Rien de sur mesure ne les maintient ensemble.

Ce qui n’a pas été publié sur LinkedIn

Les notes honnêtes, car la vidéo de démonstration polie cache de vraies décisions.

La banque est fictive et les données client sont synthétiques. Les étapes d’identité et de risque appellent des outils qui renvoient des résultats plausibles, pas de vrais fournisseurs KYC. Ce qui est réel, c’est l’architecture : un cluster Camunda 8.9 en direct, l’AI Agent Connector v6, de vrais appels de modèles à Bedrock et Gemini, et une vraie USER_TASK qui bloque réellement le processus jusqu’à ce qu’un humain la complète dans le bureau d’approbation de la démo.

Aller directement sur AG-UI au lieu d’utiliser CopilotKit m’a coûté une journée à lire le protocole d’événement et à construire le pont SSE dans le BFF. Cela en valait la peine, mais je ne le recommanderais que si vous voulez comprendre le protocole, si vous voulez juste l’interface utilisateur, les frameworks sont bien.

Les 13 outils sont le nombre nécessaire pour la démo, pas un benchmark. Le routage multi-modèle a fonctionné, mais j’ai choisi le modèle par étape au moment de la conception. Rien dans cette version ne sélectionne les modèles dynamiquement à l’exécution, et je voudrais un harnais d’évaluation en place avant de laisser quoi que ce soit faire cela devant un client.

Et l’affirmation “zéro code de glue” mérite d’être précisée : zéro glue d’orchestration. Il y a toujours un BFF qui traduit les événements du moteur en événements AG-UI. Ce qui est absent, c’est tout code personnalisé décidant de la suite des événements. Cette décision réside dans le BPMN, où un auditeur peut la lire.

Journal de bord

• Moteur : Camunda 8.9 (cluster SaaS), AI Agent Connector v6
• Modèles : Claude sur Amazon Bedrock, Gemini
• Outils : 13, déclenchés par la couche agent
• Protocole : AG-UI sur SSE (EventSource), implémenté directement, sans CopilotKit ni ChatKit
• Frontend : React, rendant les événements AG-UI typés sous forme de cartes génératives
• Backend : BFF Node.js reliant Camunda à AG-UI
• Porte humaine : BPMN USER_TASK (Advisor Review), visible en direct dans Camunda Operate
• Dépôt : letmereviewyourcode/camunda-agui-wealth-demo