Analyse d’une équipe commerciale basée sur l’IA : orchestration des agents avec LangGraph et FastAPI
Une présentation détaillée d’une plateforme multi-agents open source : comment les agents cofondateur, gestionnaire et spécialiste sont coordonnés, partagent des informations, s’arrêtent pour obtenir une validation et font des rapports.
La plupart des systèmes d’automatisation par IA suivent encore un modèle à un seul agent : un modèle reçoit une demande et renvoie une réponse. Cela convient bien pour répondre aux questions, mais le travail professionnel réel est distribué entre différentes fonctions, certaines étapes s’exécutent en parallèle et d’autres nécessitent l’approbation d’une personne. Cette présentation analyse une plateforme open source, Multi Agent for Business Automation, qui modélise une petite équipe de startup en tant qu’agents coordonnés. À la fin, vous devriez comprendre comment son orchestration, sa mémoire, ses mécanismes d’approbation et son interface API s’intègrent, ainsi quels choix de conception vous pouvez réutiliser dans vos propres systèmes d’agents.
D’un chatbot à un bureau virtuel
Examinez comment une nouvelle entreprise est réellement planifiée. Un fondateur formule la vision. Un manager la transforme en tâches concrètes. Le service financier vérifie les hypothèses de revenus et de coûts, le marketing définit la stratégie de positionnement, le service juridique identifie les risques, et le service des ventes prépare les actions de prospection. Certaines de ces étapes s’enchaînent, d’autres se déroulent en même temps, et certaines sont bloquées jusqu’à ce qu’un humain approuve la prochaine action.
D’après son README, le projet est une plateforme visant à automatiser les tâches professionnelles et à soutenir la prise de décisions, dans laquelle des agents ayant des rôles, des personnalités et des outils distincts sont coordonnés grâce à des workflows LangGraph, une mémoire partagée et des systèmes d’approbation avec intervention humaine (HITL), complétés par la génération de rapports et des intégrations externes. L’ambition n’est clairement pas de créer un autre chatbot, mais plutôt un bureau virtuel où les agents collaborent comme le ferait une équipe de startup.
Les cinq couches architecturales
Le système se divise clairement en cinq couches :
- Frontend : un tableau de bord React pour l’onboarding par chat, la visualisation des workflows, les approbations et les analyses.
- Backend API : des points de terminaison REST FastAPI, des flux WebSocket, des mécanismes d’authentification, des rapports et des API de mémoire.
- Couche des agents : les agents Fondateur, Gestionnaire, Finances, Marketing, Juridique, Argent et Ventes.
- Couche d’orchestration : des workflows LangGraph accompagnés d’un orchestrateur personnalisé, de la délégation des tâches et du suivi des points d’étape.
- Mémoire et infrastructure : Neo4j, Qdrant, Redis ou Upstash, Supabase, ainsi que le stockage des rapports.
D’après le README, l’ensemble des technologies utilisées est React 18 avec Vite, FastAPI, LangGraph ainsi que LangChain et CrewAI pour les workflows d’agents, Neo4j, Qdrant et Redis pour la mémoire et les files d’attente, et Supabase en tant que couche optionnelle pour l’authentification et la persistance.
Le cycle de vie global s’effectue du haut vers le bas, depuis la vision de l’utilisateur en passant par les agents dirigeants puis les spécialistes, pour aboutir à la mémoire partagée, aux validations et aux résultats :
User Vision
↓
Cofounder Agent
↓
Manager Agent
↓
Specialist Agents
├── Finance
├── Marketing
├── Legal
├── Money
└── Sales
↓
Shared Memory + Approval Gates
↓
Reports + Dashboard + Integrations
Ce que l’on retient de ce diagramme, c’est que la conception repose sur un système de workflow et non sur une chaîne de prompts. L’état, la mémoire, les validations, les tentatives de réessai, l’observabilité et les résultats persistants sont tous des éléments essentiels.
Le workflow en cinq étapes
Étape 1 : transformer une idée vague en contexte structuré
Tout commence lorsque l’utilisateur explique ce qu’il souhaite : un concept de produit, une idée d’entreprise ou un objectif opérationnel. L’agent co-fondateur reçoit cette information, qui peut être aussi simple qu’une seule phrase :
Input:
"I want to build an AI tool for small businesses."
Son rôle est de la transformer en un contexte structuré sur lequel le reste de l’équipe peut travailler :
Cofounder Output:
- Vision statement
- Target users
- Problem definition
- Market opportunity
- Strategic assumptions
- Initial business direction
Le README qualifie cette étape de « Vision intake ». En arrière-plan, elle peut être déclenchée via plusieurs points d’entrée, en fonction du fait que le client souhaite un projet ponctuel, une conversation ou une session approfondie :
POST /api/start-project
POST /api/conversation/start
POST /api/enhanced/start-session
Quelle que soit la voie choisie, l’arrière-plan crée un projet ou une session, enregistre l’état initial et envoie le message à l’agent approprié.
Étape 2 : planification et délégation par le manager
Lorsque la vision est structurée, l’Agent Gestionnaire prend le relais et décompose la stratégie en tâches pouvant réellement être exécutées :
Manager Responsibilities:
- Convert vision into roadmap
- Break work into functional domains
- Create agent assignments
- Define task dependencies
- Decide which agents should execute in parallel
Dans l’orchestrateur personnalisé, cela est mis en œuvre dans AgentOrchestrator.start_project(), situé dans backend/flows/orchestrator.py. Ce dernier génère un ID de projet, exécute d’abord le Cofondateur, transmet son résultat au Gestionnaire, puis lance les spécialistes selon les tâches attribuées par ce dernier. En pseudocode :
cofounder_result = await Cofounder.execute(vision_task)
manager_result = await Manager.execute(manager_task)
specialist_results = await execute_specialists(manager_result)
generate_outputs(all_results)
Le Gestionnaire constitue la couche de contrôle. Sans lui, chaque spécialiste travaillerait isolément à partir de l’idée brute et produirait des résultats qui ne se relient pas entre eux. C’est en centralisant la décomposition au sein d’un seul agent que les résultats des spécialistes forment un plan cohérent.
Étape 3 : exécution parallèle des spécialistes
Lorsque les tâches sont définies, les agents du domaine prennent le relais. La liste par défaut et leurs responsabilités sont les suivantes :
- Cofondateur : vision, stratégie et opportunités commerciales.
- Gestionnaire : feuille de route, décomposition des tâches et délégation.
- Finance : modèle de revenus, modèle de coûts, ROI et projections.
- Marketing : positionnement, campagnes et stratégie de contenu.
- Juridique : conformité, risques, contrats et vérifications de politiques.
- Finance : tarification, monétisation et opérations de revenus.
- Ventes : pipeline, prospection et stratégie de vente.
Chaque agent est défini dans backend/agents/personalities.py, et chaque définition comprend des traits, un style de communication, des domaines d’expertise ainsi que des outils spécifiques à son rôle. Cela est important : les agents sont modélisés comme des exécutants spécialisés dotés de leur propre comportement, de seuils de confiance et de contexte de tâche, et non simplement comme des prompts système différents.
L’exécution est gérée par la fonction _execute_specialists(), qui prépare une tâche pour chaque spécialiste (Finance, Marketing, Juridique et Finances, ainsi que Ventes lorsque cette fonctionnalité est activée). Chaque appel à un agent est encadré par une limite de temps de 60 secondes :
parallel_executions = [
asyncio.wait_for(agent.execute(task), timeout=60.0)
for agent_name, task in specialist_tasks
]
Tous ces appels encadrés sont ensuite attendus en même temps :
specialist_results = await asyncio.gather(
*parallel_executions,
return_exceptions=True
)
Comme asyncio.gather() prend en paramètre return_exceptions=True, un temps d’attente ou une panne survenant chez l’un des agents est retourné sous forme d’objet d’exception dans la liste des résultats, au lieu de faire annuler toute la série d’opérations. L’inconvénient est que le code appelant doit examiner chaque résultat pour déterminer s’il convient de réessayer, d’ignorer ou de transmettre à un niveau supérieur l’agent qui a échoué. La décision de conception globale est judicieuse : lorsque l’analyse financière n’a jamais besoin des résultats du marketing, ou inversement, il n’y a aucune raison de les exécuter l’un après l’autre.
Étape 4 : mémoire partagée et propagation du contexte
Un système multi-agents se dégrade rapidement lorsque chaque agent ne voit que son propre contexte. La plateforme remédie à cela en utilisant une couche de mémoire unifiée dans laquelle chaque stockage a une fonction distincte :
Neo4j → graph memory and relationships
Qdrant → vector memory and semantic retrieval
Redis → task queue, cache, runtime coordination
Local data → fallback storage and exported outputs
Le README résume cela comme étant la mémoire graphique Neo4j, la recherche vectorielle Qdrant, les files d’attente Redis ou Upstash, ainsi que le cache local avec un mécanisme de fallback adapté. Chaque solution répond à des besoins différents.
Mémoire graphique : elle enregistre les relations entre agents, tâches, projets et résultats :
Agent → executed → Task
Task → belongs_to → Project
Agent → produced → Output
Output → depends_on → PriorContext
Cette structure permet de visualiser la collaboration et de déterminer précisément quel agent a produit quel résultat, ainsi que sur quel contexte antérieur.
Mémoire vectorielle dans Qdrant : elle permet un rappel sémantique, ce qui permet à un agent de demander des travaux antérieurs en se basant sur leur signification plutôt que sur leur identifiant :
"Find previous market assumptions."
"Retrieve prior financial analysis."
"Use the earlier legal risk summary."
Mémoire de files d’attente basée sur Redis : elle assure la coordination en temps de exécution :
- Event streaming
- Task queues
- Cache
- Agent activity updates
- WebSocket event propagation
Le projet fonctionne également de manière fiable en l’absence de certains services. Pendant le développement local, Redis peut être remplacé par un adaptateur en mémoire, et les appels aux modèles de langage large peuvent être redirigés vers un fournisseur simulé. Cela réduit les obstacles à l’exécution de tout le système sur un ordinateur portable, sans avoir à prévoir toutes les dépendances nécessaires en environnement de production, bien que cela signifie également que les tests locaux ne mettront pas en évidence les problèmes qui n’apparaissent qu’avec des services réels.
Étape 5 : approbation par un humain
Les actions à fort impact ne doivent pas être exécutées de manière automatique aveugle ; ici, l’approbation humaine fait partie intégrante du flux de travail principal et non d’une solution ajoutée ultérieurement. Des contrôles s’appliquent aux décisions susceptibles d’affecter :
- Customer-facing campaigns
- Pricing recommendations
- Legal-sensitive outputs
- CRM updates
- Social media publishing
- Financial projections
- Business-critical recommendations
Le README met en évidence les points de connexion pour les notifications Slack ainsi que des délais d’attente configurables pour ces flux d’approbation. Du côté de l’API, les approbations sont accessibles via des endpoints tels que :
GET /api/approvals/pending
POST /api/approvals/{approval_id}/respond
GET /api/approvals/advanced/pending
GET /api/approvals/stats
Le cycle de vie basique d’une approbation se déroule comme suit :
Agent generates action
↓
System evaluates confidence/risk
↓
Approval request is created
↓
Frontend or Slack notifies human
↓
Human approves/rejects/provides feedback
↓
Workflow continues or stops
Le résultat est un modèle d’autonomie en niveaux : les tâches à faible risque s’exécutent automatiquement, tandis que tout ce qui concerne les clients, les aspects financiers ou les questions juridiquement sensibles attend une décision humaine. Si vous concevez des mécanismes similaires, un guide associé intitulé les modèles de routage, de diffusion et d’approbation dans LangGraph aborde plus en détail les mécanismes au niveau du graphe.
Dans le backend FastAPI
Le point d’entrée principal du backend, backend/main.py, instancie un ensemble de services globaux lorsque l’application démarre :
AgentOrchestrator
Enhanced Orchestrator
ReportGenerator
SimplePredictor
AgentCollaborator
AdvancedApprovalManager
AgentService
ReportService
LangGraphOrchestrator
Queue Manager
Selon le README, chaque route est montée par backend/main.py ; backend/api/main.py est un point d’entrée plus léger qui ne monte qu’un sous-ensemble de routes. Le code est organisé par responsabilités :
backend/
├── main.py # Primary FastAPI app
├── api/ # Route controllers
├── agents/ # Agent implementations and personalities
├── workflows/ # LangGraph and HITL orchestrators
├── flows/ # PRD DAG orchestrator
├── memory/ # Graph, vector, cache managers
├── task_queue/ # Redis/Upstash queue with fallback
├── integrations/ # HubSpot, Slack, Instagram clients
├── approvals/ # Approval managers
├── collaboration/ # Cross-agent communication
├── outputs/ # Report generation
├── analytics/ # Predictions and metrics
├── auth/ # Supabase auth
├── services/ # LLM, agent, report services
└── tools/ # Search and tool registry
La séparation entre workflows/ (les orchestrateurs LangGraph et HITL) et flows/ (l’orchestrateur DAG basé sur les PRD) mérite d’être soulignée : le projet utilise deux approches d’orchestration en parallèle, ce qui est flexible mais exige de vérifier quel chemin emprunte chaque point d’entrée.
La surface API, par groupe
Authentification
POST /api/auth/signup
POST /api/auth/signin
GET /api/auth/user
Dans le mode de type production, ces points d’entrée reposent sur l’authentification Supabase. En mode local ou de démonstration, l’application peut ignorer complètement Supabase et recourir à une logique de développement plus légère. Les options de configuration mentionnées dans le README incluent DEMO_MODE, les variables Supabase ainsi que les variables du fournisseur LLM. Les gestionnaires correspondants sont :
signup() → creates user account
signin() → authenticates user
get_current_user()→ verifies token and returns user profile
Cycle de vie du projet
GET /api/projects
POST /api/projects
POST /api/start-project
POST /api/auto-execute
GET /api/auto-execute/status
Ces éléments correspondent aux fonctions suivantes :
get_user_projects() → fetch projects for authenticated user
create_project() → create new project record
start_project() → execute Cofounder → Manager → Specialists workflow
auto_execute_project() → start automated coordination from raw vision
get_auto_execution_status() → return execution progress and logs
start_project() est le cœur de ce groupe. Sa séquence interne est :
1. Generate project_id
2. Execute Cofounder Agent
3. Log Cofounder result
4. Execute Manager Agent with Cofounder context
5. Log Manager result
6. Execute specialist agents in parallel
7. Export and persist final outputs
8. Return project status and timeline
Cette séquence correspond directement à AgentOrchestrator.start_project() et _execute_specialists() dans le module d’orchestration.
Sessions améliorées
POST /api/enhanced/start-session
POST /api/enhanced/continue-session
POST /api/enhanced/approve-and-execute
GET /api/enhanced/session-status
GET /api/enhanced/live-logs
GET /api/enhanced/session-results
GET /api/enhanced/system-metrics
POST /api/enhanced/cancel-session
POST /api/enhanced/cleanup-sessions
Chaque point d’entrée a un but précis :
start-session → create enhanced automation session
continue-session → continue existing multi-turn planning session
approve-and-execute → approve captured vision and run workflow
session-status → inspect session state
live-logs → stream logs for UI monitoring
session-results → return final session output
system-metrics → expose high-level runtime metrics
cancel-session → stop active session
cleanup-sessions → remove old sessions
C’est la méthode plus orientée vers la production, car elle sépare la conversation, l’approbation, l’exécution, le suivi et la récupération des résultats en appels distincts. Un client peut vérifier l’état ou recevoir les journaux en continu sans maintenir une requête ouverte pendant longtemps, et une session peut être annulée ou nettoyée explicitement.
Gestion des agents
GET /api/agents/status
GET /api/agents/list
GET /api/agents/personalities
GET /api/agents/configs
POST /api/agents/configs
POST /api/agents/execute
GET /api/agents/logs/live
Fonction de chaque route :
agents/status → current status of all agents
agents/list → available agent inventory
agents/personalities→ UI-visible personality metadata
agents/configs → current agent runtime settings
update configs → update temperature, approval mode, priority, enabled flag
agents/execute → execute a single agent manually
logs/live → recent agent execution logs
Lorsque vous appelez /api/agents/list, la liste des agents est renvoyée triée en quatre catégories (stratégique, commerciale, opérationnelle, spécialisée), et les points d’entrée de configuration en temps de exécution permettent à un opérateur de modifier la température, le mode d’approbation, la priorité ainsi que l’état d’activation d’un agent.
Conversations
POST /api/conversation/start
POST /api/conversation/{conversation_id}/message
POST /api/conversation/{conversation_id}/approve
Les gestionnaires associés à celles-ci :
start_conversation() → starts a Cofounder-led discovery conversation
continue_conversation() → continues the existing conversation with stored context
approve_conversation() → approves the captured vision and starts task distribution
Cet état des choses existe afin que le système puisse recueillir suffisamment d’informations avant de consacrer des ressources à des agents spécialisés. En interne, le processus se déroule comme suit :
1. User sends initial idea
2. Cofounder Agent asks clarifying questions or structures the vision
3. Conversation state is persisted
4. System detects whether vision is ready for approval
5. User approves
6. System starts agent coordination
Dans l’orchestrateur, start_conversation() attribue un nouveau ID de conversation, enregistre ce que l’utilisateur a écrit, appelle l’agent Cofounder, persiste la réponse et renvoie un drapeau ready_for_approval indiquant au client si la vision est suffisamment complète pour être approuvée.
Flux de travail LangGraph
POST /api/workflow/execute
POST /api/workflow/resume/{thread_id}
Les fonctions correspondantes :
execute_langgraph_workflow() → runs a LangGraph-based workflow
resume_workflow() → resumes workflow from checkpoint
Ces points d’entrée exposent directement la couche LangGraph. Le README le décrit comme des machines à états LangGraph qui enregistrent leurs progrès sous forme de points de contrôle, peuvent se corriger elles-mêmes et comprennent des nœuds d’interruption permettant une intervention humaine. La capacité de reprise est la propriété clé : lorsqu’un flux de travail longue durée est suspendu en attente d’approbation ou échoue en cours de route, il doit pouvoir reprendre à partir de son dernier point de contrôle plutôt que de devoir tout recommencer et payer à nouveau pour chaque appel à un LLM. Notre article décrit comment InMemorySaver de LangGraph stocke les points de contrôle et explique ce qui est réellement persisté à chaque étape.
Rapports
GET /api/reports/comprehensive
GET /api/reports/{report_type}
POST /api/reports/generate-pdf
GET /api/reports/download/{filename}
GET /api/reports/domains
GET /api/reports/domains/{domain}
Ce que produit chaque route de rapport :
comprehensive report → generate full business report
specific report → generate executive, marketing, financial, etc.
generate PDF → convert report data into downloadable PDF
download report → serve generated PDF/HTML
domain reports → return modular reports by business domain
La génération de rapports est une fonctionnalité majeure : des rapports exécutifs, marketing, financiers et complets au format JSON, avec une sortie PDF générée via WeasyPrint. C’est ce qui distingue le système d’un chatbot, car le résultat final est un artefact commercial et non un message de chat.
Mémoire
GET /api/memory/graph
GET /api/memory/stats
POST /api/memory/export
DELETE /api/memory/clear
Et ce qu’ils retournent :
memory/graph → return graph nodes and edges for visualization
memory/stats → return vector/graph memory statistics
memory/export → export stored memory and outputs
memory/clear → clear memory stores
Le README regroupe ces éléments sous /api/memory/* pour l’export en graphique et les statistiques. Avec eux, vous pouvez auditer les connaissances accumulées par les agents, suivre leurs sorties et observer la quantité de stockage utilisée par chaque backend de mémoire. Notez que l’endpoint de suppression est destructif et mérite les mêmes contrôles d’accès que toute autre action administrative.
Analyses
GET /api/analytics/predictions
GET /api/enhanced/system-metrics
GET /api/communication/stats
Leur objectif :
predictions → analyze generated outputs and estimate success/revenue/market timing
system metrics → return enhanced orchestrator metrics
communication stats → return inter-agent communication analytics
Derrière eux se trouvent de simples fonctions d’aide :
_analyze_project_success()
_analyze_revenue_trend()
_analyze_market_timing()
Ces outils analysent les résultats générés par les agents et en déduisent des indicateurs utiles pour l’entreprise, tels que la probabilité de succès, la direction de la croissance des revenus et les moments recommandés. Il s’agit d’heuristiques basées sur du texte généré, il convient donc de considérer leurs résultats comme indicatifs et non comme des prévisions.
Intégrations
/api/integrations/*
Le répertoire liste HubSpot, Slack et l’API Instagram Business, chacun ayant un rôle spécifique :
HubSpot → CRM workflows
Slack → HITL approval notifications
Instagram → marketing automation with compliance checks
L’idée de base est que les agents doivent transmettre les résultats vers des systèmes d’entreprise réels, et non seulement produire du contenu, tandis que des mécanismes d’approbation protègent tout ce qui est sensible.
WebSockets et streaming
WS /ws/agent-updates
WS /ws/agent-events
GET /api/stream/logs
Ce que chaque flux transporte :
/ws/agent-updates → periodically sends agent status updates
/ws/agent-events → streams queue/Redis events to frontend
/api/stream/logs → streams recent logs via server-sent response
Pour une interface utilisateur multi-agents, cette visibilité est essentielle. Les opérateurs doivent pouvoir voir quel agent est en cours d’exécution, quelle tâche est active, s’il y a une approbation en attente, et où le flux de travail a échoué.
L’interface frontend React
Le client est construit sur cette pile technologique :
React 18
Vite
React Router
Tailwind CSS
React Flow
Recharts
Selon le README, le tableau de bord combine un flux d’onboarding basé sur des conversations, l’état en temps réel des agents, une carte visuelle du flux de tâches, ainsi que des vues permettant de vérifier la conformité avec le PRD. Ses responsabilités sont :
1. Capture the user’s project vision
2. Display agent execution status
3. Visualize task flow
4. Show pending approval requests
5. Display reports and analytics
6. Show memory/monitoring data
7. Connect to WebSocket streams
8. Communicate with FastAPI through api.js
Le layout source est compact :
frontend/
└── src/
├── App.jsx
├── pages/
├── components/
└── services/api.js
App.jsx sert de shell authentifié, pages/ contient les vues relatives au flux de travail, aux analyses et à la surveillance, tandis que components/ fournit les éléments de base : panneaux pour le tableau de bord, écrans d’approbation, vues de conformité aux PRD et paramètres d’intégration. Chaque requête HTTP passe par services/api.js, qui gère les tentatives de réessai et le cache en un seul endroit, évitant ainsi que les problèmes réseau ne affectent les composants.
Le flux bout en bout
En résumé, le parcours principal à travers le système se déroule comme suit :
1. User submits business vision from React UI
2. Frontend sends request to FastAPI
3. FastAPI creates project/session
4. Cofounder Agent structures vision
5. Manager Agent converts vision into roadmap and assignments
6. Specialist agents execute assigned tasks
7. Results are stored in memory
8. HITL approval is requested where required
9. Reports are generated
10. Frontend displays logs, status, graph, reports, and outputs
Lorsqu’on le relie aux modules et méthodes réels, ce même flux ressemble à ceci :
React UI
↓ HTTP/WebSocket
FastAPI main.py
↓
AgentOrchestrator / EnhancedOrchestrator
↓
CofounderAgent.execute()
↓
ManagerAgent.execute()
↓
_execute_specialists()
↓
FinanceAgent / MarketingAgent / LegalAgent / MoneyAgent / SalesAgent
↓
MemoryManager + GraphMemory + VectorMemory
↓
ReportGenerator
↓
Dashboard + PDF/HTML/JSON Output
Chaque couche a une fonction précise : l’interface utilisateur gère les interactions, les orchestrateurs coordonnent les opérations, les agents les exécutent, les gestionnaires de mémoire conservent le contexte, et le générateur de rapports structure les résultats.
Pourquoi un orchestrateur de graphes plutôt qu’une chaîne
Les workflows multi-agents nécessitent plus qu’une série d’appels de fonction. Ils ont besoin de :
- State transitions
- Conditional routing
- Checkpointing
- Retry behavior
- Human approval interruptions
- Recovery after failure
- Resume from previous state
Le README qualifie les machines à états de LangGraph de couche d’orchestration précisément en raison de ces capacités. Une simple chaîne de prompts est linéaire :
A → B → C → Done
Un workflow métier prend des chemins différents en fonction des résultats intermédiaires :
A → B
├── if finance confidence low → retry Finance
├── if legal risk high → ask human approval
├── if marketing ready → generate campaign
└── if all complete → generate report
Un faible niveau de confiance financière déclenche une tentative de nouveau, un risque juridique élevé nécessite une révision par un humain, et le rapport final attend que toutes les branches soient terminées. Encodé sous forme d’appels séquentiels codés en dur, cela devient rapidement un enchevêtrement de conditions ; un graphique avec des nœuds, des arêtes et des points de contrôle explicites le rend inspectable et permet de reprendre son exécution.
Ce que la conception fait bien
- Frontières claires entre les agents : chaque agent est responsable d’un domaine métier unique, ce qui assure la cohérence des résultats et facilite l’ajout de nouveaux rôles.
- Orchestration axée sur les workflows : l’exécution est modélisée sous forme de workflow, et non comme une série de réponses aux demandes.
- Spécialistes en parallèle : les domaines de la finance, du marketing, du juridique, des finances et des ventes fonctionnent simultanément là où les dépendances le permettent, réduisant ainsi le temps total de traitement.
- Mémoire partagée : Neo4j, Qdrant, Redis et le stockage local permettent de gérer les relations, le rappel sémantique, les files d’attente, le cache et les solutions de secours.
- Sécurité grâce à l’intervention humaine : des mécanismes d’approbation garantissent que le système puisse être utilisé pour des décisions ayant des conséquences réelles.
- Observabilité en temps réel : WebSockets, journaux, chronologies, tableaux de bord et analyses permettent de suivre les activités des agents.
Renforcer la solution pour le déploiement en production
Les bases sont solides : un backend modulaire, des agents dédiés, une abstraction de la mémoire, un flux d’approbation et un frontend observable. Les prochaines étapes évidentes concernent la fiabilité, la sécurité, le suivi, l’évaluation et le contrôle des coûts :
1. Add distributed tracing with OpenTelemetry
2. Add LangSmith or custom LLM evaluation dashboards
3. Add cost tracking per agent and per workflow
4. Add stronger RBAC for users, agents, and approvals
5. Add persistent workflow checkpoints in Postgres or Redis
6. Add retry policies per agent type
7. Add queue-based background execution with Celery/RQ/Arq
8. Add structured output validation with Pydantic schemas
9. Add agent-level unit tests and golden-output evaluation
10. Add Docker production profiles and deployment manifests
Deux points méritent une attention particulière. Le suivi des coûts par agent et par flux de travail est essentiel, car les spécialistes travaillant en parallèle multiplient les appels aux LLM, et les coûts ne deviennent visibles qu’une fois mesurés. La validation des résultats structurés à l’aide de schémas Pydantic est importante, car chaque étape ultérieure, des écritures en mémoire aux rapports et mises à jour CRM, ne dépend que de la forme des données renvoyées par l’agent.
Points clés
- Considérez la couche d’orchestration comme le produit final ; l’LLM n’est qu’un composant au sein d’elle.
- Mettez en place un agent de type gestionnaire chargé de la décomposition afin que les résultats des spécialistes restent cohérents.
- Faites fonctionner des agents indépendants en parallèle, avec des délais d’expiration par agent, et gérez explicitement les échecs partiels.
- Attribuez à chaque stockage en mémoire une fonction spécifique : un graphe pour la traçabilité, des vecteurs pour le rappel, et des files d’attente pour la coordination.
Lectures complémentaires
- Agents avec validation dans LangGraph : interrupt(), checkpoints et stockage — Construire un agent LangGraph étape par étape : un graph ReAct explicite, une validation humaine via interrupt(), et une mémoire inter-thread avec un stockage, pour aboutir à un assistant de boîte de réception qui demande d’abord.
- Routage, fan-out, ReAct, critique et validation : cinq patterns LangGraph — Découvrir cinq patterns de flux de travail pour des agents dans LangGraph, allant des routeurs et des boucles ReAct aux portes d’évaluation et à la validation humaine, ainsi que les contraintes nécessaires pour chacun en environnement de production.