Notes de recherche

Interfaces d'agents en production

La surface de chat comme console d'opération — bases de connaissances branchées, outils connectés, agents sur un roster, avec visibilité en temps réel sur le budget contexte, la consommation de jetons, le choix du modèle et des opportunités d'économies concrètes. L'interface qui permet à une équipe d'exécuter vraiment un agent en production, pas seulement d'en faire la démo.

Principe opérationnel

Si vous ne voyez pas le coût, le contexte ou le choix du modèle à chaque tour, ce n'est pas vous qui exécutez l'agent — c'est l'agent qui vous exécute. Une interface de chat en production est d'abord une surface d'observabilité, et un chat ensuite.

Je veux pouvoir lancer des agents auxquels on connecte facilement des outils — avec une visibilité native sur le coût, le contexte et le bon modèle pour la bonne tâche.
— Alain Carpentier, Group e-media
Démo · l'artefact de référence de ce papier
Group e-media · Agent opérations
Outils MCP · graphe source · exécution tracée
Route l'intentionAppelle des outils gouvernésLit le graphe sourceJournalise les traces d'éval
Ce fil client ressemble à un risque d'attrition. Trouve les échecs liés et rédige le suivi opérationnel.
Routé via le graphe source. J'ai trouvé trois incidents liés, identifié le propriétaire, vérifié le guide et rédigé un suivi avec preuves, risques et critères d'acceptation.
outil : linear.createIssuesource : soutien + guidesconfiance : 0,94

40K/200K·Sonnet 4.6

Pourquoi ce papier existe

La plupart des produits de chat IA optimisent une seule chose : la qualité de la réponse. Le coût pour l'obtenir, le modèle qui l'a produite, le budget contexte consommé, les outils appelés, les sources de connaissances utilisées — tout cela reste caché derrière une surface conversationnelle lisse. Acceptable pour un jouet grand public. Pas acceptable pour une opération en production. Quand l'équipe qui exploite l'agent ne voit pas ce qu'il fait, elle ne peut ni lui faire confiance, ni l'optimiser, ni stopper un tour incontrôlé avant que la facture n'arrive. Ce papier décrit l'interface qui corrige cela : une console d'opération qui se présente comme un chat.

L'impératif de visibilité

Une interface d'agent en production expose cinq signaux en temps réel à chaque tour : quel modèle a traité la requête, combien de la fenêtre de contexte a été consommé, quels outils ont été appelés, quelles sources de connaissances ont été lues, et le coût en dollars d'entrée + sortie. Ces signaux ne sont pas enterrés dans des logs admin ou un tableau de bord d'arrière-plan — ils vivent à côté de la bulle de message, où l'équipe qui opère l'agent les lit d'un coup d'œil.

  • Budget contexte · % de la fenêtre utilisée + jetons (ex. 40K / 200K)
  • Coût · entrée + sortie, en dollars réels, par tour et cumulé pour la session
  • Modèle · lequel a tourné, pourquoi il a été choisi
  • Outils · quels outils MCP ont été appelés, avec arguments et résultats
  • Connaissance · quels corpus / documents ont été touchés, avec chips de citation

Bases de connaissances branchées

Chaque surface de chat a besoin d'une liaison à un corpus. L'interface expose les bases disponibles comme chips de première classe à côté du composer — sélectionnables par tour, avec leur fraîcheur et leur nombre de documents visibles. L'agent les utilise de manière transparente, les citations reviennent en ligne avec ancres vers les documents source.

Outils connectés

Une surface de chat de production est aussi une surface d'outils. Les serveurs MCP se branchent une fois et exposent leurs actions à l'agent — Linear, Notion, Stripe, Slack, une API interne, ce que l'équipe veut. L'interface rend chaque appel d'outil comme une carte inspectable : quel outil, quels arguments, quelle portée, ce qui est revenu. Un membre d'équipe en revue peut rejouer l'appel, contester le résultat ou révoquer la portée sans toucher au code d'infra.

Agents sur un roster

Changer d'agent dans la même conversation devrait ressembler à changer de canal. L'interface garde un roster d'agents disponibles — Concierge pour le client, Operations pour le triage d'incidents, Sales pour le brief pré-appel, un agent custom pour votre domaine — et laisse l'utilisateur choisir ou auto-route par intention. L'historique de conversation reste continu ; le cerveau qui répond change.

Vue d'ensemble du contexte

La fenêtre de contexte est un budget, et l'interface la traite comme tel. Un petit anneau près du composer montre le pourcentage utilisé ; un panneau dépliable décompose les jetons d'entrée, de sortie, l'historique conservé, la taille du prompt système et les fragments récupérés.

Vue d'ensemble du coût

Le coût se rend en monnaie, pas en jetons. Chaque tour affiche son coût entrée + sortie ; un total de session s'accumule dans l'en-tête. Les sessions multi-modèles décomposent le coût par modèle pour qu'on voie exactement ce que l'escalade vers Sonnet a ajouté à un triage commencé en Haiku.

Routage de modèle par tour

L'interface ne cache pas quel modèle a traité un tour — et plus important, ne cache pas quel modèle *aurait dû* le traiter. Un modèle moins cher qui aurait produit la même sortie se présente comme suggestion. Un modèle cher qui a traité une tâche triviale se voit signalé. La logique de routage est visible, auditable et ajustable.

Suggestions d'économies

La fonctionnalité la plus sous-estimée d'une interface de chat en production : le moment où elle vous dit que vous dépensez trop. Suggestions concrètes : « Cette classe d'intention est actuellement routée vers Sonnet à 0,18 $/tour ; Haiku gère 94 % du jeu d'éval à 0,012 $/tour — envisagez de re-router » ; « Le retrieval tire 32 fragments par tour mais le modèle n'en cite que 4 — envisagez de baisser le top-k ».

Exposition des traces

Chaque tour laisse une trace inspectable — les étapes traversées, les outils appelés, les fragments récupérés, la validation passée. La trace vit là où elle se produit (la surface de chat) plutôt que dans un outil d'observabilité séparé. Un clic sur la bulle bot révèle l'exécution étape par étape.

Ce que ce n'est pas

Pas un panneau debug greffé sur un chatbot — la visibilité est le produit, pas un add-on admin. Pas une UI d'opérateur séparée qui vit ailleurs — opérateur et utilisateur peuvent être la même personne, sur le même écran. Pas une enveloppe autour d'un seul fournisseur LLM — l'interface est un runtime multi-modèles, multi-outils, multi-agents.

Ce que nous construisons

Un composer compatible AI SDK Elements avec panneaux contexte et coût intégrés ; un sélecteur de roster lié au registre d'agents ; intégration d'outils MCP avec cartes de trace en ligne ; chips de bases de connaissances ; un routeur de modèle avec politique ajustable et popover d'explication ; un moteur de suggestions qui surveille la session pour des opportunités d'économies.

Possibilités futures

Apprentissage persistant des préférences de routage par session ; budgets d'équipe partagés avec alertes douces ; accès outil scopé par rôle directement dans le composer ; runbooks auto-générés à partir des sessions fréquemment tracées ; surfaces de collaboration multi-agents où deux agents alternent sur le même tour avec passages visibles.

Conclusion

L'interface de chat est la console de production de l'ère des agents. Une fois cela accepté, les contraintes de design s'inversent : ce qui ressemble à un produit de chat devient une surface système, et ce qui était caché devient la vraie valeur. Une équipe qui fait tourner un agent en production n'a pas besoin d'un plus joli chat. Elle a besoin de voir ce que l'agent coûte, ce que l'agent lit, quels outils il touche, et où elle laisse de l'argent sur la table.

Ressources connexes