5 défis de production dans les systèmes multi-agents et comment Deep Insight les a résolus

Construire un système multi-agents est désormais assez simple. C'est le passage en production qui fait commencer les véritables défis. Grâce aux frameworks open source et aux services cloud, vous pouvez mettre en place un agent en quelques jours. Quelques appels d'outils, quelques lignes de prompt, et vous obtenez quelque chose d'impressionnant en apparence. Mais dès que les équipes tentent de dépasser le stade du pilote pour passer à de véritables applications métier, elles se heurtent à un mur familier. Si vous avez déjà essayé de mettre un agent en production, ces frustrations vous rappelleront des souvenirs :

Pourquoi l'agent ne suit-il pas notre logique métier, ne saute-t-il pas des étapes de validation ou ne détecte-t-il pas les cas limites ?

Vous modifiez le prompt, ajoutez des exemples, changez de modèle. Les mêmes problèmes reviennent sans cesse. C'est parce que les agents ne suivent pas une séquence fixe d'instructions. Ils portent leurs propres jugements en fonction du contexte. Les instructions seules ne suffisent pas. Vous devez concevoir comment l'agent réfléchit, quand il vérifie et ce qu'il fait lorsque les choses tournent mal. C'est précisément pourquoi il est devenu essentiel d'aller au-delà de la seule ingénierie de prompt et de concevoir l'architecture cognitive complète de l'agent ainsi que son flux d'exécution.

Pour relever ces défis de front, l'équipe AWS Solutions Architecture a construit Deep Insight, un système multi-agents de qualité production. Dans cette série d'articles, nous partageons ce que l'équipe a appris de première main lors de la construction de Deep Insight, en trois articles. Nous expliquerons comment nous avons appliqué les techniques d'Ingénierie du Contexte proposées par Anthropic (architecture multi-agents, prise de notes structurée, human-in-the-loop, etc.) dans un environnement de production réel. Nous aborderons également les compromis que nous avons rencontrés en chemin (avec le code) et les enseignements opérationnels tirés du déploiement et de l'exécution de cet agent sur AWS.

Aperçu de la série d'articles

• Partie 1 : 5 défis de production dans les systèmes multi-agents et comment Deep Insight les a résolus.
• Partie 2 : Au-delà de la fenêtre de contexte : techniques d'Ingénierie du Contexte et application par Deep Insight.
• Partie 3 : L'ingénierie du harnais en pratique : passage de Deep Insight du développement à la production.

Ceci est la Partie 1 d'une série en trois parties. Elle définit les cinq défis fondamentaux que tout système multi-agents en production doit résoudre et montre comment chaque couche de la pile y répond, de Strands Agents SDK et Amazon Bedrock à Amazon Bedrock AgentCore, Application Load Balancer, et AWS Fargate. Les Parties 2 et 3 traitent de l'Ingénierie du Contexte et du déploiement en production.

Présentation de Deep Insight

Deep Insight est un système multi-agents qui transforme l'analyse de données complexes en insights automatisés. À partir d'un fichier CSV et d'un prompt en langage naturel, une hiérarchie d'agents spécialisés (Coordinator, Planner, Supervisor, Coder, Validator, Reporter et Tracker) collabore sur l'analyse. Ensemble, ils chargent les données, exécutent des analyses, génèrent des graphiques, valident les calculs et produisent un rapport professionnel (.docx) avec citations.

Nous explorerons l'architecture en détail plus tard. D'abord, voyons-le en action. Pour la démonstration, nous fournissons des données publicitaires d'une entreprise alimentaire fictive, Yummy Food (yummy-food-market.csv) avec un fichier de définitions de colonnes (column_definitions.json), et fournissons le prompt : Analyse ceci d'un point de vue ventes et marketing, génère des graphiques et des insights, et produis un rapport .docx. Deep Insight génère un plan d'analyse, le présente à l'utilisateur pour approbation et, une fois approuvé, exécute l'analyse.

La vidéo de démonstration de Deep Insight ci-dessous montre le flux de travail complet, du téléversement des données et de la révision du plan d'analyse jusqu'au streaming en temps réel et au téléchargement du rapport final.

Comment puis-je l'essayer ?

Deep Insight est disponible en open source sur GitHub avec un guide d'installation complet, et propose trois options de déploiement couvrant du développement à la production.

La première est la version Self-Hosted, qui s'exécute localement via la CLI. Elle est optimisée pour l'itération rapide avec un accès complet au code de chaque agent, prompt et flux de travail. Elle s'installe en environ 10 minutes, ce qui la rend bien adaptée au développement. (Une vidéo de démonstration de la version Self-Hosted est disponible sur YouTube.)

La deuxième est la version Web, une interface utilisateur basée sur un navigateur permettant de téléverser des données, de réviser les plans d'analyse (Human-in-the-Loop, ou HITL) et de télécharger des rapports, le tout sans écrire de code, ce qui la rend accessible aux non-développeurs. (La vidéo de démonstration précédente montre la version Web en action.)

La troisième est la version Managed AgentCore, une option de déploiement en production propulsée par Amazon Bedrock AgentCore, une plateforme pour créer, connecter et optimiser des agents à grande échelle, avec n'importe quel framework ou modèle. Cette version déploie les agents sur le runtime AgentCore, une capacité d'Amazon Bedrock AgentCore. Le système s'exécute entièrement dans un cloud privé virtuel (VPC) privé, avec un Code Interpreter personnalisé hébergé séparément sur AWS Fargate, et les agents s'exécutent simultanément dans des environnements isolés par utilisateur. C'est le bon choix lorsque vous avez besoin d'isolation des sessions et d'un déploiement dans un VPC privé. La partie 3 couvre son déploiement et ses opérations en détail.

Les trois partagent la même architecture multi-agents, de sorte qu'un agent validé en développement est déployé en production tel quel.

Présentation de la solution

Construire un système multi-agents de production demande plus que de bons prompts. Vous avez besoin de la pile technologique et de l'infrastructure appropriées pour répondre à la question de savoir comment les agents collaborent, comment ils raisonnent, comment vous les déployez, où ils exécutent du code en toute sécurité et comment vous surveillez la santé opérationnelle. Deep Insight résout des problèmes dans ces cinq domaines clés. Comme les agents génèrent à la fois du code et du contenu de rapport, nous couvrons également les contrôles d'IA responsable pour la production dans Solution detail 2.

Le diagramme d'architecture suivant (Figure 1) illustre cela en un coup d'œil. Les cases vertes représentent la structure multi-agents de Strands Agents, qui répond aux défis 1 et 2 du tableau précédent. Nous couvrirons cela en détail dans la prochaine section Solution detail 1: Multi-agent system design. Les composants d'infrastructure restants présentés dans le diagramme répondent aux défis 3, 4 et 5, que nous aborderons dans Solution detail 2: Production deployment and operations.

Figure 1 : Architecture de la solution

Solution detail 1 : Conception du système multi-agents

Deep Insight utilise une architecture multi-agents dans laquelle huit agents collaborent pour produire un livrable de haute qualité. Chaque agent travaille dans son propre contexte indépendant, n'effectue que ses tâches spécialisées et ne transmet que des résultats compressés.

Figure 2 : Structure multi-agents

Le Coordinator achemine les requêtes des utilisateurs, le Planner décompose les tâches en étapes discrètes, le Plan Reviewer recueille les commentaires des utilisateurs, et le Supervisor invoque les agents spécialisés appropriés selon le plan. Le Coder écrit et exécute le code d'analyse de données, le Validator vérifie les calculs, le Reporter génère le rapport final, et le Tracker suit l'avancement. Nous allons expliquer cela en trois couches :

• [1re Couche] Coordinator vers Planner vers Plan Reviewer : analyse de la requête et création du plan d'exécution.
• [2e Couche] Supervisor : orchestration des agents spécialisés.
• [3e Couche] Coder, Validator, Reporter, Tracker : exécution des tâches spécialisées.

Deux schémas clés du Strands Agents SDK sont combinés pour contrôler le flux d'exécution à travers ces agents. Premièrement, le schéma Graph définit l'ordre d'exécution et le flux des agents sous forme de graphe orienté. Les requêtes circulent du Coordinateur au Planificateur, puis au Réviseur de plan, puis au Superviseur, avec une branche conditionnelle revenant au Planificateur en cas de demande de révision. La détermination de l'étape suivante par condition rend les flux de travail complexes comme le HITL et la gestion des erreurs simples à mettre en œuvre. Deuxièmement, le schéma Agents-as-Tools permet au Superviseur d'invoquer des agents spécialisés (Coder, Validator, Reporter, Tracker) en tant qu'outils uniquement lorsque nécessaire. Chacun travaille dans un contexte indépendant et ne renvoie que des résultats, minimisant l'utilisation du contexte tout en préservant l'expertise du domaine.

Cette section montre comment l'architecture résout le routage, la planification et l'orchestration.

[1re couche] Coordinateur vers Planificateur vers Réviseur de plan

Cette couche transforme une requête utilisateur en un plan d'exécution approuvé.

1.1 Coordinateur (routage) : toutes les requêtes ne nécessitent pas une orchestration coûteuse

Le Coordinateur est le point d'entrée des requêtes utilisateur. Il traite directement les salutations de base et achemine les tâches complexes comme l'analyse de données vers le Planificateur avec un marqueur handoff_to_planner.

La décision de conception clé concerne le choix du modèle : comme le Coordinateur se contente de classer, il utilise le léger Claude Haiku, évitant les coûts de niveau Opus pour les simples salutations et offrant des réponses rapides.

# builder.py: conditional edges for routing decisions
builder.set_entry_point("coordinator")
builder.add_edge("coordinator", "planner", condition=should_handoff_to_planner)

Les conditions de routage proviennent du prompt du Coordinateur : toute requête nécessitant des outils, un raisonnement ou une réflexion en plusieurs étapes est dirigée vers le Planificateur.

1.2 Planificateur (création du plan) : les analyses complexes nécessitent une décomposition avant exécution

Dans la structure multi-agents de Deep Insight, l'agent Planificateur joue le rôle crucial de distribution des tâches entre les agents. Avant que le travail substantiel ne commence, il décompose les grandes tâches en étapes plus petites, et chaque agent spécialisé les exécute une à la fois, maintenant le contexte de chaque agent réduit.

Le Planificateur utilise un modèle Claude Opus avec l'Extended Thinking activé pour élaborer le plan d'analyse. Il organise le plan sous forme de [ ] liste de contrôle qui spécifie les tâches concrètes assignées à chaque agent, stockée dans une full_plan variable. Il décompose la requête en 5–10 étapes claires, comme le montre l'exemple suivant :

## title
Yummy Food Consumer Purchase Patterns and Advertising Effectiveness Analysis Report

## steps

### 1. Coder: Comprehensive Data Analysis and Insight Generation
- [ ] Load all data files from './data/*' path and understand structure
- [ ] Analyze consumer purchase history (patterns, preferences, customer segments)
- [ ] Analyze advertising data by channel (cost, effectiveness, channel comparison)
- [ ] Category-level analysis (fresh food, convenience food, health food ad effectiveness)
- [ ] Calculate key business metrics (conversion rate, CPA, ROAS, etc.)
- [ ] Generate visualizations (5+ charts, consumer segment charts)
- [ ] Derive strategic marketing insights
- [ ] Generate calculation metadata (for validation)

### 2. Validator: Calculation Verification and Citation Metadata Generation
- [ ] Identify verification targets and extract filter calculations
- [ ] Load data files directly and perform recalculations
- [ ] Verify accuracy of per-channel performance metrics
- [ ] Validate data consistency of visuals and graphs
- [ ] Generate citation metadata (reference numbers for verified items)

### 3. Reporter: Marketing Analysis Report Generation
- [ ] Write report overview
- [ ] Create structured report using verified analysis results
- [ ] Insert visualizations and analysis sections
- [ ] Present marketing strategy recommendations and improvement proposals
- [ ] Generate professional marketing report in DOCX format

1.3 Réviseur de plan

Le Réviseur de plan est un nœud HITL qui présente le plan à l'utilisateur et recueille une approbation ou des commentaires de révision. S'il y a des commentaires, il revient au Planificateur pour réviser le plan. S'il est approuvé, il transmet la tâche au Superviseur. Un nombre maximal de révisions (MAX_PLAN_REVISIONS) est fixé pour éviter les boucles infinies.

# builder.py: Plan Reviewer's bidirectional conditional edges
builder.add_edge("plan_reviewer", "planner", condition=should_revise_plan)
builder.add_edge("plan_reviewer", "supervisor", condition=should_proceed_to_supervisor)
builder.set_max_node_executions(25)

Dans la version Web, le Réviseur de plan affiche une fenêtre modale dans le navigateur où l'utilisateur lit le plan et l'approuve ou saisit des commentaires de révision. Un compte à rebours de 300 secondes approuve automatiquement le plan si aucune réponse n'arrive.

Figure 3 : exécution de l'agent Réviseur de plan dans l'interface web

Sans planification, l'agent décide de tout à l'exécution, une correction en cours de route invalide le travail précédent, et les utilisateurs n'ont aucune visibilité sur l'avancement. Avec le Planificateur et le Réviseur de plan, l'utilisateur peut examiner et réviser le plan, suivre la progression en temps réel et réexécuter uniquement une étape en échec.

[2e couche] Superviseur (orchestrateur) : les agents spécialisés ont besoin d'un chef d'orchestre

Le Superviseur exécute le full_plan du Planificateur dans l'ordre, en invoquant les agents de la couche 3 (Coder, Validator, Reporter, Tracker) en tant qu'outils enregistrés sur lui via Tool Use.

# nodes.py: registering sub-agents as tools on the Supervisor
agent = strands_utils.get_agent(
    agent_name="supervisor",
    system_prompts=apply_prompt_template(prompt_name="supervisor", prompt_context={}),
    model_id=os.getenv("SUPERVISOR_MODEL_ID", os.getenv("DEFAULT_MODEL_ID")),
    prompt_cache_info=(True, "default"),
    tool_cache=True,
    tools=[coder_agent_tool, reporter_agent_tool, tracker_agent_tool, validator_agent_tool],
    streaming=True,
)

Le prompt système du Superviseur définit des règles de flux de travail strictes :

• Ordre d'exécution obligatoire : Coder, Tracker, Validator, Tracker, Reporter, Tracker : après l'exécution de chaque agent, Tracker est invoqué pour suivre la progression, permettant au Superviseur de gérer l'état global de la tâche.
• Règle d'achèvement de section : le Superviseur ne passe pas à l'agent suivant tant que tous les éléments de la liste de contrôle pour l'agent en cours ne sont pas marqués [x].
• Préservation du contexte : le Superviseur transmet les variables clues et full_plan à chaque agent outil, maintenant l'intégralité du contexte et évitant toute perte d'informations.

[3e couche] Coder, Validator, Reporter, Tracker : la division du travail favorise la qualité

Chaque agent de la couche 3 (Coder, Validator, Reporter, Tracker) est encapsulé comme un PythonAgentTool et reçoit des appels Tool Use du Supervisor. Chacun est créé comme une instance Agent() indépendante dans le Strands SDK avec son propre prompt système, son identifiant de modèle et son ensemble d'outils.

Le Supervisor invoque les appels d'outils dans cet ordre, en se basant sur la liste de contrôle du Planner :

1. Coder – Charge les données, écrit et exécute le code d'analyse, produit des graphiques PNG, accumule les résultats dans all_results.txt, et laisse calculation_metadata.json pour vérification.
2. Tracker (1re passe) – Met à jour les éléments terminés de la liste de contrôle de [ ] à [x], ce que le Supervisor utilise pour décider s'il faut poursuivre.
3. Validator – Réexécute chaque calcul de calculation_metadata.json à partir des données sources. Les correspondances à 0.01 près sont validées, les divergences sont signalées. Les calculs vérifiés sont transmis à citations.json pour que le Reporter les cite.
4. Tracker (2e passe) – Reflète l'état d'achèvement du Validator dans la liste de contrôle.
5. Reporter – Lit all_results.txt et citations.json pour générer le rapport DOCX final en deux versions, avec et sans citations.
6. Tracker (3e passe) – Reflète l'état d'achèvement final de toutes les tâches.

Le Tracker s'exécute après chaque agent afin que le Supervisor puisse suivre la progression et faire respecter la règle d'achèvement (pas de passage à la suite tant que tous les éléments ne sont pas [x]). Comme il met à jour la liste de contrôle par raisonnement LLM sans outils, il ajoute peu de surcharge.

Configuration du modèle LLM par agent

Deep Insight adapte le modèle et les paramètres au rôle de chaque agent. Il ne s'agit pas d'une sélection de modèle. C'est une décision architecturale visant à optimiser le coût et la qualité.

Les agents Superviseur, Codeur et Rapporteur utilisent le Prompt Caching pour mettre en cache leurs prompts système et leurs définitions d'outils, réduisant les coûts de tokens d'entrée jusqu'à 90 pour cent sur les appels répétés. Le Coordinateur ne s'exécute qu'une seule fois, et le Validateur et le Traceur s'exécutent avec des contextes différents à chaque fois, de sorte que la mise en cache est inefficace pour eux et reste désactivée. Cette stratégie de mise en cache sélective est un compromis délibéré entre coût et performance.

Détail de la solution 2 : Déploiement en production et exploitation

Si Solution detail 1 définie ce que fait le système, cette section définit où et comment il s'exécute en toute sécurité. Tout ce qui suit concerne les décisions d'infrastructure pour les opérations de production. Plus précisément, cette section couvre l'environnement d'exécution sécurisé pour le code généré par LLM, et la visibilité opérationnelle pour l'équipe.

1. Exécution de code : le code généré par LLM a besoin d'un environnement d'exécution sécurisé

L'agent Coder écrit et exécute du Python pour l'analyse de données. Dans la version Self-Hosted, il s'exécute localement via subprocess.run(), mais en production (AgentCore), la sécurité et l'isolation sont essentielles. Exécuter du code généré par LLM directement sur un serveur de production est risqué : le modèle pourrait supprimer des fichiers système, épuiser les ressources dans une boucle infinie, ou accéder aux données d'analyse d'autres utilisateurs. Deep Insight résout ce problème avec des conteneurs éphémères par session sur AWS Fargate et un ALB. Ces composants ne s'exécutent pas de manière isolée. Comme le montre la Figure 1, le runtime AgentCore, l'ALB et les tâches Fargate s'exécutent tous dans le même VPC privé. Des VPC endpoints les connectent à Amazon Simple Storage Service (Amazon S3), Amazon Bedrock et Amazon Elastic Container Registry (Amazon ECR) sans traverser l'internet public. Les security groups restreignent les composants pouvant atteindre les conteneurs Code Interpreter. Les rôles AWS Identity and Access Management (IAM) limitent chaque composant aux seules ressources AWS dont il a besoin. Amazon CloudWatch collecte les journaux des conteneurs et les données d'observabilité d'AgentCore Observability, une capacité d'Amazon Bedrock AgentCore.

• Image Docker de conteneur personnalisée : un bac à sable pré-optimisé avec polices, bibliothèques système et packages Python pour le système multi-agents.
• Isolation des conteneurs : chaque session d'analyse obtient un conteneur Fargate indépendant dans un sous-réseau VPC privé sans accès direct à internet.
• Exécution en 2 étapes : le code généré par LLM est encodé en base64, envoyé via HTTP, écrit dans un fichier (étape 1), puis exécuté via subprocess (étape 2).
• Affinité de session : les cookies de sticky session de l'ALB acheminent un agent vers le même conteneur même lorsqu'il exécute du code plusieurs fois.
• Gestion des artefacts : les graphiques, rapports et journaux sont téléversés vers Amazon S3 une fois l'analyse terminée. Les conteneurs se terminent automatiquement après une heure.

L'isolation des conteneurs protège l'infrastructure, mais elle ne régit pas ce que les agents génèrent. L'agent Validator revérifie les calculs. Il ne détecte pas les instructions d'injection de prompt cachées dans les données téléversées ni ne filtre le texte généré par LLM à la recherche de contenus nuisibles ou non fondés. Pour les déploiements en production, nous recommandons d'ajouter Amazon Bedrock Guardrails comme contrôle d'IA responsable : appliquez des filtres de contenu et la détection d'attaques par prompt aux prompts des utilisateurs et aux données téléversées, et appliquez des vérifications contextuelles de fondement aux sorties des agents afin que le texte du rapport reste fondé sur les données sources et les calculs vérifiés.

2. Opérations et surveillance : les équipes ont besoin de visibilité

Un système de production n'est pas complet avec le code seul. L'équipe doit évaluer la santé du système, diagnostiquer les problèmes et examiner les résultats, c'est pourquoi Deep Insight fournit une Web UI et un tableau de bord Ops.

Web UI (deep-insight-web)

Une interface web basée sur FastAPI qui communique avec le backend via l'AgentCore Native Protocol (boto3.invoke_agent_runtime()). Les utilisateurs téléversent des données et saisissent un prompt, puis suivent la progression via le streaming Server-Sent Events (SSE). Lorsque le plan est généré, une fenêtre modale permet à l'utilisateur de l'approuver ou de donner un retour de révision (HITL). Le rapport final peut être téléchargé directement. Le coréen et l'anglais sont tous deux pris en charge.

Figure 4 : capture d'écran de la version web de Deep Insight

Tableau de bord Ops (deep-insight-web/ops)

Le tableau de bord Ops est facultatif. Deep Insight fonctionne très bien sans lui, mais il ajoute ces fonctionnalités pour les équipes qui en ont besoin :

• Suivi des tâches : toutes les métriques des tâches d'analyse, y compris le statut, l'utilisation de tokens et le temps écoulé, sont enregistrées dans Amazon DynamoDB.
• Alertes d'échec : lorsqu'une analyse échoue, un e-mail est immédiatement envoyé aux administrateurs via Amazon SNS.
• Tableau de bord admin : un tableau de bord admin dédié est protégé par une authentification JSON Web Token (JWT) via Amazon Cognito pour une surveillance sécurisée des tâches.

Figure 5 : capture d'écran du tableau de bord Ops de Deep Insight

Figure 6 : vue détaillée du tableau de bord Ops de Deep Insight

Extension de l'architecture de Deep Insight

L'architecture multi-agents de Deep Insight ne se limite pas au seul domaine de la génération de rapports d'analyse de données. Les deux exemples suivants démontrent que les principes de conception d'orchestration hiérarchique restent efficaces dans des domaines entièrement différents.

Cas 1 : LG Electronics : système d'extraction d'insights marketing propulsé par l'IA agentique

La Division des ventes coréenne de LG Electronics a construit ChatInsight sur la même architecture multi-agents que Deep Insight, où les demandes d'analyse de données prenaient 2 à 3 semaines et perdaient leur intention entre les marketeurs et les data scientists. Le Coordinator achemine selon la complexité, le Planner suit les tâches, et le Supervisor orchestre le Coder et le Reporter, avec un état inter-agents transmis de manière cumulative via un fichier all_results.txt. Une analyse qui prenait 3 jours prend désormais 30 minutes, soit une amélioration de productivité de 288x. Les marketeurs qui ne connaissent pas SQL peuvent laisser l'agent explorer les données et proposer des stratégies (voir le système d'extraction d'insights agentique de LG Electronics sur le blog AWS Tech).

Figure 7 : architecture du système d'insights marketing agentique de LG Electronics

Cas 2 : TechRecon : agent de reconnaissance technologique propulsé par l'IA (re:Invent 2025)

Présenté à AWS re:Invent 2025 (session SNR203), TechRecon applique l'architecture de Deep Insight à la stratégie technologique. À partir d'une entreprise et d'un secteur donnés, un Researcher collecte les tendances technologiques, le Coder analyse, le Validator vérifie et le Reporter produit une Analyse de paysage et un Article de position technique. L'architecture est quasi identique à celle de Deep Insight, construite avec le modèle Graph du Strands Agents SDK ainsi qu'Extended Thinking et Prompt Caching, avec le Researcher remplaçant le Coder comme agent d'exécution principal. Cela montre que cette conception est un modèle à usage général : échangez les rôles et les prompts des agents, et la même structure d'orchestration résout des problèmes totalement différents.

Figure 8 : Résultats de TechRecon

(En savoir plus : TechRecon GitHub | Vidéo de la session AWS re:Invent)

Conclusion

Construire un agent qui fonctionne en production n'est pas une question de capacité du modèle. C'est une question d'architecture. Deep Insight offre une réponse éprouvée :

• Gestion du flux de travail : le modèle Graph du Strands Agents SDK définit l'ordre d'exécution entre les agents et met en œuvre la ramification HITL, tandis que le modèle Agents-as-Tools permet au Supervisor d'invoquer des agents spécialisés uniquement lorsque c'est nécessaire.
• Moteur de raisonnement : nous attribuons les modèles Claude d'Amazon Bedrock par rôle (Haiku, puis Opus, puis Sonnet) pour optimiser le coût et la qualité.
• Déploiement : Amazon Bedrock AgentCore fournit un runtime géré avec isolation des sessions, déploiement dans un VPC privé et observabilité OpenTelemetry.
• Exécution du code : un Application Load Balancer associé à Amazon Elastic Container Service (Amazon ECS) sur Fargate isole l'exécution du code généré par les LLM dans des conteneurs sandbox éphémères par session, prévenant ainsi les problèmes de sécurité tels que l'accès aux fichiers système, l'épuisement des ressources et la divulgation involontaire de données.
• Opérations : le streaming SSE de l'interface Web et le tableau de bord Ops (DynamoDB + Cognito + SNS) offrent une visibilité à l'ensemble de l'équipe.

Le système d'analyse marketing de LG Electronics et le cas TechRecon à re:Invent 2025 ont validé ces principes de conception.

Dans la Partie 2, nous examinons quatre couches de techniques de Context Engineering pour surmonter les limites de la fenêtre de contexte par-dessus cette architecture, de l'isolation au niveau de l'architecture à la conception des prompts, l'optimisation des outils et les garanties de vérification, en comparant notre approche aux travaux d'ingénierie d'Anthropic.

Deep Insight est open source. Explorez le code et adaptez-le à votre propre domaine.

• GitHub
• Atelier : Deep Insight Workshop (Anglais | Coréen)

À propos des auteurs