Le contexte d’un agent sort du prompt pour devenir une couche de données exploitable. Zep a construit Konig pour servir des millions de graphes temporels séparés par utilisateur, équipe ou projet, avec provenance, contrôle d’accès et récupération sous 200 ms. La mémoire devient ainsi un système de données gouverné, pas un historique de conversation.

Cette évolution rejoint l’architecture décrite sur InfoQ : les équipes de données exposent via MCP des outils qui portent déjà schémas, règles métier et sémantique. L’agent n’a plus à recevoir toutes les tables dans son context window ; il sélectionne les capacités utiles, ce qui réduit les tokens et limite les accès inutiles.

Salesforce applique ce principe à l’échelle d’une suite métier avec Headless 360 et Data 360 MCP Server. Les agents découvrent relations, permissions, workflows et règles de validation déjà présentes dans la plateforme. Pour les développeurs, l’enjeu se déplace : concevoir le contexte comme une API gouvernée, versionnée et observable devient une responsabilité d’architecture.

Le contrôle des agents ne repose plus seulement sur leur prompt. Dify traite désormais l’agent comme une ressource maintenue, réutilisable dans plusieurs workflows, avec outils gérés, sandbox, journal de build et observabilité. Configuration, accès, traçage et points de revue deviennent ainsi des composants explicites du runtime que l’équipe peut faire évoluer sans recopier l’agent.

Microsoft durcit de son côté le contrat d’extension de son Agent Framework Python. Les middlewares redeviennent une séquence validée de façon cohérente dans les agents, le harness, les clients et Foundry. Pour les développeurs, cette rigueur réduit les chemins implicites et rend les interceptions de tool calling ou de politique plus prévisibles.

The New Stack décrit la même maturation côté architecture : un agent de production dépend de contrats d’outils, de permissions, de garde-fous et de tracing, pas seulement du modèle. La conséquence est concrète : les équipes doivent versionner le comportement du harness comme du code applicatif et tester les contrôles au même titre que les sorties du LLM.

Les coding agents passent du tour interactif à l’exécution prolongée. WIRED a repéré dans Codex un `Persistent mode` encore en test, capable de continuer jusqu’à être mis en sommeil et de créer ses propres tâches de suivi. OpenAI précise que cette persistance ne doit pas élargir les permissions déjà accordées.

Cette autonomie agrandit pourtant le rayon d’impact d’une erreur. The Register rapporte qu’une chaîne de prompt injection contre Claude Code Auto Mode a mené à l’exécution de code dans 60 à 80 % de petits échantillons de test. Le chercheur recommande de traiter le sandbox système et le contrôle réseau comme la vraie frontière.

Un incident relaté par Tom’s Hardware montre l’autre risque : un test de nettoyage piloté par Claude a supprimé le répertoire personnel d’un développeur avant d’être arrêté. Pour les équipes, l’exécution longue doit donc partir d’un workspace jetable, sans secrets ni répertoire personnel, avec snapshots et sortie réseau bornée.