Le contexte devient le nouveau périmètre : Gérez les agents d'IA grâce à une livraison programmable des applications

Le contexte n’est pas une abstraction. Il se trouve directement dans la charge utile. Voici à quoi ressemble une requête MCP en conditions réelles :

POST /agent/v1/invoke HTTP/1.1

Hôte : agentmesh.internal

Autorisation : Bearer xyz123

Type de contenu : application/json

Version X-MCP : 1.0

{

"contexte": {

    "utilisateur": { ... },

    "objectif": "...",

    "prior_messages": [ ... ],

    "task_state": { ... },

    "sécurité": { ... }

  },

"input": { "prompt": "Visualisez-le maintenant avec un graphique rapide." }

 }

Ce bloc de contexte est indispensable. Il représente la mémoire active de l’agent. Il rassemble tout ce que l’agent « sait » et chaque hypothèse qui guidera ses actions. Chaque étape le transmet tel quel : sans compression, parfois sans vérification, et presque toujours de plus en plus obsolète au fil du temps.

Ce bagage crée en fin de compte une dérive de contexte. La dérive survient lorsque :

• Les anciens objectifs et l’état des tâches restent après que vous êtes passé à autre chose.
• Les messages précédents s'accumulent, alourdissant les requêtes et perturbant les agents.
• Les balises de sécurité persistent là où elles n'ont pas leur place.
• Plusieurs agents mettent à jour le même thread sans nettoyer les éléments superflus.

Lorsque l'agent n°4 prend le relais, il prend des décisions basées sur des instructions dépassées, des contrôles d’accès obsolètes et des « objectifs » que plus personne ne considère. Les agents ne se plaignent jamais. Ils font simplement des erreurs avec assurance et passent le chaos à la prochaine étape.

Si vous réduisez encore votre plateforme de gestion du trafic à un simple répartiteur de charge, félicitations. Vous jouez aux dames alors que tous les autres jouent aux échecs.

Dans les architectures agentiques, la livraison programmable des applications est la seule couche qui offre :

• Visibilité totale sur chaque requête
• Le pouvoir d'inspecter, de modifier, de bloquer ou de purifier le contexte
• Ne dépend d’aucun avis ni souvenir d’un agent

Ne chargez pas les agents avec toute l’histoire à chaque requête.

• Réduisez prior_messages aux N derniers échanges.
• Faites expirer automatiquement les objectifs selon le temps ou un changement d’état.
• Abandonnez task_state lorsque l’intention change de continuation à nouvelle tâche.

Vous imposez maintenant des limites de mémoire et une discipline cognitive avant même que l’agent ne traite les données.

Si votre bloc de contexte indique security.classification = confidential mais que vous vous apprêtez à utiliser une API publique de synthèse, vous devez déployer une règle programmable à la périphérie pour bloquer, censurer ou masquer les champs sensibles et vérifier l’étendue des accès à chaque requête. Les grands modèles de langage (LLM) ne contesteront pas vos règles ; ils risquent simplement de divulguer des informations.

Un utilisateur est-il passé de « résumer les indicateurs trimestriels » à « créer une présentation » ? Il faut réinitialiser le contexte, pas simplement l'accumuler. Quand l’intention de la demande change mais que le contexte contient encore d’anciennes finalités et l’état des tâches, supprimez-le et repartez à zéro. C’est ainsi que vous évitez de résoudre un problème d’hier avec des données d’aujourd’hui.

Votre couche de prestation d’application doit suivre :

• Évolution des tailles des jetons dans les blocs de contexte
• Taux de croissance des messages précédents
• Modèles de discordance entre objectifs et tâches par agent

Vous repérez ainsi les gonflements et dérives contextuelles avant qu’ils ne deviennent ingérables. La surveillance vous fournit des réponses claires lorsque la direction s’étonne du comportement sûr de lui de vos « agents autonomes ».