Agents auto-améliorateurs : guérison, apprentissage et changement contrôlé
Des agents capables d’améliorer eux-mêmes sans risque : auto-réparation en temps de exécution, apprentissage entre différentes exécutions, ainsi que des modifications qui ne sont déployées qu’après évaluation et utilisation de canaris, sur LangGraph.
Sources: Self-improving Agentic AI Applications — Feedback loop integration
Un agent de type ReAct planifie bien, utilise des outils, obtient des informations et termine des tâches en plusieurs étapes. Les problèmes commencent une fois qu’il est en production et que quelqu’un se demande ce qui se passe s’il commet une erreur. Peut-il s’en apercevoir ? Peut-il se remettre sans devoir redémarrer tout le flux de travail ? Peut-il se souvenir de ce qui a fonctionné, apprendre des corrections des utilisateurs et améliorer progressivement son propre comportement ?
Les gens regroupent ces questions sous l’appellation « boucle de feedback de l’agent », mais cette appellation est trompeuse. L’architecture présentée ci-dessous associe LangGraph à MongoDB, Gemini sur Vertex AI et Arize Phoenix, et couvre la récupération en temps de exécution, l’apprentissage à partir de l’expérience, l’évaluation continue et l’amélioration contrôlée.
Pourquoi la boucle naïve est dangereuse
La version simpliste d’une boucle de feedback est la suivante :
Agent produces answer
↓
LLM reflects on answer
↓
Agent learns
C’est attrayant car c’est simple, mais c’est aussi risqué. Lorsqu’un LLM évalue sa propre sortie et modifie immédiatement son comportement futur, une erreur peut se transformer en leçon, cette leçon en mémoire, et cette mémoire peut alors influencer des milliers de décisions ultérieures.
Une conception plus sûre repose sur un principe différent : l’agent corrige l’exécution en cours, la plateforme apprend à partir de nombreuses exécutions, et une couche de contrôle décide ce qui deviendra le comportement de production.
Exemple concret : un agent recommande des codes de rémunération ou de déduction. Lors d’une exécution, il choisit le mauvais code parce qu’il n’a jamais récupéré de politique de rémunération spécifique à l’état. Le processus d’apprentissage naïf se déroule comme suit :
Agent made mistake
↓
Agent reflects
↓
"Always retrieve state policy"
↓
Write lesson to memory
↓
Future agents use lesson
Plusieurs choses peuvent mal se passer. Le diagnostic peut être incorrect. La règle peut ne s’appliquer qu’à un seul type de transaction de paie. Un changement de politique ultérieur peut rendre la leçon obsolète. Des entrées malveillantes de la part de l’utilisateur peuvent influencer le résultat. De plus, la leçon peut aider dans certains cas tout en nuissant à d’autres.
Ainsi, une meilleure conception considère une leçon comme une hypothèse et non comme une vérité absolue.
Production failure
↓
Capture evidence
↓
Evaluate the run
↓
Identify recurring failure
↓
Generate lesson candidate
↓
Gather supporting and contradicting evidence
↓
Validate
↓
Canary test
↓
Activate
Le changement est subtil. L’agent ne se réécrit pas constamment. La plateforme qui l’entoure évalue et fait évoluer constamment l’agent.
Trois plans ayant des autorités différentes
Il est utile d’imaginer trois plans reliés entre eux.
+------------------------------------------------+
| RUNTIME PLANE |
| |
| plan -> act -> validate -> repair -> respond |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| LEARNING PLANE |
| |
| evaluate -> diagnose -> cluster -> learn |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| CONTROL PLANE |
| |
| test -> approve -> canary -> rollout -> rollback|
+------------------------------------------------+
Chaque plan fonctionne à son propre rythme et possède un degré d’autorité différent. Le plan de exécution opère en quelques millisecondes ou secondes, et sa seule tâche est d’accomplir la demande en cours de manière fiable. Le plan d’apprentissage analyse de nombreuses exécutions sur une période allant de quelques minutes à des jours, afin de déterminer ce que révèlent les données collectées. Le plan de contrôle décide si une amélioration proposée est suffisamment sûre pour être intégrée dans le comportement de production. Parmi les choix de conception d’une plateforme d’agent adaptatif, peu sont aussi importants que le fait de maintenir ces trois plans séparés.
1. Auto-réparation en temps réel
Commençons par le problème immédiat : une appel à outil échoue. Une implémentation simpliste se contente de réessayer.
Tool failed
↓
Retry
↓
Retry
↓
Retry
Cependant, réessayer ne constitue pas une solution autonome. Pour se remettre, il faut savoir ce qui a échoué et choisir une stratégie de récupération adaptée. Un flux de travail LangGraph plus solide ressemble davantage à ceci :
User Request
|
v
Clarification Gate
|
v
Retrieve Context
|
v
Plan
|
v
Proposed Action
|
v
Action Guard
|
v
Execute Tool
|
v
Sanitize Tool Result
|
v
Validate Tool Result
|
v
Reason
|
v
Validate Answer
|
+------ uncertain ------> Critic
| |
| v
| Policy Router
| / | | \
| PASS REPAIR HUMAN FAIL
| |
+---------------------------+
|
v
Response
Quelques éléments de ce graphique méritent une attention particulière.
Valider avant d’agir
Imaginez un agent capable d’effectuer des actions ayant des effets secondaires : mettre à jour les données des employés, créer une déduction de salaire, soumettre une transaction, modifier un compte ou envoyer une notification. Vérifier le résultat a posteriori est trop tardif. L’architecture nécessite un garde d’action avant toute modification ayant des conséquences. Ce garde évalue les permissions, les règles métier, les preuves disponibles, le fait que l’action soit réversible, le niveau de risque, ainsi que la nécessité d’une approbation humaine. Ce n’est qu’alors que l’outil peut être exécuté.
Cela redéfinit la notion de validation. La question n’est plus « l’action était-elle correcte ? » mais devient, de manière bien plus sûre, « disposons-nous de preuves et d’autorités suffisantes pour l’autoriser ? »
Les résultats produits par l’outil ne sont pas non plus fiables
Un autre risque est négligé. Les agents lisent du contenu provenant de sites web, de documents, d’API, de moteurs de recherche, de bases de données et d’autres agents, et ce matériel se retrouve dans le contexte du LLM. Les résultats des outils constituent donc une autre voie d’injection de prompts, ce qui explique pourquoi un sanitiseur de résultats d’outil déterministe doit être inséré entre l’exécution de l’outil et le raisonnement.
External Tool
|
v
Tool Result
|
v
Sanitizer
|
v
Validator
|
v
LLM
Les tâches typiques d’un outil de nettoyage incluent l’application de contraintes sur le type et la longueur du contenu généré, le rejet des structures mal formatées, l’échappement des textes ressemblant à des instructions, ainsi que l’identification des tentatives d’injection probables. Une contrainte est absolue : aucun LLM ne doit être utilisé pour examiner des textes susceptibles d’être hostiles.
Séparer le validateur du critique
Un schéma courant consiste à demander à un LLM « Cette réponse est-elle correcte ? » à chaque requête. Cela augmente la latence et les coûts, et confère au modèle trop de pouvoir. La validation déterministe doit avoir la priorité, par exemple :
Schema correct?
Required fields present?
Allowed value?
Business invariant satisfied?
Evidence exists?
Policy satisfied?
Known contradiction detected?
Si un logiciel peut prouver qu’une réponse est fausse, il n’y a aucune raison de demander à un autre modèle de répondre. Seule une véritable ambiguïté sémantique parvient au critiqueur, et même dans ce cas, celui-ci ne dirige pas le flux de travail. Son rôle consiste en un diagnostic, dans les termes suivants :
{
"correctness": 0.61,
"groundedness": 0.92,
"uncertainty": 0.73,
"defects": [
"missing_authoritative_evidence"
]
}
Un routeur de politique déterministe choisit ensuite parmi quatre résultats :
PASS
REPAIR
HUMAN REVIEW
SAFE FAIL
La séparation est claire : le LLM fournit des preuves et un jugement, tandis que la politique logicielle détient l’autorité.
La réparation doit modifier la stratégie
Une nouvelle tentative n’a de valeur que lorsque quelque chose a changé. Prenons un agent qui agit ainsi :
Search policy
↓
Generate recommendation
↓
Fail validation
Si la réparation répète la séquence ci-dessous avec la même requête, les mêmes preuves et la même méthode de raisonnement, ce n’est pas une récupération. C’est de la répétition.
Search policy
↓
Generate recommendation
Un agent fiable surveille quelques champs.
failure signature
strategy fingerprint
attempt ID
repair strategy
remaining budget
quality delta
Une règle simple s’applique alors.
same failure
+
same strategy
+
same evidence
=
do not retry
Lorsque la même panne se produit avec la même stratégie une seconde fois, l’agent doit changer de stratégie, transférer la tâche à une personne ou échouer de manière sûre. Un simple retry_count ne suffit pas à gérer cela, c’est pourquoi l’autoguérison en production nécessite des budgets de réparation. Ces derniers peuvent limiter le nombre d’appels aux LLM, aux outils, le temps écoulé, les coûts et les tentatives de réparation sémantique. L’objectif n’est pas de persévérer jusqu’à ce que quelque chose fonctionne, mais plutôt d’utiliser une quantité limitée de ressources pour des stratégies de récupération réellement différentes.
Vérifier que la réparation a été efficace
Même différentes tentatives peuvent échouer à améliorer la situation. Supposons qu’un évaluateur note la qualité du résultat initial :
quality score = 0.54
Après la première réparation :
quality score = 0.55
Après le deuxième :
quality score = 0.56
Sur le papier, c’est une amélioration, mais en pratique, c’est un blocage. Un portail delta de réparation y remédie.
delta = score_after_repair - score_before_repair
Lorsque plusieurs réparations ne procurent que des améliorations négligeables, les ressources cessent de circuler.
small delta
+
small delta
=
human review or safe failure
Cela permet d’éviter l’une des défaillances les plus fréquentes des agents : la boucle de raisonnement coûteuse qui donne l’impression d’être active sans produire presque aucun résultat.
Le contrôle humain est un choix de routage
Le contrôle humain ne devrait pas être considéré comme une défaillance. Pour certaines tâches, c’est simplement la décision finale appropriée. De plus, le « contrôle humain » englobe plusieurs résultats différents.
Human
|
+-----------+-----------+
| | |
Approve Edit Reject
| | |
Continue Validate Safe Fail
Request Repair
|
v
Repair
Chaque issue se déroule différemment, il convient donc que chacune soit affichée explicitement dans le graphique. Le modèle d’interruption et de reprise de LangGraph convient parfaitement à cela, car le flux de travail peut être sauvegardé en point de contrôle, suspendu, puis repris lorsque le réviseur répond.
2. Apprendre de l’expérience au fil des exécutions
La correction en temps de exécution répond à la question de savoir comment récupérer cette demande. L’apprentissage à partir de l’expérience se demande ce que cette demande enseigne sur les demandes futures. Il relève généralement du second plan. Une fois que l’agent a répondu :
run_completed
|
v
Evaluation worker
|
v
Gather feedback
|
v
Reflection
|
v
Candidate lesson
Nul n’a besoin d’attendre que l’un des LLM réfléchisse à ce qu’un autre aurait pu apprendre. La latence reste faible, et l’évaluation hors ligne peut être bien plus approfondie.
Les retours ne sont pas la vérité
Les signaux arrivent de multiples sources : un utilisateur appuie sur « moins » ; un expert corrige une réponse ; une API rejette une transaction ; un audit de conformité détecte une erreur deux semaines plus tard. Ceux-ci ne sont pas équivalents. Prenons en compte les premières paires d’équivalences qui échouent :
thumbs up != correct
thumbs down != incorrectuser correction != authoritative rule
Les retours doivent donc être conservés en tant que preuves brutes et classés selon leur fiabilité, à peu près comme ceci :
Authoritative business outcome
>
Expert human label
>
Deterministic rule
>
Calibrated evaluator
>
User feedback
>
Agent self-confidence
Cela empêche que les sentiments ne soient confondus avec la vérité factuelle.
Les meilleurs retours arrivent souvent en retard
Les agents lancent fréquemment des workflows dont le succès n’est pas immédiatement visible.
Agent recommends payroll code
|
v
Payroll system accepts
|
v
Two weeks later
|
v
Audit rejects transaction
Le signal utile arrive bien après la fin de l’exécution de LangGraph, ce qui signifie que chaque décision importante nécessite une filiation causale. Transmettez le run_id aux systèmes ultérieurs afin que les résultats ultérieurs puissent être rattachés à la décision qui les a engendrés. Sinon, le système d’apprentissage comprend que quelque chose a échoué mais ne peut pas déterminer quelle décision de l’agent mérite le crédit ou la responsabilité. C’est le classique problème d’attribution des crédits.
La mémoire nécessite une gouvernance
Lorsque les agents apprennent au fil des exécutions, la mémoire devient à la fois puissante et dangereuse. Trois catégories méritent d’être distinguées.
- La mémoire de profil stocke les préférences d’un utilisateur ou d’une entité, comme par exemple la préférence pour des explications concises.
- La mémoire épisodique enregistre des événements survenus, par exemple que l’exécution 182 a échoué parce que la politique d’état n’a pas pu être récupérée.
La mémoire procédurale modifie le comportement le plus souvent, ce qui justifie une gouvernance stricte. Une seule exécution échouée ne doit en aucun cas créer de règle procédurale en production. Le chemin devrait ressembler à ceci :
Observation
↓
Candidate lesson
↓
Supporting evidence
+
Counterexamples
↓
Validation
↓
Active lesson
Une leçon est mieux modélisée comme une hypothèse associée à des preuves, à un cadre d’application, à une confiance et à un cycle de vie, et non comme du texte simplement stocké dans une mémoire vectorielle.
La mémoire acquise ne peut pas surpasser les connaissances autoritaires
Les agents récupèrent deux types d’informations. Les connaissances autoritaires désignent les politiques, les réglementations, les configurations, les données de référence ainsi que les règles commerciales contractuelles. Les connaissances acquises englobent les préférences, les expériences, les stratégies antérieures, les observations et les leçons tirées. Elles doivent rester logiquement séparées, avec une hiérarchie cohérente :
Authoritative policy
>
Tenant configuration
>
Approved procedural lesson
>
Episodic example
>
User preference
>
Unverified claim
>
LLM reflection
Sinon, une leçon mémorisée avec assurance peut éclipser silencieusement la politique réelle.
Les leçons deviennent obsolètes
Ce qui était utile il y a six mois peut être erroné aujourd’hui. Les politiques, les produits, les API, le comportement des utilisateurs et les modèles évoluent constamment. Les leçons actives nécessitent une gestion tout au long de leur cycle de vie.
candidate
↓
validated
↓
active
↓
pending revalidation
↓
deprecated
↓
retired
Attribuez à chaque leçon une date de validation, ainsi que, le cas échéant, une date d’expiration ou une politique de révalidation. Un changement de politique peut alors déclencher une réévaluation de toutes les leçons basées sur cette politique, de sorte que la mémoire se transforme en connaissances gérées et non en un ensemble d’informations qui ne cesse de croître.
3. Le plan d’apprentissage hors ligne
La couche suivante agrège les données provenant de multiples exécutions en production.
Runs
+
User Feedback
+
Human Reviews
+
Downstream Outcomes
+
Evaluation Scores
|
v
Failure Classification
|
v
Failure Clustering
Disons qu’une semaine de courses révèle cette répartition :
missing state policy 178
wrong tool selected 63
bad tool argument 52
unsupported inference 41
output schema failure 11
Désormais, la plateforme peut identifier quels problèmes sont systémiques. Cela diffère de demander à un seul agent ayant échoué de réfléchir à une seule tentative infructueuse. Le système d’apprentissage permet de détecter des schémas.
Tout échec n’est pas un problème lié aux instructions
L’ingénierie des instructions n’est pas toujours la solution. Si un agent oublie constamment de récupérer une politique fiable avant de faire une recommandation, ajouter une ligne dans les instructions système lui demandant de s’en souvenir pourrait aider. Une solution plus efficace pourrait être une règle structurelle :
Graph rule:
Policy retrieval must occur before this decision.
D’autres pannes récurrentes pourraient nécessiter des modifications dans ces domaines :
retrieval
tool schema
validator rule
routing
memory policy
clarification logic
action guard
model configuration
Un moteur d’amélioration mature propose plusieurs corrections possibles sans réécrire automatiquement la demande.
L’évaluation occupe une place centrale
Si un système peut générer des améliorations mais ne peut pas juger si elles sont meilleures, il n’y a pas de boucle d’apprentissage, seulement une boucle de mutation. L’évaluation est l’élément fondamental de cette architecture.
Correctness
Groundedness
Retrieval relevance
Completeness
Tool selection
Tool arguments
Trajectory efficiency
Repair effectiveness
Safety
Latency
Cost
Business outcome
L’évaluation doit couvrir la réponse finale ainsi que le chemin suivi pour y parvenir. Deux agents peuvent produire la même réponse. L’agent A procède de la manière suivante :
Agent A
search -> answer
pendant que l’Agent B fait cela :
Agent B
search
-> wrong tool
-> retry
-> timeout
-> second search
-> repair
-> answer
Si l’on se base uniquement sur la réponse finale, elles sont équivalentes. Cependant, une évaluation de la trajectoire montre clairement le contraire.
Un seul juge basé sur un LLM n’est pas suffisant
Il est utile de faire rédiger une réponse par Gemini puis de la faire évaluer par un autre modèle Gemini, mais cela comporte un risque d’erreur corrélée, car l’évaluateur peut partager les lacunes du générateur. Une couche d’évaluation plus solide combine plusieurs sources.
Deterministic checks
+
Business outcomes
+
Human labels
+
Multiple evaluator rubrics
+
LLM judges
Les évaluateurs de LLM devraient également être comparés de temps en temps avec des exemples étiquetés par des humains. Cela permet de déterminer dans quelle mesure on peut faire confiance à l’évaluateur avant que ses scores n’influencent les leçons qui seront mises en avant.
L’observabilité fait partie de l’apprentissage
Le suivi traditionnel se demande simplement si le service est opérationnel. L’observabilité des agents doit également permettre de comprendre pourquoi l’agent a pris une décision donnée. Une bonne configuration de production enregistre un suivi complet de l’exécution de LangGraph.
Agent Run
|
+-- Retrieve Context
|
+-- Planner
|
+-- Tool Call
|
+-- Tool Result Validator
|
+-- Repair
|
+-- Critic
|
+-- Final Answer
Chaque exécution doit également posséder une identité stable qui relie plusieurs enregistrements.
LangGraph execution
MongoDB events
Vertex AI calls
Evaluation results
Human feedback
Downstream outcomes
Cette corrélation constitue la matière première du cycle. L’observabilité cesse d’être un simple outil de débogage pour devenir une partie intégrante du système d’apprentissage.
Pourquoi les événements d’écriture uniquement aident-ils
Il est tentant de stocker toute la trajectoire d’exécution dans un seul document de run de MongoDB. Cela fonctionne au début, mais devient problématique à grande échelle. Préférez plutôt conserver un format compact pour les runs.
run_id
agent
release
outcome
latency
tool count
repair count
cost
Ensuite, enregistrez l’exécution sous forme d’événements uniquement en appendice.
run.started
retrieval.completed
tool.called
validation.failed
repair.started
human_review.requested
run.completed
Cela préserve l’ordre causal, évite l’augmentation excessive des documents, simplifie le suivi distribué et rend l’analyse des pannes plus précise.
La reproductibilité nécessite plus qu’une simple version de prompt
Le comportement d’un agent dépend de bien plus que de son prompt système.
model
generation settings
graph version
tool definitions
validator rules
critic rubric
retrieval configuration
memory rules
security rules
Chaque série de production devrait donc relier une version de l’agent immuable. Conceptuellement :
agent_release_43
|
+-- graph v12
+-- prompt v43
+-- Gemini configuration
+-- tools v17
+-- validator v11
+-- retrieval config v9
+-- memory policy v5
+-- evaluation suite v8
Une exécution échouée peut alors être reproduite plus tard. Sans cela, le débogage se réduit à se demander quelle version a produit une réponse, avant de plonger dans le silence.
Le plan de contrôle : les améliorations ouvrent l’accès à la production
Finalement, le système d’apprentissage repère une panne récurrente et propose une amélioration. La pire réaction consiste à la déployer immédiatement. Préférez plutôt la soumettre à des étapes de validation :
Candidate Improvement
|
v
Historical Replay
|
v
Regression Evaluation
|
v
Shadow Production
|
v
Canary
|
v
Progressive Rollout
|
v
Production
À chaque étape, comparez le candidat avec la version actuelle. Cela peut améliorer la précision tout en augmentant la latence, réduire les hallucinations tout en augmentant le recours à l’intervention humaine, ou aider un type de tâche tout en nuissant à un autre. La promotion nécessite donc plusieurs mécanismes de contrôle.
Les leçons ont également besoin de canaris
La mémoire à long terme a une conséquence intéressante : lorsque une nouvelle leçon procédurale est activée et intégrée dans le contexte des agents futurs, leur comportement change, de sorte que l’intégration d’une leçon revient en fait à modifier un prompt. L’activation doit être considérée comme une expérience, et non immédiatement appliquée à toutes les exécutions éligibles.
Historical replay
↓
5% canary
↓
Measure outcome
↓
25%
↓
Measure
↓
100%
Si la leçon détériore les performances, revenez en arrière. La mémoire cesse alors d’être un mécanisme adaptatif mystérieux pour devenir une version logicielle mesurable.
L’architecture finale
En résumé, la plateforme d’agent adaptatif ressemble à peu près à ceci :
USER
|
v
+------------------------------------------------------+
| RUNTIME |
| |
| clarify -> retrieve -> plan -> action guard |
| | |
| v |
| tool |
| | |
| sanitize |
| | |
| validate |
| | |
| reason |
| | |
| answer validate |
| | |
| critic if needed |
| | |
| policy router |
| / | \ |
| repair human pass |
+--------------------------+---------------------------+
|
agent events
|
v
+------------------------------------------------------+
| LEARNING |
| |
| traces + feedback + outcomes |
| | |
| v |
| evaluate |
| | |
| classify failures |
| | |
| cluster |
| / \ |
| lessons improvement candidates |
+--------+----------------------+----------------------+
| |
v v
+------------------------------------------------------+
| CONTROL |
| |
| validate -> replay -> shadow -> canary -> rollout |
| | |
| monitor |
| | |
| rollback |
+------------------------------------------------------+
Les limites de responsabilité sont délibérément bien définies. L’agent en temps de exécution corrige le déroulement des opérations. Le système d’apprentissage génère des hypothèses. Le plan de contrôle décide quel comportement sera considéré comme fiable.
Réfléchir à la notion d’« auto-amélioration »
Lorsqu’on entend parler d’« agent auto-améliorant », beaucoup imaginent une intelligence artificielle qui réécrit ses propres instructions ou se met à jour après chaque conversation. Pour les systèmes en production, c’est un modèle mental erroné. Un modèle plus approprié est un cycle :
Observe
↓
Measure
↓
Diagnose
↓
Propose
↓
Test
↓
Promote
↓
Monitor
L’intelligence ici n’est pas limitée au LLM. Différentes parties du système la possèdent :
- Le graphe LangGraph détermine l’ordre d’exécution.
- Les validateurs de code classique appliquent des règles déjà connues.
- Le LLM gère tout ce qui est ambigu.
- MongoDB conserve l’état et l’expérience accumulée.
- Le suivi collecte les preuves.
- Les évaluateurs notent la qualité.
- Les humains prennent la décision lorsque le risque est élevé et que la réponse est floue.
- Le plan de contrôle régule tout changement de comportement.
Cette distribution transforme un agent en un système d’agents adaptatifs.
Un ordre de construction judicieux
Nul n’a besoin de construire l’ensemble du cycle d’un seul coup. Une séquence fonctionnelle commence par une exécution fiable et par un suivi à chaque exécution. En plus de cela, on intègre des mécanismes de protection, une validation des résultats et des réponses, des corrections ciblées ainsi qu’une révision humaine. Viennent ensuite les mesures de qualité : les traces, l’évaluation et la classification des pannes, ainsi qu’un ensemble de données de régression utile. L’apprentissage par l’expérience n’intervient que lorsque la qualité peut être mesurée avec confiance, ce qui permet d’introduire des candidats à des leçons, une mémoire ciblée, une agrégation des preuves, des contrôles de péremption et un retour d’information différé. L’amélioration contrôlée constitue enfin l’étape finale, avec le regroupement des pannes, la génération de candidats, l’évaluation par rejouement, du trafic de test et un déploiement progressif.
L’ordre est important :
Reliability
↓
Observability
↓
Evaluation
↓
Learning
↓
Controlled adaptation
Passer directement au « apprentissage autonome » avant même d’avoir effectué une évaluation conduit généralement à un système qui évolue plus rapidement que les ingénieurs ne peuvent le suivre.
Le but
Nul ne devrait viser un agent capable de se modifier lui-même. Un objectif plus réaliste est une plateforme capable de démontrer quand un agent doit changer. Se souvenir des conversations précédentes ne suffit pas pour que ce cycle mérite la confiance ; il nécessite une chaîne disciplinée entre ces différentes étapes :
production behavior
↓
evidence
↓
evaluation
↓
learning
↓
experimentation
↓
controlled production change
Cette chaîne constitue le fondement d’un système d’agents adaptatifs basé sur des preuves, et c’est l’architecture dont a besoin l’IA agente pour passer des démonstrations impressionnantes à des logiciels de production fiables.