Skip to content
Produit

Pourquoi l'état gouverné surpasse la mémoire persistante pour l'IA d'entreprise

OpenAI et Amazon ont annoncé un Stateful Runtime Environment pour les agents Frontier. Voici pourquoi l'architecture d'état gouverné de JieGou — où chaque mutation d'état est visible, auditable et périmétée — est la meilleure approche pour l'IA d'entreprise.

JT
JieGou Team
· · 6 min de lecture

Le 27 février 2026, OpenAI et Amazon ont annoncé un Stateful Runtime Environment pour les agents Frontier — des systèmes de fichiers persistants et une mémoire qui survivent entre les appels d’outils au sein des sessions d’agents. C’est une capacité significative. Les agents qui oublient tout entre les exécutions sont fondamentalement limités.

Mais la mémoire persistante seule ne suffit pas pour l’IA d’entreprise. La question n’est pas si les agents doivent se souvenir — c’est qui contrôle ce dont ils se souviennent, et qui peut le voir.

La promesse et le péril de la mémoire persistante des agents

La mémoire persistante rend les agents considérablement plus capables. Un agent qui se souvient du ton de communication préféré de votre équipe, de vos seuils d’approbation, de vos segments clients — cet agent s’améliore à chaque exécution.

Le péril est tout aussi clair. Un agent avec une mémoire persistante non contrôlée peut :

  • Accumuler des faits périmés ou incorrects qui dégradent la qualité de sortie au fil du temps
  • Faire fuiter des informations entre départements quand la mémoire n’est pas périmétée
  • Résister aux audits de conformité quand il n’y a pas de trace de ce qui a été appris, quand et d’où
  • Créer des dépendances cachées quand les workflows en aval reposent sur un état d’agent opaque

13 des 14 capacités stateful : déjà dans JieGou

Quand nous avons évalué le Stateful Runtime de Frontier par rapport à l’architecture existante de JieGou, nous avons trouvé que 13 des 14 capacités stateful étaient déjà couvertes :

CapacitéCouverture JieGou
État entrée/sortie structuréSchémas I/O de recette avec validation
Flux de données étape à étapeMap previousStepOutputs dans l’exécuteur de workflow
Branchement conditionnel sur l’étatConditionStep avec évaluation d’expression
Gestion d’état de boucleLoopContext avec suivi d’itération
État d’exécution parallèlePromise.allSettled avec cascade de défaillances
État de porte d’approbationApprovalPauseError avec reprise de checkpoint
Mémoire partagée (multi-agents)Map sharedMemory sur StepExecutionContext
État de boucle de convergenceConvergenceLoop avec injection de feedback d’évaluation
Checkpoint/repriseWorkflowCheckpointV2 avec suivi par étape
État de récupération de connaissancesContexte RAG avec résolution auto-contexte
État de voix de marqueProfils de voix de marque avec périmètre départemental
État de glossaireInjection de contexte glossaire par département
État d’apprentissage few-shotCuration d’exemples few-shot depuis l’historique d’exécution

La seule lacune : la mémoire persistante d’agent inter-workflows — les faits qui persistent entre des exécutions de workflows séparées.

La 14e capacité : Agent Workspaces

Nous avons construit les Agent Workspaces pour combler cette lacune — mais avec une décision de conception critique : chaque élément d’état persistant est gouverné par défaut.

Un Agent Workspace est un magasin clé-valeur structuré périmétré à un agent au sein d’un compte. Chaque entrée suit :

  • Clé : Un identifiant descriptif (ex. preferred_tone, primary_contact, approved_budget)
  • Valeur : Le fait appris (sérialisable en JSON, max 10 KB)
  • Source : Comment l’entrée a été créée — auto (extrait par LLM), user (défini manuellement) ou step_output (capturé depuis une étape de workflow)
  • Run ID : Quelle exécution de workflow a produit cette entrée
  • Horodatage : Quand elle a été mise à jour pour la dernière fois

Ces métadonnées de provenance sont ce qui sépare l’état gouverné de la mémoire persistante brute.

Contraintes par conception

  • 100 entrées maximum par workspace — empêche la croissance non bornée de la mémoire
  • 10 KB par valeur d’entrée — garde les entrées focalisées et récupérables
  • ~2 000 tokens de budget pour l’injection dans le prompt — le contexte du workspace ne cannibalise pas la tâche réelle
  • Périmètre départemental — les workspaces héritent des mêmes contrôles d’accès que le reste de JieGou

Pourquoi l’état gouverné > la mémoire persistante brute

DimensionÉtat gouverné (JieGou)Mémoire persistante brute (Frontier SRE)
VisibilitéChaque entrée a une provenance (source, run ID, horodatage)L’état vit à l’intérieur du runtime de l’agent
AuditabilitéIntégré au journal d’audit ; les équipes de conformité peuvent inspecterL’état du runtime n’est pas exposé à la couche de gouvernance
PérimétragePérimétré par département avec application du RBACPérimétré par session ; périmètre inter-workflows flou
Contrôle de tailleLimites strictes (100 entrées, 10 KB chacune)Persistance système de fichiers — pas de limites inhérentes
PéremptionHorodatages + curation manuelle permettent l’hygiène des faitsPas de mécanisme intégré pour l’expiration des faits
ConformitéAccès API pour les vérifications de conformité automatiséesNécessite des outils personnalisés pour inspecter l’état de l’agent

La différence fondamentale : le Stateful Runtime de Frontier rend les agents plus capables. L’état gouverné de JieGou rend les agents plus capables et plus auditables.

Comparaison avec le Stateful Runtime de Frontier

Le Stateful Runtime Environment de Frontier est une ingénierie impressionnante. Des systèmes de fichiers persistants, une mémoire inter-appels d’outils et une intégration avec l’infrastructure d’Amazon créent un environnement d’exécution puissant pour les agents autonomes.

Mais il est conçu pour la capacité de l’agent, pas pour la gouvernance d’entreprise. L’état du runtime est optimisé pour l’usage de l’agent — pas pour que les équipes de conformité inspectent, pas pour que les frontières départementales soient appliquées, pas pour que les pistes d’audit capturent.

JieGou aborde l’état persistant depuis la direction opposée : gouvernance d’abord, capacité ensuite. Les Agent Workspaces sont moins flexibles qu’un système de fichiers complet — et c’est le but. Les contraintes (entrées structurées, limites strictes, suivi de provenance) sont des fonctionnalités, pas des limitations.

Conclusion : la gouvernance est le différenciateur

La mémoire persistante est le minimum pour des agents IA capables. Chaque plateforme l’aura bientôt.

Le différenciateur n’est pas si les agents peuvent se souvenir — c’est si vous pouvez voir, contrôler et auditer ce dont ils se souviennent. Pour l’IA d’entreprise, l’état gouverné n’est pas un nice-to-have. C’est l’exigence qui sépare les déploiements de production des expériences scientifiques.


En savoir plus sur l’architecture de gouvernance de JieGou ou comparer avec OpenAI Frontier.

governance state agent-workspace persistent-memory openai-frontier enterprise compliance security
Partager cet article

Vous avez aime cet article ?

Recevez des astuces workflows, des mises a jour produit et des guides d'automatisation dans votre boite de reception.

No spam. Unsubscribe anytime.