[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:fr":3,"public-menus:all":38,"post:ai-agent-reliability-why-the-final-answer-is-not-enough:fr":205,"related:post:ai-agent-reliability-why-the-final-answer-is-not-enough:fr:1":1126},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","fr","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":1125},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":561,"featuredImage":562,"featuredImageAlt":563,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":564,"publishedAt":565,"createdAt":566,"updatedAt":567,"seoLocalePaths":568,"categories":577,"author":586,"translations":591},"460","Fiabilité des agents IA : pourquoi la réponse finale ne suffit pas","ai-agent-reliability-why-the-final-answer-is-not-enough","\u003Cp>\u003Cb>Une sortie correcte ne prouve pas un raisonnement correct, une exécution sûre ou un système digne de confiance.\u003C\u002Fb>\u003C\u002Fp>\n\u003Cp>Depuis des années, l'évaluation de l'IA est dominée par une question d'une simplicité trompeuse : \u003Cb>La réponse était-elle correcte ?\u003C\u002Fb> Pour un chatbot, cela peut parfois suffire. Pour un agent capable de rechercher dans des systèmes, de lire des données, d'appeler des outils, de modifier des états, d'exécuter des flux de travail, d'écrire des fichiers, d'interagir avec des API ou de prendre des décisions, ce n'est pas le cas.\u003C\u002Fp>\n\u003Cp>Un agent peut produire la bonne réponse finale tout en faisant plusieurs choses de travers en cours de route. Il peut utiliser la mauvaise source, mal comprendre une instruction et compenser ensuite l'erreur, accéder à des informations inutiles, exécuter une action intermédiaire non autorisée, se remettre silencieusement d'une erreur qui aurait dû déclencher une escalade, ou laisser derrière lui des effets secondaires que personne n'a remarqués.\u003C\u002Fp>\n\u003Cp>Cela crée l'un des problèmes centraux de l'IA agentique : \u003Cb>un résultat correct ne prouve pas une trajectoire correcte.\u003C\u002Fb>\u003C\u002Fp>\n\u003Ch2>L'illusion du résultat\u003C\u002Fh2>\n\u003Cp>Les logiciels traditionnels nous donnent un modèle intuitif de la correction. Une entrée entre dans un système déterministe ou principalement déterministe, la logique est exécutée, une sortie est produite, et des tests vérifient le comportement attendu. Les systèmes basés sur les LLM affaiblissent cette hypothèse. Les systèmes agentiques vont plus loin.\u003C\u002Fp>\n\u003Cul>\u003Cli>interprétation du modèle\u003C\u002Fli>\u003Cli>contexte récupéré\u003C\u002Fli>\u003Cli>sélection d'outils\u003C\u002Fli>\u003Cli>observations intermédiaires\u003C\u002Fli>\u003Cli>état externe\u003C\u002Fli>\u003Cli>actions précédentes\u003C\u002Fli>\u003Cli>plans générés par le modèle\u003C\u002Fli>\u003Cli>limites de permission\u003C\u002Fli>\u003Cli>nouvelles tentatives et comportement de secours\u003C\u002Fli>\u003Cli>interaction humaine\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Deux exécutions partant d'entrées presque identiques peuvent atteindre le même résultat par des chemins très différents. Si l'évaluation n'observe que la sortie finale, la majeure partie du système reste invisible.\u003C\u002Fp>\n\u003Cp>Imaginez qu'un agent IA reçoive l'instruction : \u003Ci>Mettre à jour l'adresse de facturation du client.\u003C\u002Fi> L'adresse est finalement mise à jour correctement. Une évaluation conventionnelle pourrait classer la tâche comme réussie.\u003C\u002Fp>\n\u003Col>\u003Cli>L'agent recherche plusieurs dossiers clients sans rapport.\u003C\u002Fli>\u003Cli>Il récupère plus d'informations personnelles que nécessaire.\u003C\u002Fli>\u003Cli>Il modifie d'abord le mauvais compte.\u003C\u002Fli>\u003Cli>Il remarque l'erreur.\u003C\u002Fli>\u003Cli>Il annule la modification.\u003C\u002Fli>\u003Cli>Il met à jour le bon compte.\u003C\u002Fli>\u003Cli>Il signale le succès.\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>\u003Cb>État final : correct. Comportement du système : inacceptable.\u003C\u002Fb> Un benchmark basé uniquement sur le résultat donne une réussite à cette exécution. Un système d'assurance en production ne devrait pas.\u003C\u002Fp>\n\u003Ch2>La trajectoire fait partie du produit\u003C\u002Fh2>\n\u003Cp>C'est pourquoi la \u003Cb>trajectoire\u003C\u002Fb> d'un agent IA doit devenir un objet d'ingénierie de première classe. Une trajectoire est la séquence d'états et d'actions pertinents entre la demande initiale et le résultat final.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Intention → Contexte → Décision → Outil → Action → Observation → Décision → Changement d'état → Résultat\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Zachary J. Stevens développe cette idée dans \u003Ci>La trajectoire est le système\u003C\u002Fi>, soutenant que l'évaluation agentique doit aller au-delà de la réponse finale et examiner le chemin complet de l'action à travers un environnement changeant.\u003C\u002Fp>\n\u003Cblockquote class=\"border-l-4 border-gray-300 pl-4 italic\">Un résultat correct n'excuse pas une trajectoire inacceptable.\u003Ccite class=\"block mt-2 text-sm\">— Zachary J. Stevens, La trajectoire est le système\u003C\u002Fcite>\u003C\u002Fblockquote>\n\u003Ca href=\"https:\u002F\u002Fzacharyjstevens.com\u002Fdispatches\u002Fvanguard-signal\u002F009-the-trajectory-is-the-system\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">La trajectoire est le système\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Zachary J. Stevens — DFEI.009 sur l'évaluation des systèmes agentiques par leur trajectoire complète plutôt que par le seul résultat final.\u003C\u002Fp>\u003C\u002Fa>\n\u003Cp>La distinction est extrêmement importante. La fiabilité n'est donc pas simplement \u003Cb>une sortie correcte\u003C\u002Fb>. Elle est plus proche de \u003Cb>résultat acceptable + trajectoire acceptable + récupérabilité + preuves\u003C\u002Fb>.\u003C\u002Fp>\n\u003Ch2>Une bonne réponse peut cacher un système défaillant\u003C\u002Fh2>\n\u003Ctable class=\"w-full border-collapse\">\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Agent\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Résultat final\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Exécution\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">A\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Correct\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Chemin correct\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">B\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Correct\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Chemin non sûr\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">C\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Incorrect\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Échec sûr\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">D\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Incorrect\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Échec non sûr\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftable>\n\u003Cp>La plupart des évaluations basées sur des benchmarks récompensent fortement A et B et pénalisent C et D. Sur le plan opérationnel, cependant, \u003Cb>B peut être plus dangereux que C\u003C\u002Fb>. L'agent C peut reconnaître l'incertitude, arrêter l'exécution et demander une revue humaine. L'agent B peut produire avec confiance des résultats corrects tout en violant des hypothèses que personne ne surveille.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>sortie réussie → confiance accrue → permissions élargies → plus d'automatisation → plus grande portée des dégâts\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Nous avons besoin de preuves, pas de confiance\u003C\u002Fh2>\n\u003Cp>L'une des plus grandes erreurs dans l'adoption de l'IA est de considérer la confiance du modèle, la satisfaction de l'utilisateur ou le taux de réussite historique comme une preuve de fiabilité du système. Ils ne sont pas équivalents.\u003C\u002Fp>\n\u003Cul>\u003Cli>Qu'est-ce que l'agent a reçu ?\u003C\u002Fli>\u003Cli>Quel contexte a-t-il récupéré ?\u003C\u002Fli>\u003Cli>Quels outils a-t-il appelés ?\u003C\u002Fli>\u003Cli>Pourquoi l'action a-t-elle été autorisée ?\u003C\u002Fli>\u003Cli>Quel état existait avant l'action ?\u003C\u002Fli>\u003Cli>Qu'est-ce qui a changé ?\u003C\u002Fli>\u003Cli>Quelles défaillances intermédiaires se sont produites ?\u003C\u002Fli>\u003Cli>Y a-t-il eu des tentatives ?\u003C\u002Fli>\u003Cli>L'approbation humaine était-elle requise ?\u003C\u002Fli>\u003Cli>L'exécution aurait-elle pu être arrêtée ?\u003C\u002Fli>\u003Cli>L'action peut-elle être annulée ?\u003C\u002Fli>\u003Cli>Quels modèles, invites et versions d'outils ont été impliqués ?\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Sans ces réponses, il n'y a aucune assurance opérationnelle sérieuse. Il n'y a qu'une sortie. L'observabilité et les preuves doivent donc être conçues dans l'architecture de l'agent plutôt que d'être ajoutées après le déploiement.\u003C\u002Fp>\n\u003Ch2>La journalisation n'est pas la même chose que le contrôle\u003C\u002Fh2>\n\u003Cp>Les organisations répondent souvent : \u003Ci>Tout est journalisé.\u003C\u002Fi> Bien. Mais la journalisation seule ne contrôle rien. Un journal vous dit ce qui s'est passé. Un contrôle détermine si quelque chose \u003Cb>peut se produire\u003C\u002Fb>.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>L'agent demande DELETE \u002Fcustomer\u002F123 ↓\nAction journalisée ↓\nDELETE exécuté\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Cela donne de l'observabilité. Comparez avec :\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>L'agent demande DELETE \u002Fcustomer\u002F123 ↓\nÉvaluation de la politique ↓\nIdentité actuelle vérifiée ↓\nParamètres de l'action actuelle vérifiés ↓\nSeuil de risque évalué ↓\nApprobation humaine si nécessaire ↓\nAction exécutée ↓\nRésultat vérifié ↓\nPreuves stockées\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Maintenant, nous approchons d'un système de contrôle. La différence est architecturale, pas cosmétique.\u003C\u002Fp>\n\u003Ch2>La permission est nécessaire — mais ce n'est pas une assurance\u003C\u002Fh2>\n\u003Cp>Supposons qu'un agent ait la permission d'envoyer des e-mails. Le contrôle d'accès répond : \u003Cb>Cet agent peut-il envoyer des e-mails ?\u003C\u002Fb> Il ne répond pas : \u003Cb>Cet e-mail particulier doit-il être envoyé à cette personne particulière avec cette pièce jointe particulière maintenant ?\u003C\u002Fb>\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>CONTRÔLE DE CAPACITÉ\nQu'est-ce que l'agent est techniquement autorisé à faire ? + ASSURANCE D'ACTION\nCette action spécifique est-elle appropriée dans l'état actuel ?\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Le RBAC, les portées OAuth, les permissions API et les identités d'agent définissent l'espace des actions possibles. Ils ne prouvent pas qu'une action dans cet espace est appropriée. Une architecture d'agent solide nécessite les deux couches.\u003C\u002Fp>\n\u003Ch2>Le premier faux pas compte\u003C\u002Fh2>\n\u003Cp>Lorsqu'un agent échoue, l'action incorrecte finale n'est souvent pas là où l'échec a commencé. Le véritable échec a peut-être eu lieu bien plus tôt.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Mauvaise récupération ↓\nMauvaise hypothèse ↓\nRaisonnement plausible ↓\nAppel d'outil valide ↓\nMauvaise action\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Si nous n'examinons que l'action finale, nous corrigeons le symptôme. Si nous inspectons la trajectoire, nous pouvons identifier le \u003Cb>premier faux pas\u003C\u002Fb>. Cela transforme un échec non attribuable en un problème d'ingénierie concret.\u003C\u002Fp>\n\u003Ch2>Les tests d'agents doivent aller au-delà des tests de prompts\u003C\u002Fh2>\n\u003Cp>Les prompts comptent, mais le comportement d'un agent en production émerge d'un système entier.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>MODÈLE\n+\nPROMPT SYSTÈME\n+\nCONTEXTE\n+\nMÉMOIRE\n+\nRÉCUPÉRATION\n+\nOUTILS\n+\nPERMISSIONS\n+\nWORKFLOW\n+\nÉTAT EXTERNE\n+\nLOGIQUE DE CONTRÔLE\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Modifier l'un de ces éléments peut changer la trajectoire. Par conséquent, versionner uniquement le prompt est insuffisant.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>version_modèle\nversion_prompt\nversion_outils\nversion_politique\nversion_récupération\nversion_workflow\nétat_environnement\nid_exécution\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Les critères d'acceptation pour les agents doivent inclure le comportement\u003C\u002Fh2>\n\u003Cp>Les critères d'acceptation traditionnels ressemblent souvent à ceci : \u003Ci>Étant donné X, le système produit Y.\u003C\u002Fi> Pour les systèmes agentiques, cela est incomplet. Les critères d'acceptation devraient également définir des contraintes sur la trajectoire.\u003C\u002Fp>\n\u003Ch3>Résultat\u003C\u002Fh3>\n\u003Cp>L'adresse du client est mise à jour correctement.\u003C\u002Fp>\n\u003Ch3>Autorisation\u003C\u002Fh3>\n\u003Cp>L'agent modifie uniquement le client explicitement sélectionné.\u003C\u002Fp>\n\u003Ch3>Accès aux données\u003C\u002Fh3>\n\u003Cp>Aucun enregistrement client non lié n'est consulté.\u003C\u002Fp>\n\u003Ch3>Outils\u003C\u002Fh3>\n\u003Cp>Seules les opérations CRM approuvées sont utilisées.\u003C\u002Fp>\n\u003Ch3>Vérification\u003C\u002Fh3>\n\u003Cp>La nouvelle adresse est relue et comparée à la valeur demandée.\u003C\u002Fp>\n\u003Ch3>Échec\u003C\u002Fh3>\n\u003Cp>Une résolution d'identité ambiguë arrête l'exécution.\u003C\u002Fp>\n\u003Ch3>Autorité humaine\u003C\u002Fh3>\n\u003Cp>Un humain peut rejeter la modification avant l'exécution lorsque les seuils de risque exigent une approbation.\u003C\u002Fp>\n\u003Ch3>Preuve\u003C\u002Fh3>\n\u003Cp>L'exécution laisse une trace suffisante pour reconstituer la décision et la transition d'état.\u003C\u002Fp>\n\u003Ch3>Récupération\u003C\u002Fh3>\n\u003Cp>La valeur précédente reste récupérable.\u003C\u002Fp>\n\u003Ch2>L'humain dans la boucle ne suffit pas\u003C\u002Fh2>\n\u003Cp>Ajouter une case d'approbation humaine ne résout pas automatiquement le problème. Un humain ne peut contrôler un agent que s'il dispose de la visibilité, de l'autorité, du temps, du contexte et de la capacité de récupération.\u003C\u002Fp>\n\u003Cul>\u003Cli>\u003Cb>Visibilité :\u003C\u002Fb> suffisamment d'informations pour comprendre ce qui se passe.\u003C\u002Fli>\u003Cli>\u003Cb>Autorité :\u003C\u002Fb> capacité réelle d'arrêter ou de modifier l'action.\u003C\u002Fli>\u003Cli>\u003Cb>Temps :\u003C\u002Fb> intervention avant que la conséquence ne se produise.\u003C\u002Fli>\u003Cli>\u003Cb>Contexte :\u003C\u002Fb> preuves suffisantes pour prendre la décision.\u003C\u002Fli>\u003Cli>\u003Cb>Capacité de récupération :\u003C\u002Fb> capacité d'inverser ou de réparer l'action.\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Un utilisateur qui clique sur \u003Cb>Approuver\u003C\u002Fb> pour quelque chose qu'il ne peut pas inspecter de manière significative n'est pas une gouvernance solide. C'est du théâtre d'approbation.\u003C\u002Fp>\n\u003Ch2>Le rollback doit devenir une capacité native de l'IA\u003C\u002Fh2>\n\u003Cp>Le déploiement logiciel traditionnel nous a appris quelque chose de précieux : \u003Cb>Ne déployez jamais ce que vous ne pouvez pas annuler.\u003C\u002Fb> Nous devrions appliquer le même principe aux actions agentiques.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>RÉVERSIBLE\nPeut être automatiquement annulé. COMPENSABLE\nNe peut pas être annulé directement mais peut exécuter une action compensatoire. IRRÉVERSIBLE\nNe peut pas restaurer de manière fiable l'état précédent.\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Plus l'irréversibilité est élevée, plus l'exigence de contrôle doit être forte.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Lire un document public → conséquence faible\nCréer un brouillon → réversible\nModifier un enregistrement CRM → réversible mais conséquent\nEnvoyer un e-mail externe → pratiquement irréversible\nTransférer de l'argent → conséquence élevée\nSupprimer des données de production → potentiellement catastrophique\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>L'agent a besoin d'un plan de contrôle\u003C\u002Fh2>\n\u003Cpre class=\"code-block\">\u003Ccode>INTENTION UTILISATEUR \u002F SYSTÈME │ ▼ AGENT IA │ action proposée │ ▼ ┌───────────────────┐ │ PLAN DE CONTRÔLE │ ├───────────────────┤ │ Identité │ │ Autorisation │ │ Politique │ │ Risque │ │ État │ │ Preuve │ │ Autorité humaine │ │ Annulation │ └───────────────────┘ │ approuvé ? \u002F \\ NON OUI │ │ STOP ▼ OUTIL │ ▼ CHANGEMENT D'ÉTAT │ ▼ VÉRIFICATION\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cb>Le LLM devrait proposer. Le plan de contrôle devrait gouverner.\u003C\u002Fb> Cette séparation est cruciale. Le modèle ne devrait pas être l'autorité ultime déterminant si sa propre action proposée à fort impact est sûre.\u003C\u002Fp>\n\u003Ch2>Des benchmarks à la confiance opérationnelle\u003C\u002Fh2>\n\u003Cp>Les benchmarks restent utiles. Ils nous renseignent sur les capacités, comparent les modèles, détectent les régressions et aident à estimer les performances attendues. Mais l'évaluation des capacités et la confiance opérationnelle répondent à des questions différentes.\u003C\u002Fp>\n\u003Cp>Un benchmark demande : \u003Cb>Le système peut-il faire cela ?\u003C\u002Fb> L'assurance opérationnelle demande : \u003Cb>Pouvons-nous permettre au système de faire cela ici, dans ces conditions, avec ces permissions et ces conséquences ?\u003C\u002Fb>\u003C\u002Fp>\n\u003Ch2>La fiabilité devrait être mesurée comme une propriété système\u003C\u002Fh2>\n\u003Col>\u003Cli>\u003Cb>Exactitude du résultat :\u003C\u002Fb> Le système a-t-il produit le résultat attendu ?\u003C\u002Fli>\u003Cli>\u003Cb>Exactitude de la trajectoire :\u003C\u002Fb> A-t-il suivi un chemin acceptable ?\u003C\u002Fli>\u003Cli>\u003Cb>Intégrité du contrôle :\u003C\u002Fb> Les limites d'autorisation, de politique et d'intervention ont-elles été respectées ?\u003C\u002Fli>\u003Cli>\u003Cb>Récupérabilité :\u003C\u002Fb> Les défaillances peuvent-elles être contenues, inversées ou réparées ?\u003C\u002Fli>\u003Cli>\u003Cb>Complétude des preuves :\u003C\u002Fb> L'exécution peut-elle être reconstruite et auditée ?\u003C\u002Fli>\u003C\u002Fol>\n\u003Cpre class=\"code-block\">\u003Ccode>Fiabilité opérationnelle\n=\nRésultat × Trajectoire × Contrôle × Récupérabilité × Preuves\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>La multiplication est intentionnelle. Si une dimension critique approche de zéro, un score élevé ailleurs ne devrait pas le cacher. Un résultat parfaitement correct avec une intégrité d'autorisation nulle n'est pas un système fiable à 80 %. C'est une exécution inacceptable qui a produit la bonne réponse par hasard.\u003C\u002Fp>\n\u003Ch2>Le succès est parfois l'échec le plus dangereux\u003C\u002Fh2>\n\u003Cp>Les échecs attirent l'attention. Le succès souvent non. Cela rend les trajectoires d'agents réussies mais non contrôlées particulièrement dangereuses. Un échec évident crée un incident. Un défaut de trajectoire caché crée de la \u003Cb>confiance\u003C\u002Fb>. Et la confiance élargit l'autonomie.\u003C\u002Fp>\n\u003Cp>Les organisations ne devraient donc pas seulement enquêter sur \u003Ci>Pourquoi l'agent a-t-il échoué ?\u003C\u002Fi> Elles devraient périodiquement se demander : \u003Cb>Pourquoi l'agent a-t-il réussi ?\u003C\u002Fb> A-t-il réussi parce que l'architecture a de manière fiable contraint et vérifié l'exécution, ou parce que rien n'a mal tourné cette fois-ci ?\u003C\u002Fp>\n\u003Ch2>Conclusion\u003C\u002Fh2>\n\u003Cp>L'industrie évolue rapidement de l'IA qui \u003Cb>répond\u003C\u002Fb> vers l'IA qui \u003Cb>agit\u003C\u002Fb>. Cette transition change ce que signifie la fiabilité. Pour un système de réponse, évaluer la réponse peut souvent suffire. Pour un système d'action, nous devons évaluer le chemin.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Invite\n↓\nLa réponse devient intention\n↓\nTrajectoire\n↓\nActions\n↓\nChangements d'état\n↓\nPreuves\n↓\nRésultat\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>La réponse finale reste importante, mais elle n'est que la partie visible d'un système bien plus vaste. Une fois que l'IA est autorisée à affecter le monde réel, \u003Cb>le chemin vers la réponse fait partie de la réponse.\u003C\u002Fb>\u003C\u002Fp>",{"time":212,"blocks":213,"version":560},1788955766559,[214,218,221,224,227,231,234,249,252,255,266,269,272,275,279,282,288,296,299,302,324,327,330,333,336,351,354,357,360,363,366,369,372,375,378,381,384,387,390,393,396,399,402,405,408,411,414,417,421,424,427,430,433,436,439,442,445,448,451,454,457,460,463,466,469,472,475,478,486,489,492,495,498,501,504,507,510,513,516,519,522,525,533,536,539,542,545,548,551,554,557],{"data":215,"type":217},{"text":216},"\u003Cb>Une sortie correcte ne prouve pas un raisonnement correct, une exécution sûre ou un système digne de confiance.\u003C\u002Fb>","paragraph",{"data":219,"type":217},{"text":220},"Depuis des années, l'évaluation de l'IA est dominée par une question d'une simplicité trompeuse : \u003Cb>La réponse était-elle correcte ?\u003C\u002Fb> Pour un chatbot, cela peut parfois suffire. Pour un agent capable de rechercher dans des systèmes, de lire des données, d'appeler des outils, de modifier des états, d'exécuter des flux de travail, d'écrire des fichiers, d'interagir avec des API ou de prendre des décisions, ce n'est pas le cas.",{"data":222,"type":217},{"text":223},"Un agent peut produire la bonne réponse finale tout en faisant plusieurs choses de travers en cours de route. Il peut utiliser la mauvaise source, mal comprendre une instruction et compenser ensuite l'erreur, accéder à des informations inutiles, exécuter une action intermédiaire non autorisée, se remettre silencieusement d'une erreur qui aurait dû déclencher une escalade, ou laisser derrière lui des effets secondaires que personne n'a remarqués.",{"data":225,"type":217},{"text":226},"Cela crée l'un des problèmes centraux de l'IA agentique : \u003Cb>un résultat correct ne prouve pas une trajectoire correcte.\u003C\u002Fb>",{"data":228,"type":42},{"text":229,"level":230},"L'illusion du résultat",2,{"data":232,"type":217},{"text":233},"Les logiciels traditionnels nous donnent un modèle intuitif de la correction. Une entrée entre dans un système déterministe ou principalement déterministe, la logique est exécutée, une sortie est produite, et des tests vérifient le comportement attendu. Les systèmes basés sur les LLM affaiblissent cette hypothèse. Les systèmes agentiques vont plus loin.",{"data":235,"type":248},{"items":236,"style":247},[237,238,239,240,241,242,243,244,245,246],"interprétation du modèle","contexte récupéré","sélection d'outils","observations intermédiaires","état externe","actions précédentes","plans générés par le modèle","limites de permission","nouvelles tentatives et comportement de secours","interaction humaine","unordered","list",{"data":250,"type":217},{"text":251},"Deux exécutions partant d'entrées presque identiques peuvent atteindre le même résultat par des chemins très différents. Si l'évaluation n'observe que la sortie finale, la majeure partie du système reste invisible.",{"data":253,"type":217},{"text":254},"Imaginez qu'un agent IA reçoive l'instruction : \u003Ci>Mettre à jour l'adresse de facturation du client.\u003C\u002Fi> L'adresse est finalement mise à jour correctement. Une évaluation conventionnelle pourrait classer la tâche comme réussie.",{"data":256,"type":248},{"items":257,"style":265},[258,259,260,261,262,263,264],"L'agent recherche plusieurs dossiers clients sans rapport.","Il récupère plus d'informations personnelles que nécessaire.","Il modifie d'abord le mauvais compte.","Il remarque l'erreur.","Il annule la modification.","Il met à jour le bon compte.","Il signale le succès.","ordered",{"data":267,"type":217},{"text":268},"\u003Cb>État final : correct. Comportement du système : inacceptable.\u003C\u002Fb> Un benchmark basé uniquement sur le résultat donne une réussite à cette exécution. Un système d'assurance en production ne devrait pas.",{"data":270,"type":42},{"text":271,"level":230},"La trajectoire fait partie du produit",{"data":273,"type":217},{"text":274},"C'est pourquoi la \u003Cb>trajectoire\u003C\u002Fb> d'un agent IA doit devenir un objet d'ingénierie de première classe. Une trajectoire est la séquence d'états et d'actions pertinents entre la demande initiale et le résultat final.",{"data":276,"type":278},{"code":277},"Intention → Contexte → Décision → Outil → Action → Observation → Décision → Changement d'état → Résultat","code",{"data":280,"type":217},{"text":281},"Zachary J. Stevens développe cette idée dans \u003Ci>La trajectoire est le système\u003C\u002Fi>, soutenant que l'évaluation agentique doit aller au-delà de la réponse finale et examiner le chemin complet de l'action à travers un environnement changeant.",{"data":283,"type":287},{"text":284,"caption":285,"alignment":286},"Un résultat correct n'excuse pas une trajectoire inacceptable.","Zachary J. Stevens, La trajectoire est le système","left","quote",{"data":289,"type":295},{"link":290,"meta":291},"https:\u002F\u002Fzacharyjstevens.com\u002Fdispatches\u002Fvanguard-signal\u002F009-the-trajectory-is-the-system\u002F",{"image":292,"title":293,"description":294},{},"La trajectoire est le système","Zachary J. Stevens — DFEI.009 sur l'évaluation des systèmes agentiques par leur trajectoire complète plutôt que par le seul résultat final.","linkTool",{"data":297,"type":217},{"text":298},"La distinction est extrêmement importante. La fiabilité n'est donc pas simplement \u003Cb>une sortie correcte\u003C\u002Fb>. Elle est plus proche de \u003Cb>résultat acceptable + trajectoire acceptable + récupérabilité + preuves\u003C\u002Fb>.",{"data":300,"type":42},{"text":301,"level":230},"Une bonne réponse peut cacher un système défaillant",{"data":303,"type":323},{"content":304,"withHeadings":14},[305,309,313,316,320],[306,307,308],"Agent","Résultat final","Exécution",[310,311,312],"A","Correct","Chemin correct",[314,311,315],"B","Chemin non sûr",[317,318,319],"C","Incorrect","Échec sûr",[321,318,322],"D","Échec non sûr","table",{"data":325,"type":217},{"text":326},"La plupart des évaluations basées sur des benchmarks récompensent fortement A et B et pénalisent C et D. Sur le plan opérationnel, cependant, \u003Cb>B peut être plus dangereux que C\u003C\u002Fb>. L'agent C peut reconnaître l'incertitude, arrêter l'exécution et demander une revue humaine. L'agent B peut produire avec confiance des résultats corrects tout en violant des hypothèses que personne ne surveille.",{"data":328,"type":278},{"code":329},"sortie réussie → confiance accrue → permissions élargies → plus d'automatisation → plus grande portée des dégâts",{"data":331,"type":42},{"text":332,"level":230},"Nous avons besoin de preuves, pas de confiance",{"data":334,"type":217},{"text":335},"L'une des plus grandes erreurs dans l'adoption de l'IA est de considérer la confiance du modèle, la satisfaction de l'utilisateur ou le taux de réussite historique comme une preuve de fiabilité du système. Ils ne sont pas équivalents.",{"data":337,"type":248},{"items":338,"style":247},[339,340,341,342,343,344,345,346,347,348,349,350],"Qu'est-ce que l'agent a reçu ?","Quel contexte a-t-il récupéré ?","Quels outils a-t-il appelés ?","Pourquoi l'action a-t-elle été autorisée ?","Quel état existait avant l'action ?","Qu'est-ce qui a changé ?","Quelles défaillances intermédiaires se sont produites ?","Y a-t-il eu des tentatives ?","L'approbation humaine était-elle requise ?","L'exécution aurait-elle pu être arrêtée ?","L'action peut-elle être annulée ?","Quels modèles, invites et versions d'outils ont été impliqués ?",{"data":352,"type":217},{"text":353},"Sans ces réponses, il n'y a aucune assurance opérationnelle sérieuse. Il n'y a qu'une sortie. L'observabilité et les preuves doivent donc être conçues dans l'architecture de l'agent plutôt que d'être ajoutées après le déploiement.",{"data":355,"type":42},{"text":356,"level":230},"La journalisation n'est pas la même chose que le contrôle",{"data":358,"type":217},{"text":359},"Les organisations répondent souvent : \u003Ci>Tout est journalisé.\u003C\u002Fi> Bien. Mais la journalisation seule ne contrôle rien. Un journal vous dit ce qui s'est passé. Un contrôle détermine si quelque chose \u003Cb>peut se produire\u003C\u002Fb>.",{"data":361,"type":278},{"code":362},"L'agent demande DELETE \u002Fcustomer\u002F123 ↓\nAction journalisée ↓\nDELETE exécuté",{"data":364,"type":217},{"text":365},"Cela donne de l'observabilité. Comparez avec :",{"data":367,"type":278},{"code":368},"L'agent demande DELETE \u002Fcustomer\u002F123 ↓\nÉvaluation de la politique ↓\nIdentité actuelle vérifiée ↓\nParamètres de l'action actuelle vérifiés ↓\nSeuil de risque évalué ↓\nApprobation humaine si nécessaire ↓\nAction exécutée ↓\nRésultat vérifié ↓\nPreuves stockées",{"data":370,"type":217},{"text":371},"Maintenant, nous approchons d'un système de contrôle. La différence est architecturale, pas cosmétique.",{"data":373,"type":42},{"text":374,"level":230},"La permission est nécessaire — mais ce n'est pas une assurance",{"data":376,"type":217},{"text":377},"Supposons qu'un agent ait la permission d'envoyer des e-mails. Le contrôle d'accès répond : \u003Cb>Cet agent peut-il envoyer des e-mails ?\u003C\u002Fb> Il ne répond pas : \u003Cb>Cet e-mail particulier doit-il être envoyé à cette personne particulière avec cette pièce jointe particulière maintenant ?\u003C\u002Fb>",{"data":379,"type":278},{"code":380},"CONTRÔLE DE CAPACITÉ\nQu'est-ce que l'agent est techniquement autorisé à faire ? + ASSURANCE D'ACTION\nCette action spécifique est-elle appropriée dans l'état actuel ?",{"data":382,"type":217},{"text":383},"Le RBAC, les portées OAuth, les permissions API et les identités d'agent définissent l'espace des actions possibles. Ils ne prouvent pas qu'une action dans cet espace est appropriée. Une architecture d'agent solide nécessite les deux couches.",{"data":385,"type":42},{"text":386,"level":230},"Le premier faux pas compte",{"data":388,"type":217},{"text":389},"Lorsqu'un agent échoue, l'action incorrecte finale n'est souvent pas là où l'échec a commencé. Le véritable échec a peut-être eu lieu bien plus tôt.",{"data":391,"type":278},{"code":392},"Mauvaise récupération ↓\nMauvaise hypothèse ↓\nRaisonnement plausible ↓\nAppel d'outil valide ↓\nMauvaise action",{"data":394,"type":217},{"text":395},"Si nous n'examinons que l'action finale, nous corrigeons le symptôme. Si nous inspectons la trajectoire, nous pouvons identifier le \u003Cb>premier faux pas\u003C\u002Fb>. Cela transforme un échec non attribuable en un problème d'ingénierie concret.",{"data":397,"type":42},{"text":398,"level":230},"Les tests d'agents doivent aller au-delà des tests de prompts",{"data":400,"type":217},{"text":401},"Les prompts comptent, mais le comportement d'un agent en production émerge d'un système entier.",{"data":403,"type":278},{"code":404},"MODÈLE\n+\nPROMPT SYSTÈME\n+\nCONTEXTE\n+\nMÉMOIRE\n+\nRÉCUPÉRATION\n+\nOUTILS\n+\nPERMISSIONS\n+\nWORKFLOW\n+\nÉTAT EXTERNE\n+\nLOGIQUE DE CONTRÔLE",{"data":406,"type":217},{"text":407},"Modifier l'un de ces éléments peut changer la trajectoire. Par conséquent, versionner uniquement le prompt est insuffisant.",{"data":409,"type":278},{"code":410},"version_modèle\nversion_prompt\nversion_outils\nversion_politique\nversion_récupération\nversion_workflow\nétat_environnement\nid_exécution",{"data":412,"type":42},{"text":413,"level":230},"Les critères d'acceptation pour les agents doivent inclure le comportement",{"data":415,"type":217},{"text":416},"Les critères d'acceptation traditionnels ressemblent souvent à ceci : \u003Ci>Étant donné X, le système produit Y.\u003C\u002Fi> Pour les systèmes agentiques, cela est incomplet. Les critères d'acceptation devraient également définir des contraintes sur la trajectoire.",{"data":418,"type":42},{"text":419,"level":420},"Résultat",3,{"data":422,"type":217},{"text":423},"L'adresse du client est mise à jour correctement.",{"data":425,"type":42},{"text":426,"level":420},"Autorisation",{"data":428,"type":217},{"text":429},"L'agent modifie uniquement le client explicitement sélectionné.",{"data":431,"type":42},{"text":432,"level":420},"Accès aux données",{"data":434,"type":217},{"text":435},"Aucun enregistrement client non lié n'est consulté.",{"data":437,"type":42},{"text":438,"level":420},"Outils",{"data":440,"type":217},{"text":441},"Seules les opérations CRM approuvées sont utilisées.",{"data":443,"type":42},{"text":444,"level":420},"Vérification",{"data":446,"type":217},{"text":447},"La nouvelle adresse est relue et comparée à la valeur demandée.",{"data":449,"type":42},{"text":450,"level":420},"Échec",{"data":452,"type":217},{"text":453},"Une résolution d'identité ambiguë arrête l'exécution.",{"data":455,"type":42},{"text":456,"level":420},"Autorité humaine",{"data":458,"type":217},{"text":459},"Un humain peut rejeter la modification avant l'exécution lorsque les seuils de risque exigent une approbation.",{"data":461,"type":42},{"text":462,"level":420},"Preuve",{"data":464,"type":217},{"text":465},"L'exécution laisse une trace suffisante pour reconstituer la décision et la transition d'état.",{"data":467,"type":42},{"text":468,"level":420},"Récupération",{"data":470,"type":217},{"text":471},"La valeur précédente reste récupérable.",{"data":473,"type":42},{"text":474,"level":230},"L'humain dans la boucle ne suffit pas",{"data":476,"type":217},{"text":477},"Ajouter une case d'approbation humaine ne résout pas automatiquement le problème. Un humain ne peut contrôler un agent que s'il dispose de la visibilité, de l'autorité, du temps, du contexte et de la capacité de récupération.",{"data":479,"type":248},{"items":480,"style":247},[481,482,483,484,485],"\u003Cb>Visibilité :\u003C\u002Fb> suffisamment d'informations pour comprendre ce qui se passe.","\u003Cb>Autorité :\u003C\u002Fb> capacité réelle d'arrêter ou de modifier l'action.","\u003Cb>Temps :\u003C\u002Fb> intervention avant que la conséquence ne se produise.","\u003Cb>Contexte :\u003C\u002Fb> preuves suffisantes pour prendre la décision.","\u003Cb>Capacité de récupération :\u003C\u002Fb> capacité d'inverser ou de réparer l'action.",{"data":487,"type":217},{"text":488},"Un utilisateur qui clique sur \u003Cb>Approuver\u003C\u002Fb> pour quelque chose qu'il ne peut pas inspecter de manière significative n'est pas une gouvernance solide. C'est du théâtre d'approbation.",{"data":490,"type":42},{"text":491,"level":230},"Le rollback doit devenir une capacité native de l'IA",{"data":493,"type":217},{"text":494},"Le déploiement logiciel traditionnel nous a appris quelque chose de précieux : \u003Cb>Ne déployez jamais ce que vous ne pouvez pas annuler.\u003C\u002Fb> Nous devrions appliquer le même principe aux actions agentiques.",{"data":496,"type":278},{"code":497},"RÉVERSIBLE\nPeut être automatiquement annulé. COMPENSABLE\nNe peut pas être annulé directement mais peut exécuter une action compensatoire. IRRÉVERSIBLE\nNe peut pas restaurer de manière fiable l'état précédent.",{"data":499,"type":217},{"text":500},"Plus l'irréversibilité est élevée, plus l'exigence de contrôle doit être forte.",{"data":502,"type":278},{"code":503},"Lire un document public → conséquence faible\nCréer un brouillon → réversible\nModifier un enregistrement CRM → réversible mais conséquent\nEnvoyer un e-mail externe → pratiquement irréversible\nTransférer de l'argent → conséquence élevée\nSupprimer des données de production → potentiellement catastrophique",{"data":505,"type":42},{"text":506,"level":230},"L'agent a besoin d'un plan de contrôle",{"data":508,"type":278},{"code":509},"INTENTION UTILISATEUR \u002F SYSTÈME │ ▼ AGENT IA │ action proposée │ ▼ ┌───────────────────┐ │ PLAN DE CONTRÔLE │ ├───────────────────┤ │ Identité │ │ Autorisation │ │ Politique │ │ Risque │ │ État │ │ Preuve │ │ Autorité humaine │ │ Annulation │ └───────────────────┘ │ approuvé ? \u002F \\ NON OUI │ │ STOP ▼ OUTIL │ ▼ CHANGEMENT D'ÉTAT │ ▼ VÉRIFICATION",{"data":511,"type":217},{"text":512},"\u003Cb>Le LLM devrait proposer. Le plan de contrôle devrait gouverner.\u003C\u002Fb> Cette séparation est cruciale. Le modèle ne devrait pas être l'autorité ultime déterminant si sa propre action proposée à fort impact est sûre.",{"data":514,"type":42},{"text":515,"level":230},"Des benchmarks à la confiance opérationnelle",{"data":517,"type":217},{"text":518},"Les benchmarks restent utiles. Ils nous renseignent sur les capacités, comparent les modèles, détectent les régressions et aident à estimer les performances attendues. Mais l'évaluation des capacités et la confiance opérationnelle répondent à des questions différentes.",{"data":520,"type":217},{"text":521},"Un benchmark demande : \u003Cb>Le système peut-il faire cela ?\u003C\u002Fb> L'assurance opérationnelle demande : \u003Cb>Pouvons-nous permettre au système de faire cela ici, dans ces conditions, avec ces permissions et ces conséquences ?\u003C\u002Fb>",{"data":523,"type":42},{"text":524,"level":230},"La fiabilité devrait être mesurée comme une propriété système",{"data":526,"type":248},{"items":527,"style":265},[528,529,530,531,532],"\u003Cb>Exactitude du résultat :\u003C\u002Fb> Le système a-t-il produit le résultat attendu ?","\u003Cb>Exactitude de la trajectoire :\u003C\u002Fb> A-t-il suivi un chemin acceptable ?","\u003Cb>Intégrité du contrôle :\u003C\u002Fb> Les limites d'autorisation, de politique et d'intervention ont-elles été respectées ?","\u003Cb>Récupérabilité :\u003C\u002Fb> Les défaillances peuvent-elles être contenues, inversées ou réparées ?","\u003Cb>Complétude des preuves :\u003C\u002Fb> L'exécution peut-elle être reconstruite et auditée ?",{"data":534,"type":278},{"code":535},"Fiabilité opérationnelle\n=\nRésultat × Trajectoire × Contrôle × Récupérabilité × Preuves",{"data":537,"type":217},{"text":538},"La multiplication est intentionnelle. Si une dimension critique approche de zéro, un score élevé ailleurs ne devrait pas le cacher. Un résultat parfaitement correct avec une intégrité d'autorisation nulle n'est pas un système fiable à 80 %. C'est une exécution inacceptable qui a produit la bonne réponse par hasard.",{"data":540,"type":42},{"text":541,"level":230},"Le succès est parfois l'échec le plus dangereux",{"data":543,"type":217},{"text":544},"Les échecs attirent l'attention. Le succès souvent non. Cela rend les trajectoires d'agents réussies mais non contrôlées particulièrement dangereuses. Un échec évident crée un incident. Un défaut de trajectoire caché crée de la \u003Cb>confiance\u003C\u002Fb>. Et la confiance élargit l'autonomie.",{"data":546,"type":217},{"text":547},"Les organisations ne devraient donc pas seulement enquêter sur \u003Ci>Pourquoi l'agent a-t-il échoué ?\u003C\u002Fi> Elles devraient périodiquement se demander : \u003Cb>Pourquoi l'agent a-t-il réussi ?\u003C\u002Fb> A-t-il réussi parce que l'architecture a de manière fiable contraint et vérifié l'exécution, ou parce que rien n'a mal tourné cette fois-ci ?",{"data":549,"type":42},{"text":550,"level":230},"Conclusion",{"data":552,"type":217},{"text":553},"L'industrie évolue rapidement de l'IA qui \u003Cb>répond\u003C\u002Fb> vers l'IA qui \u003Cb>agit\u003C\u002Fb>. Cette transition change ce que signifie la fiabilité. Pour un système de réponse, évaluer la réponse peut souvent suffire. Pour un système d'action, nous devons évaluer le chemin.",{"data":555,"type":278},{"code":556},"Invite\n↓\nLa réponse devient intention\n↓\nTrajectoire\n↓\nActions\n↓\nChangements d'état\n↓\nPreuves\n↓\nRésultat",{"data":558,"type":217},{"text":559},"La réponse finale reste importante, mais elle n'est que la partie visible d'un système bien plus vaste. Une fois que l'IA est autorisée à affecter le monde réel, \u003Cb>le chemin vers la réponse fait partie de la réponse.\u003C\u002Fb>","2.31","Une sortie correcte ne prouve pas un raisonnement correct, une exécution sûre ou un système digne de confiance.","\u002Fuploads\u002F2026\u002F09\u002Fai-agent-reliability-why-the-final-answer-is-not-enough-1788955466306-pl0qhz.webp","ai-agent-reliability-why-the-final-answer-is-not-enough-1788955466306-pl0qhz","PUBLISHED","2026-09-09T04:01:00.000Z","2026-09-09T12:01:07.219Z","2026-09-09T13:08:53.481Z",{"en":569,"de":570,"sr":571,"es":572,"fr":573,"it":574,"ru":575,"zh":576},"\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fde\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fsr\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fes\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Ffr\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fit\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fru\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough","\u002Fzh\u002Fblog\u002Fai-agent-reliability-why-the-final-answer-is-not-enough",[578,582],{"id":579,"name":580,"slug":581},58,"Évaluation et garde-fous qualité","evaluation",{"id":583,"name":584,"slug":585},59,"Gouvernance et audit","governance",{"id":587,"login":588,"email":589,"displayName":590},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[592,927],{"lang":593,"title":594,"content":595,"contentJson":596,"excerpt":926},"en","AI Agent Reliability: Why the Final Answer Is Not Enough","{\"time\":1788955485785,\"blocks\":[{\"data\":{\"text\":\"\u003Cb>Correct output does not prove correct reasoning, safe execution, or a trustworthy system.\u003C\u002Fb>\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"For years, AI evaluation has been dominated by a deceptively simple question: \u003Cb>Was the answer correct?\u003C\u002Fb> For a chatbot, this may sometimes be sufficient. For an agent capable of searching systems, reading data, calling tools, modifying state, executing workflows, writing files, interacting with APIs, or making decisions, it is not.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"An agent can produce the correct final answer while doing several things wrong on the way there. It can use the wrong source, misunderstand an instruction and later compensate for the mistake, access unnecessary information, execute an unauthorized intermediate action, silently recover from an error that should have triggered escalation, or leave behind side effects nobody noticed.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"That creates one of the central problems of agentic AI: \u003Cb>a correct outcome does not prove a correct trajectory.\u003C\u002Fb>\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"The Outcome Illusion\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Traditional software gives us an intuitive model of correctness. Input enters a deterministic or mostly deterministic system, logic is executed, output is produced, and tests verify expected behavior. LLM-based systems weaken this assumption. Agentic systems go further.\"},\"type\":\"paragraph\"},{\"data\":{\"items\":[\"model interpretation\",\"retrieved context\",\"tool selection\",\"intermediate observations\",\"external state\",\"previous actions\",\"model-generated plans\",\"permission boundaries\",\"retries and fallback behavior\",\"human interaction\"],\"style\":\"unordered\"},\"type\":\"list\"},{\"data\":{\"text\":\"Two executions starting from nearly identical inputs may reach the same result through very different paths. If evaluation observes only the final output, most of the system remains invisible.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Imagine an AI agent receives the instruction: \u003Ci>Update the customer's billing address.\u003C\u002Fi> The address is ultimately updated correctly. A conventional evaluation might classify the task as successful.\"},\"type\":\"paragraph\"},{\"data\":{\"items\":[\"The agent searches several unrelated customer records.\",\"It retrieves more personal information than required.\",\"It initially modifies the wrong account.\",\"It notices the mistake.\",\"It reverses the change.\",\"It updates the correct account.\",\"It reports success.\"],\"style\":\"ordered\"},\"type\":\"list\"},{\"data\":{\"text\":\"\u003Cb>Final state: correct. System behavior: unacceptable.\u003C\u002Fb> An outcome-only benchmark gives this execution a pass. A production assurance system should not.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"The Trajectory Is Part of the Product\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"This is why the \u003Cb>trajectory\u003C\u002Fb> of an AI agent must become a first-class engineering object. A trajectory is the sequence of relevant states and actions between the original request and the final result.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Intent → Context → Decision → Tool → Action → Observation → Decision → State change → Result\"},\"type\":\"code\"},{\"data\":{\"text\":\"Zachary J. Stevens develops this idea in \u003Ci>The Trajectory Is the System\u003C\u002Fi>, arguing that agentic evaluation must move beyond the final answer and examine the complete path of action through a changing environment.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"A correct outcome does not excuse an unacceptable trajectory.\",\"caption\":\"Zachary J. Stevens, The Trajectory Is the System\",\"alignment\":\"left\"},\"type\":\"quote\"},{\"data\":{\"link\":\"https:\u002F\u002Fzacharyjstevens.com\u002Fdispatches\u002Fvanguard-signal\u002F009-the-trajectory-is-the-system\u002F\",\"meta\":{\"image\":{},\"title\":\"The Trajectory Is the System\",\"description\":\"Zachary J. Stevens — DFEI.009 on evaluating agentic systems by their complete trajectory rather than only the final outcome.\"}},\"type\":\"linkTool\"},{\"data\":{\"text\":\"The distinction matters enormously. Reliability is therefore not simply \u003Cb>correct output\u003C\u002Fb>. It is closer to \u003Cb>acceptable outcome + acceptable trajectory + recoverability + evidence\u003C\u002Fb>.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"A Correct Answer Can Hide a Broken System\",\"level\":2},\"type\":\"header\"},{\"data\":{\"content\":[[\"Agent\",\"Final result\",\"Execution\"],[\"A\",\"Correct\",\"Correct path\"],[\"B\",\"Correct\",\"Unsafe path\"],[\"C\",\"Incorrect\",\"Safe failure\"],[\"D\",\"Incorrect\",\"Unsafe failure\"]],\"withHeadings\":true},\"type\":\"table\"},{\"data\":{\"text\":\"Most benchmark-driven evaluation strongly rewards A and B and penalizes C and D. Operationally, however, \u003Cb>B can be more dangerous than C\u003C\u002Fb>. Agent C may recognize uncertainty, stop execution and request human review. Agent B may confidently produce correct results while violating assumptions that nobody is monitoring.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"successful output → increased trust → broader permissions → more automation → larger blast radius\"},\"type\":\"code\"},{\"data\":{\"text\":\"We Need Evidence, Not Confidence\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"One of the biggest mistakes in AI adoption is treating model confidence, user satisfaction or historical success rate as evidence of system reliability. They are not equivalent.\"},\"type\":\"paragraph\"},{\"data\":{\"items\":[\"What did the agent receive?\",\"What context did it retrieve?\",\"Which tools did it call?\",\"Why was the action allowed?\",\"What state existed before the action?\",\"What changed?\",\"Which intermediate failures occurred?\",\"Was anything retried?\",\"Was human approval required?\",\"Could execution have been stopped?\",\"Can the action be reversed?\",\"Which model, prompt and tool versions were involved?\"],\"style\":\"unordered\"},\"type\":\"list\"},{\"data\":{\"text\":\"Without these answers, there is no serious operational assurance. There is only an output. Observability and evidence must therefore be designed into agent architecture rather than added after deployment.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Logging Is Not the Same as Control\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Organizations often respond: \u003Ci>Everything is logged.\u003C\u002Fi> Good. But logging alone does not control anything. A log tells you what happened. A control determines whether something \u003Cb>may happen\u003C\u002Fb>.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Agent requests DELETE \u002Fcustomer\u002F123 ↓\\nAction logged ↓\\nDELETE executed\"},\"type\":\"code\"},{\"data\":{\"text\":\"That gives observability. Compare it with:\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Agent requests DELETE \u002Fcustomer\u002F123 ↓\\nPolicy evaluation ↓\\nCurrent identity verified ↓\\nCurrent action parameters checked ↓\\nRisk threshold evaluated ↓\\nHuman approval if required ↓\\nAction executed ↓\\nResult verified ↓\\nEvidence stored\"},\"type\":\"code\"},{\"data\":{\"text\":\"Now we are approaching a control system. The difference is architectural, not cosmetic.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Permission Is Necessary — but It Is Not Assurance\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Suppose an agent has permission to send email. Access control answers: \u003Cb>Can this agent send email?\u003C\u002Fb> It does not answer: \u003Cb>Should this particular email be sent to this particular person with this particular attachment right now?\u003C\u002Fb>\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"CAPABILITY CONTROL\\nWhat is the agent technically allowed to do? + ACTION ASSURANCE\\nIs this specific action appropriate in the current state?\"},\"type\":\"code\"},{\"data\":{\"text\":\"RBAC, OAuth scopes, API permissions and agent identities define the space of possible actions. They do not prove that an action inside that space is appropriate. Strong agent architecture needs both layers.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"The First Wrong Step Matters\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"When an agent fails, the final incorrect action is often not where the failure started. The real failure may have happened much earlier.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Wrong retrieval ↓\\nWrong assumption ↓\\nPlausible reasoning ↓\\nValid tool call ↓\\nWrong action\"},\"type\":\"code\"},{\"data\":{\"text\":\"If we investigate only the final action, we fix the symptom. If we inspect the trajectory, we can identify the \u003Cb>first wrong step\u003C\u002Fb>. That turns an unattributable failure into a concrete engineering problem.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Agent Testing Must Move Beyond Prompt Testing\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Prompts matter, but production agent behavior emerges from an entire system.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"MODEL\\n+\\nSYSTEM PROMPT\\n+\\nCONTEXT\\n+\\nMEMORY\\n+\\nRETRIEVAL\\n+\\nTOOLS\\n+\\nPERMISSIONS\\n+\\nWORKFLOW\\n+\\nEXTERNAL STATE\\n+\\nCONTROL LOGIC\"},\"type\":\"code\"},{\"data\":{\"text\":\"Changing any one of these can change the trajectory. Therefore versioning only the prompt is insufficient.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"model_version\\nprompt_version\\ntool_version\\npolicy_version\\nretrieval_version\\nworkflow_version\\nenvironment_state\\nexecution_id\"},\"type\":\"code\"},{\"data\":{\"text\":\"Acceptance Criteria for Agents Must Include Behavior\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Traditional acceptance criteria often look like this: \u003Ci>Given X, the system produces Y.\u003C\u002Fi> For agentic systems, that is incomplete. Acceptance criteria should also define constraints on the trajectory.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Outcome\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The customer's address is updated correctly.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Authorization\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The agent modifies only the explicitly selected customer.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Data access\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"No unrelated customer records are accessed.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Tools\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"Only approved CRM operations are used.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Verification\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The new address is read back and compared with the requested value.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Failure\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"Ambiguous identity resolution stops execution.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Human authority\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"A human can reject the modification before execution when risk thresholds require approval.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Evidence\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The execution leaves a trace sufficient to reconstruct the decision and state transition.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Recovery\",\"level\":3},\"type\":\"header\"},{\"data\":{\"text\":\"The previous value remains recoverable.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Human-in-the-Loop Is Not Enough\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Adding a human approval box does not automatically solve the problem. A human can only control an agent if the person has visibility, authority, time, context and recovery capability.\"},\"type\":\"paragraph\"},{\"data\":{\"items\":[\"\u003Cb>Visibility:\u003C\u002Fb> enough information to understand what is happening.\",\"\u003Cb>Authority:\u003C\u002Fb> actual ability to stop or modify the action.\",\"\u003Cb>Time:\u003C\u002Fb> intervention before the consequence occurs.\",\"\u003Cb>Context:\u003C\u002Fb> sufficient evidence to make the decision.\",\"\u003Cb>Recovery capability:\u003C\u002Fb> ability to reverse or repair the action.\"],\"style\":\"unordered\"},\"type\":\"list\"},{\"data\":{\"text\":\"A user clicking \u003Cb>Approve\u003C\u002Fb> on something they cannot meaningfully inspect is not strong governance. It is approval theater.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Rollback Must Become a Native AI Capability\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Traditional software deployment has taught us something valuable: \u003Cb>Never deploy what you cannot roll back.\u003C\u002Fb> We should apply the same principle to agentic actions.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"REVERSIBLE\\nCan automatically undo. COMPENSATABLE\\nCannot undo directly but can execute a compensating action. IRREVERSIBLE\\nCannot reliably restore the previous state.\"},\"type\":\"code\"},{\"data\":{\"text\":\"The higher the irreversibility, the stronger the control requirement should become.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Read public document → low consequence\\nCreate draft → reversible\\nModify CRM record → reversible but consequential\\nSend external email → practically irreversible\\nTransfer money → high consequence\\nDelete production data → potentially catastrophic\"},\"type\":\"code\"},{\"data\":{\"text\":\"The Agent Needs a Control Plane\",\"level\":2},\"type\":\"header\"},{\"data\":{\"code\":\"USER \u002F SYSTEM INTENT │ ▼ AI AGENT │ proposed action │ ▼ ┌───────────────────┐ │ CONTROL PLANE │ ├───────────────────┤ │ Identity │ │ Authorization │ │ Policy │ │ Risk │ │ State │ │ Evidence │ │ Human authority │ │ Rollback │ └───────────────────┘ │ approved? \u002F \\\\ NO YES │ │ STOP ▼ TOOL │ ▼ STATE CHANGE │ ▼ VERIFICATION\"},\"type\":\"code\"},{\"data\":{\"text\":\"\u003Cb>The LLM should propose. The control plane should govern.\u003C\u002Fb> That separation is crucial. The model should not be the ultimate authority determining whether its own proposed high-impact action is safe.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"From Benchmarks to Operational Trust\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Benchmarks remain useful. They tell us about capability, compare models, detect regressions and help estimate expected performance. But capability evaluation and operational trust answer different questions.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"A benchmark asks: \u003Cb>Can the system do this?\u003C\u002Fb> Operational assurance asks: \u003Cb>Can we allow the system to do this here, under these conditions, with these permissions and consequences?\u003C\u002Fb>\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Reliability Should Be Measured as a System Property\",\"level\":2},\"type\":\"header\"},{\"data\":{\"items\":[\"\u003Cb>Outcome correctness:\u003C\u002Fb> Did the system produce the expected result?\",\"\u003Cb>Trajectory correctness:\u003C\u002Fb> Did it follow an acceptable path?\",\"\u003Cb>Control integrity:\u003C\u002Fb> Were authorization, policy and intervention boundaries respected?\",\"\u003Cb>Recoverability:\u003C\u002Fb> Can failures be contained, reversed or repaired?\",\"\u003Cb>Evidence completeness:\u003C\u002Fb> Can the execution be reconstructed and audited?\"],\"style\":\"ordered\"},\"type\":\"list\"},{\"data\":{\"code\":\"Operational Reliability\\n=\\nOutcome × Trajectory × Control × Recoverability × Evidence\"},\"type\":\"code\"},{\"data\":{\"text\":\"The multiplication is intentional. If one critical dimension approaches zero, a high score elsewhere should not hide it. A perfectly correct output with zero authorization integrity is not an 80% reliable system. It is an unacceptable execution that happened to produce the right answer.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Success Is Sometimes the Most Dangerous Failure\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"Failures attract attention. Success often does not. That makes successful but uncontrolled agent trajectories particularly dangerous. An obvious failure creates an incident. A hidden trajectory defect creates \u003Cb>confidence\u003C\u002Fb>. And confidence expands autonomy.\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Organizations should therefore not only investigate \u003Ci>Why did the agent fail?\u003C\u002Fi> They should periodically ask: \u003Cb>Why did the agent succeed?\u003C\u002Fb> Did it succeed because the architecture reliably constrained and verified the execution, or because nothing went wrong this time?\"},\"type\":\"paragraph\"},{\"data\":{\"text\":\"Conclusion\",\"level\":2},\"type\":\"header\"},{\"data\":{\"text\":\"The industry is moving rapidly from AI that \u003Cb>answers\u003C\u002Fb> toward AI that \u003Cb>acts\u003C\u002Fb>. That transition changes what reliability means. For an answer system, evaluating the answer may often be sufficient. For an action system, we must evaluate the path.\"},\"type\":\"paragraph\"},{\"data\":{\"code\":\"Prompt ↓\\nResponse becomes Intent ↓\\nTrajectory ↓\\nActions ↓\\nState changes ↓\\nEvidence ↓\\nOutcome\"},\"type\":\"code\"},{\"data\":{\"text\":\"The final answer remains important, but it is only the visible end of a much larger system. Once AI is allowed to affect the real world, \u003Cb>the path to the answer becomes part of the answer.\u003C\u002Fb>\"},\"type\":\"paragraph\"}],\"version\":\"2.31.0\"}",{"time":597,"blocks":598,"version":925},1788955485785,[599,602,605,608,611,614,617,630,633,636,646,649,652,655,658,661,665,671,674,677,691,694,697,700,703,718,721,724,727,730,733,736,739,742,745,748,751,754,757,760,763,766,769,772,775,778,781,784,787,790,793,796,799,802,805,808,811,814,817,820,823,826,829,832,835,838,841,844,852,855,858,861,864,867,870,873,876,879,882,885,888,891,899,902,905,908,911,914,916,919,922],{"data":600,"type":217},{"text":601},"\u003Cb>Correct output does not prove correct reasoning, safe execution, or a trustworthy system.\u003C\u002Fb>",{"data":603,"type":217},{"text":604},"For years, AI evaluation has been dominated by a deceptively simple question: \u003Cb>Was the answer correct?\u003C\u002Fb> For a chatbot, this may sometimes be sufficient. For an agent capable of searching systems, reading data, calling tools, modifying state, executing workflows, writing files, interacting with APIs, or making decisions, it is not.",{"data":606,"type":217},{"text":607},"An agent can produce the correct final answer while doing several things wrong on the way there. It can use the wrong source, misunderstand an instruction and later compensate for the mistake, access unnecessary information, execute an unauthorized intermediate action, silently recover from an error that should have triggered escalation, or leave behind side effects nobody noticed.",{"data":609,"type":217},{"text":610},"That creates one of the central problems of agentic AI: \u003Cb>a correct outcome does not prove a correct trajectory.\u003C\u002Fb>",{"data":612,"type":42},{"text":613,"level":230},"The Outcome Illusion",{"data":615,"type":217},{"text":616},"Traditional software gives us an intuitive model of correctness. Input enters a deterministic or mostly deterministic system, logic is executed, output is produced, and tests verify expected behavior. LLM-based systems weaken this assumption. Agentic systems go further.",{"data":618,"type":248},{"items":619,"style":247},[620,621,622,623,624,625,626,627,628,629],"model interpretation","retrieved context","tool selection","intermediate observations","external state","previous actions","model-generated plans","permission boundaries","retries and fallback behavior","human interaction",{"data":631,"type":217},{"text":632},"Two executions starting from nearly identical inputs may reach the same result through very different paths. If evaluation observes only the final output, most of the system remains invisible.",{"data":634,"type":217},{"text":635},"Imagine an AI agent receives the instruction: \u003Ci>Update the customer's billing address.\u003C\u002Fi> The address is ultimately updated correctly. A conventional evaluation might classify the task as successful.",{"data":637,"type":248},{"items":638,"style":265},[639,640,641,642,643,644,645],"The agent searches several unrelated customer records.","It retrieves more personal information than required.","It initially modifies the wrong account.","It notices the mistake.","It reverses the change.","It updates the correct account.","It reports success.",{"data":647,"type":217},{"text":648},"\u003Cb>Final state: correct. System behavior: unacceptable.\u003C\u002Fb> An outcome-only benchmark gives this execution a pass. A production assurance system should not.",{"data":650,"type":42},{"text":651,"level":230},"The Trajectory Is Part of the Product",{"data":653,"type":217},{"text":654},"This is why the \u003Cb>trajectory\u003C\u002Fb> of an AI agent must become a first-class engineering object. A trajectory is the sequence of relevant states and actions between the original request and the final result.",{"data":656,"type":278},{"code":657},"Intent → Context → Decision → Tool → Action → Observation → Decision → State change → Result",{"data":659,"type":217},{"text":660},"Zachary J. Stevens develops this idea in \u003Ci>The Trajectory Is the System\u003C\u002Fi>, arguing that agentic evaluation must move beyond the final answer and examine the complete path of action through a changing environment.",{"data":662,"type":287},{"text":663,"caption":664,"alignment":286},"A correct outcome does not excuse an unacceptable trajectory.","Zachary J. Stevens, The Trajectory Is the System",{"data":666,"type":295},{"link":290,"meta":667},{"image":668,"title":669,"description":670},{},"The Trajectory Is the System","Zachary J. Stevens — DFEI.009 on evaluating agentic systems by their complete trajectory rather than only the final outcome.",{"data":672,"type":217},{"text":673},"The distinction matters enormously. Reliability is therefore not simply \u003Cb>correct output\u003C\u002Fb>. It is closer to \u003Cb>acceptable outcome + acceptable trajectory + recoverability + evidence\u003C\u002Fb>.",{"data":675,"type":42},{"text":676,"level":230},"A Correct Answer Can Hide a Broken System",{"data":678,"type":323},{"content":679,"withHeadings":14},[680,683,685,687,689],[306,681,682],"Final result","Execution",[310,311,684],"Correct path",[314,311,686],"Unsafe path",[317,318,688],"Safe failure",[321,318,690],"Unsafe failure",{"data":692,"type":217},{"text":693},"Most benchmark-driven evaluation strongly rewards A and B and penalizes C and D. Operationally, however, \u003Cb>B can be more dangerous than C\u003C\u002Fb>. Agent C may recognize uncertainty, stop execution and request human review. Agent B may confidently produce correct results while violating assumptions that nobody is monitoring.",{"data":695,"type":278},{"code":696},"successful output → increased trust → broader permissions → more automation → larger blast radius",{"data":698,"type":42},{"text":699,"level":230},"We Need Evidence, Not Confidence",{"data":701,"type":217},{"text":702},"One of the biggest mistakes in AI adoption is treating model confidence, user satisfaction or historical success rate as evidence of system reliability. They are not equivalent.",{"data":704,"type":248},{"items":705,"style":247},[706,707,708,709,710,711,712,713,714,715,716,717],"What did the agent receive?","What context did it retrieve?","Which tools did it call?","Why was the action allowed?","What state existed before the action?","What changed?","Which intermediate failures occurred?","Was anything retried?","Was human approval required?","Could execution have been stopped?","Can the action be reversed?","Which model, prompt and tool versions were involved?",{"data":719,"type":217},{"text":720},"Without these answers, there is no serious operational assurance. There is only an output. Observability and evidence must therefore be designed into agent architecture rather than added after deployment.",{"data":722,"type":42},{"text":723,"level":230},"Logging Is Not the Same as Control",{"data":725,"type":217},{"text":726},"Organizations often respond: \u003Ci>Everything is logged.\u003C\u002Fi> Good. But logging alone does not control anything. A log tells you what happened. A control determines whether something \u003Cb>may happen\u003C\u002Fb>.",{"data":728,"type":278},{"code":729},"Agent requests DELETE \u002Fcustomer\u002F123 ↓\nAction logged ↓\nDELETE executed",{"data":731,"type":217},{"text":732},"That gives observability. Compare it with:",{"data":734,"type":278},{"code":735},"Agent requests DELETE \u002Fcustomer\u002F123 ↓\nPolicy evaluation ↓\nCurrent identity verified ↓\nCurrent action parameters checked ↓\nRisk threshold evaluated ↓\nHuman approval if required ↓\nAction executed ↓\nResult verified ↓\nEvidence stored",{"data":737,"type":217},{"text":738},"Now we are approaching a control system. The difference is architectural, not cosmetic.",{"data":740,"type":42},{"text":741,"level":230},"Permission Is Necessary — but It Is Not Assurance",{"data":743,"type":217},{"text":744},"Suppose an agent has permission to send email. Access control answers: \u003Cb>Can this agent send email?\u003C\u002Fb> It does not answer: \u003Cb>Should this particular email be sent to this particular person with this particular attachment right now?\u003C\u002Fb>",{"data":746,"type":278},{"code":747},"CAPABILITY CONTROL\nWhat is the agent technically allowed to do? + ACTION ASSURANCE\nIs this specific action appropriate in the current state?",{"data":749,"type":217},{"text":750},"RBAC, OAuth scopes, API permissions and agent identities define the space of possible actions. They do not prove that an action inside that space is appropriate. Strong agent architecture needs both layers.",{"data":752,"type":42},{"text":753,"level":230},"The First Wrong Step Matters",{"data":755,"type":217},{"text":756},"When an agent fails, the final incorrect action is often not where the failure started. The real failure may have happened much earlier.",{"data":758,"type":278},{"code":759},"Wrong retrieval ↓\nWrong assumption ↓\nPlausible reasoning ↓\nValid tool call ↓\nWrong action",{"data":761,"type":217},{"text":762},"If we investigate only the final action, we fix the symptom. If we inspect the trajectory, we can identify the \u003Cb>first wrong step\u003C\u002Fb>. That turns an unattributable failure into a concrete engineering problem.",{"data":764,"type":42},{"text":765,"level":230},"Agent Testing Must Move Beyond Prompt Testing",{"data":767,"type":217},{"text":768},"Prompts matter, but production agent behavior emerges from an entire system.",{"data":770,"type":278},{"code":771},"MODEL\n+\nSYSTEM PROMPT\n+\nCONTEXT\n+\nMEMORY\n+\nRETRIEVAL\n+\nTOOLS\n+\nPERMISSIONS\n+\nWORKFLOW\n+\nEXTERNAL STATE\n+\nCONTROL LOGIC",{"data":773,"type":217},{"text":774},"Changing any one of these can change the trajectory. Therefore versioning only the prompt is insufficient.",{"data":776,"type":278},{"code":777},"model_version\nprompt_version\ntool_version\npolicy_version\nretrieval_version\nworkflow_version\nenvironment_state\nexecution_id",{"data":779,"type":42},{"text":780,"level":230},"Acceptance Criteria for Agents Must Include Behavior",{"data":782,"type":217},{"text":783},"Traditional acceptance criteria often look like this: \u003Ci>Given X, the system produces Y.\u003C\u002Fi> For agentic systems, that is incomplete. Acceptance criteria should also define constraints on the trajectory.",{"data":785,"type":42},{"text":786,"level":420},"Outcome",{"data":788,"type":217},{"text":789},"The customer's address is updated correctly.",{"data":791,"type":42},{"text":792,"level":420},"Authorization",{"data":794,"type":217},{"text":795},"The agent modifies only the explicitly selected customer.",{"data":797,"type":42},{"text":798,"level":420},"Data access",{"data":800,"type":217},{"text":801},"No unrelated customer records are accessed.",{"data":803,"type":42},{"text":804,"level":420},"Tools",{"data":806,"type":217},{"text":807},"Only approved CRM operations are used.",{"data":809,"type":42},{"text":810,"level":420},"Verification",{"data":812,"type":217},{"text":813},"The new address is read back and compared with the requested value.",{"data":815,"type":42},{"text":816,"level":420},"Failure",{"data":818,"type":217},{"text":819},"Ambiguous identity resolution stops execution.",{"data":821,"type":42},{"text":822,"level":420},"Human authority",{"data":824,"type":217},{"text":825},"A human can reject the modification before execution when risk thresholds require approval.",{"data":827,"type":42},{"text":828,"level":420},"Evidence",{"data":830,"type":217},{"text":831},"The execution leaves a trace sufficient to reconstruct the decision and state transition.",{"data":833,"type":42},{"text":834,"level":420},"Recovery",{"data":836,"type":217},{"text":837},"The previous value remains recoverable.",{"data":839,"type":42},{"text":840,"level":230},"Human-in-the-Loop Is Not Enough",{"data":842,"type":217},{"text":843},"Adding a human approval box does not automatically solve the problem. A human can only control an agent if the person has visibility, authority, time, context and recovery capability.",{"data":845,"type":248},{"items":846,"style":247},[847,848,849,850,851],"\u003Cb>Visibility:\u003C\u002Fb> enough information to understand what is happening.","\u003Cb>Authority:\u003C\u002Fb> actual ability to stop or modify the action.","\u003Cb>Time:\u003C\u002Fb> intervention before the consequence occurs.","\u003Cb>Context:\u003C\u002Fb> sufficient evidence to make the decision.","\u003Cb>Recovery capability:\u003C\u002Fb> ability to reverse or repair the action.",{"data":853,"type":217},{"text":854},"A user clicking \u003Cb>Approve\u003C\u002Fb> on something they cannot meaningfully inspect is not strong governance. It is approval theater.",{"data":856,"type":42},{"text":857,"level":230},"Rollback Must Become a Native AI Capability",{"data":859,"type":217},{"text":860},"Traditional software deployment has taught us something valuable: \u003Cb>Never deploy what you cannot roll back.\u003C\u002Fb> We should apply the same principle to agentic actions.",{"data":862,"type":278},{"code":863},"REVERSIBLE\nCan automatically undo. COMPENSATABLE\nCannot undo directly but can execute a compensating action. IRREVERSIBLE\nCannot reliably restore the previous state.",{"data":865,"type":217},{"text":866},"The higher the irreversibility, the stronger the control requirement should become.",{"data":868,"type":278},{"code":869},"Read public document → low consequence\nCreate draft → reversible\nModify CRM record → reversible but consequential\nSend external email → practically irreversible\nTransfer money → high consequence\nDelete production data → potentially catastrophic",{"data":871,"type":42},{"text":872,"level":230},"The Agent Needs a Control Plane",{"data":874,"type":278},{"code":875},"USER \u002F SYSTEM INTENT │ ▼ AI AGENT │ proposed action │ ▼ ┌───────────────────┐ │ CONTROL PLANE │ ├───────────────────┤ │ Identity │ │ Authorization │ │ Policy │ │ Risk │ │ State │ │ Evidence │ │ Human authority │ │ Rollback │ └───────────────────┘ │ approved? \u002F \\ NO YES │ │ STOP ▼ TOOL │ ▼ STATE CHANGE │ ▼ VERIFICATION",{"data":877,"type":217},{"text":878},"\u003Cb>The LLM should propose. The control plane should govern.\u003C\u002Fb> That separation is crucial. The model should not be the ultimate authority determining whether its own proposed high-impact action is safe.",{"data":880,"type":42},{"text":881,"level":230},"From Benchmarks to Operational Trust",{"data":883,"type":217},{"text":884},"Benchmarks remain useful. They tell us about capability, compare models, detect regressions and help estimate expected performance. But capability evaluation and operational trust answer different questions.",{"data":886,"type":217},{"text":887},"A benchmark asks: \u003Cb>Can the system do this?\u003C\u002Fb> Operational assurance asks: \u003Cb>Can we allow the system to do this here, under these conditions, with these permissions and consequences?\u003C\u002Fb>",{"data":889,"type":42},{"text":890,"level":230},"Reliability Should Be Measured as a System Property",{"data":892,"type":248},{"items":893,"style":265},[894,895,896,897,898],"\u003Cb>Outcome correctness:\u003C\u002Fb> Did the system produce the expected result?","\u003Cb>Trajectory correctness:\u003C\u002Fb> Did it follow an acceptable path?","\u003Cb>Control integrity:\u003C\u002Fb> Were authorization, policy and intervention boundaries respected?","\u003Cb>Recoverability:\u003C\u002Fb> Can failures be contained, reversed or repaired?","\u003Cb>Evidence completeness:\u003C\u002Fb> Can the execution be reconstructed and audited?",{"data":900,"type":278},{"code":901},"Operational Reliability\n=\nOutcome × Trajectory × Control × Recoverability × Evidence",{"data":903,"type":217},{"text":904},"The multiplication is intentional. If one critical dimension approaches zero, a high score elsewhere should not hide it. A perfectly correct output with zero authorization integrity is not an 80% reliable system. It is an unacceptable execution that happened to produce the right answer.",{"data":906,"type":42},{"text":907,"level":230},"Success Is Sometimes the Most Dangerous Failure",{"data":909,"type":217},{"text":910},"Failures attract attention. Success often does not. That makes successful but uncontrolled agent trajectories particularly dangerous. An obvious failure creates an incident. A hidden trajectory defect creates \u003Cb>confidence\u003C\u002Fb>. And confidence expands autonomy.",{"data":912,"type":217},{"text":913},"Organizations should therefore not only investigate \u003Ci>Why did the agent fail?\u003C\u002Fi> They should periodically ask: \u003Cb>Why did the agent succeed?\u003C\u002Fb> Did it succeed because the architecture reliably constrained and verified the execution, or because nothing went wrong this time?",{"data":915,"type":42},{"text":550,"level":230},{"data":917,"type":217},{"text":918},"The industry is moving rapidly from AI that \u003Cb>answers\u003C\u002Fb> toward AI that \u003Cb>acts\u003C\u002Fb>. That transition changes what reliability means. For an answer system, evaluating the answer may often be sufficient. For an action system, we must evaluate the path.",{"data":920,"type":278},{"code":921},"Prompt ↓\nResponse becomes Intent ↓\nTrajectory ↓\nActions ↓\nState changes ↓\nEvidence ↓\nOutcome",{"data":923,"type":217},{"text":924},"The final answer remains important, but it is only the visible end of a much larger system. Once AI is allowed to affect the real world, \u003Cb>the path to the answer becomes part of the answer.\u003C\u002Fb>","2.31.0","Correct output does not prove correct reasoning, safe execution, or a trustworthy system.",{"lang":7,"title":208,"content":210,"contentJson":928,"excerpt":561},{"time":212,"blocks":929,"version":560},[930,932,934,936,938,940,942,945,947,949,952,954,956,958,960,962,964,968,970,972,980,982,984,986,988,991,993,995,997,999,1001,1003,1005,1007,1009,1011,1013,1015,1017,1019,1021,1023,1025,1027,1029,1031,1033,1035,1037,1039,1041,1043,1045,1047,1049,1051,1053,1055,1057,1059,1061,1063,1065,1067,1069,1071,1073,1075,1078,1080,1082,1084,1086,1088,1090,1092,1094,1096,1098,1100,1102,1104,1107,1109,1111,1113,1115,1117,1119,1121,1123],{"data":931,"type":217},{"text":216},{"data":933,"type":217},{"text":220},{"data":935,"type":217},{"text":223},{"data":937,"type":217},{"text":226},{"data":939,"type":42},{"text":229,"level":230},{"data":941,"type":217},{"text":233},{"data":943,"type":248},{"items":944,"style":247},[237,238,239,240,241,242,243,244,245,246],{"data":946,"type":217},{"text":251},{"data":948,"type":217},{"text":254},{"data":950,"type":248},{"items":951,"style":265},[258,259,260,261,262,263,264],{"data":953,"type":217},{"text":268},{"data":955,"type":42},{"text":271,"level":230},{"data":957,"type":217},{"text":274},{"data":959,"type":278},{"code":277},{"data":961,"type":217},{"text":281},{"data":963,"type":287},{"text":284,"caption":285,"alignment":286},{"data":965,"type":295},{"link":290,"meta":966},{"image":967,"title":293,"description":294},{},{"data":969,"type":217},{"text":298},{"data":971,"type":42},{"text":301,"level":230},{"data":973,"type":323},{"content":974,"withHeadings":14},[975,976,977,978,979],[306,307,308],[310,311,312],[314,311,315],[317,318,319],[321,318,322],{"data":981,"type":217},{"text":326},{"data":983,"type":278},{"code":329},{"data":985,"type":42},{"text":332,"level":230},{"data":987,"type":217},{"text":335},{"data":989,"type":248},{"items":990,"style":247},[339,340,341,342,343,344,345,346,347,348,349,350],{"data":992,"type":217},{"text":353},{"data":994,"type":42},{"text":356,"level":230},{"data":996,"type":217},{"text":359},{"data":998,"type":278},{"code":362},{"data":1000,"type":217},{"text":365},{"data":1002,"type":278},{"code":368},{"data":1004,"type":217},{"text":371},{"data":1006,"type":42},{"text":374,"level":230},{"data":1008,"type":217},{"text":377},{"data":1010,"type":278},{"code":380},{"data":1012,"type":217},{"text":383},{"data":1014,"type":42},{"text":386,"level":230},{"data":1016,"type":217},{"text":389},{"data":1018,"type":278},{"code":392},{"data":1020,"type":217},{"text":395},{"data":1022,"type":42},{"text":398,"level":230},{"data":1024,"type":217},{"text":401},{"data":1026,"type":278},{"code":404},{"data":1028,"type":217},{"text":407},{"data":1030,"type":278},{"code":410},{"data":1032,"type":42},{"text":413,"level":230},{"data":1034,"type":217},{"text":416},{"data":1036,"type":42},{"text":419,"level":420},{"data":1038,"type":217},{"text":423},{"data":1040,"type":42},{"text":426,"level":420},{"data":1042,"type":217},{"text":429},{"data":1044,"type":42},{"text":432,"level":420},{"data":1046,"type":217},{"text":435},{"data":1048,"type":42},{"text":438,"level":420},{"data":1050,"type":217},{"text":441},{"data":1052,"type":42},{"text":444,"level":420},{"data":1054,"type":217},{"text":447},{"data":1056,"type":42},{"text":450,"level":420},{"data":1058,"type":217},{"text":453},{"data":1060,"type":42},{"text":456,"level":420},{"data":1062,"type":217},{"text":459},{"data":1064,"type":42},{"text":462,"level":420},{"data":1066,"type":217},{"text":465},{"data":1068,"type":42},{"text":468,"level":420},{"data":1070,"type":217},{"text":471},{"data":1072,"type":42},{"text":474,"level":230},{"data":1074,"type":217},{"text":477},{"data":1076,"type":248},{"items":1077,"style":247},[481,482,483,484,485],{"data":1079,"type":217},{"text":488},{"data":1081,"type":42},{"text":491,"level":230},{"data":1083,"type":217},{"text":494},{"data":1085,"type":278},{"code":497},{"data":1087,"type":217},{"text":500},{"data":1089,"type":278},{"code":503},{"data":1091,"type":42},{"text":506,"level":230},{"data":1093,"type":278},{"code":509},{"data":1095,"type":217},{"text":512},{"data":1097,"type":42},{"text":515,"level":230},{"data":1099,"type":217},{"text":518},{"data":1101,"type":217},{"text":521},{"data":1103,"type":42},{"text":524,"level":230},{"data":1105,"type":248},{"items":1106,"style":265},[528,529,530,531,532],{"data":1108,"type":278},{"code":535},{"data":1110,"type":217},{"text":538},{"data":1112,"type":42},{"text":541,"level":230},{"data":1114,"type":217},{"text":544},{"data":1116,"type":217},{"text":547},{"data":1118,"type":42},{"text":550,"level":230},{"data":1120,"type":217},{"text":553},{"data":1122,"type":278},{"code":556},{"data":1124,"type":217},{"text":559},"Post erfolgreich abgerufen",{"items":1127,"source":1198,"manualIds":1199,"manualMatchedIds":1200},[1128,1135,1142,1149,1156,1163,1170,1177,1184,1191],{"id":1129,"slug":1130,"title":1131,"excerpt":1132,"featuredImage":1133,"publishedAt":1134},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Maîtriser le flux de travail SEO : Stratégies d'optimisation essentielles pour la croissance organique","Un flux de travail SEO structuré est crucial pour une croissance organique durable. Découvrez les dix stratégies fondamentales, de la recherche de mots-clés et l'optimisation technique à la qualité du contenu et l'analyse des performances.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":1136,"slug":1137,"title":1138,"excerpt":1139,"featuredImage":1140,"publishedAt":1141},"480","when-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger","Quand une IA devrait-elle cesser de faire confiance à ses propres connaissances ? — Le déclencheur de récupération","Un modèle d'IA n'a pas besoin de récupération pour chaque question. Le problème important est de savoir quand ses connaissances internes ne suffisent plus. Le Déclencheur de Récupération est une frontière de décision pratique qui détermine quand un système d'IA devrait cesser de se fier uniquement aux connaissances du modèle et obtenir des preuves externes avant de répondre.","\u002Fuploads\u002F2026\u002F09\u002Fwhen-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger-1790574991244-f4rpyg.webp","2026-09-28T01:49:00.000Z",{"id":1143,"slug":1144,"title":1145,"excerpt":1146,"featuredImage":1147,"publishedAt":1148},"479","where-does-an-llm-get-its-data-rag-data-sources-in-python","D'où un LLM tire-t-il ses données ? Sources de données RAG en Python","Un LLM ne connaît pas magiquement vos fichiers, bases de données ou API. Cette suite pratique de la série sur le RAG montre, avec du Python simple, comment des données externes deviennent des preuves récupérables : des fichiers texte et du SQL à la recherche en texte intégral, aux embeddings, à l'assemblage du contexte et à l'appel final au LLM.","\u002Fuploads\u002F2026\u002F09\u002Fwhere-does-an-llm-get-its-data-rag-data-sources-in-python-1790517200521-nfsi5i.webp","2026-09-27T05:51:00.000Z",{"id":1150,"slug":1151,"title":1152,"excerpt":1153,"featuredImage":1154,"publishedAt":1155},"469","rag-failed-but-which-layer-actually-failed-a-diagnostic-method","Échec du RAG — mais quelle couche a réellement échoué ? Une méthode de diagnostic","Lorsqu'une réponse RAG est erronée, blâmer la récupération ou le modèle est trop vague. Cette méthode de diagnostic isole la couverture des sources, la construction de la requête, la récupération, le classement, l'assemblage du contexte, la génération, l'attribution des preuves et la fraîcheur—afin que la défaillance réelle puisse être reproduite et corrigée.","\u002Fuploads\u002F2026\u002F09\u002Frag-failed-but-which-layer-actually-failed-a-diagnostic-method-1790350847177-pior4c.webp","2026-09-24T19:39:00.000Z",{"id":1157,"slug":1158,"title":1159,"excerpt":1160,"featuredImage":1161,"publishedAt":1162},"493","mlops-vs-llmops-what-changes-when-the-model-is-an-llm","MLOps vs LLMOps : qu'est-ce qui change lorsque le modèle est un LLM","MLOps exploite les systèmes d'apprentissage automatique ; LLMOps étend ces pratiques aux prompts, au contexte, à la récupération, aux fournisseurs, aux outils, aux évaluations et au comportement d'exécution autour des grands modèles de langage.","\u002Fuploads\u002F2026\u002F10\u002Fmlops-vs-llmops-what-changes-when-the-model-is-an-llm-1791487319869-2v7hxo.webp","2026-10-08T15:20:00.000Z",{"id":1164,"slug":1165,"title":1166,"excerpt":1167,"featuredImage":1168,"publishedAt":1169},"459","ollama-is-not-the-product-building-production-ready-open-llm-applications","Ollama n'est pas le produit : construire des applications Open-LLM prêtes pour la production","Exécuter un modèle local avec Ollama est facile. Construire une application Open-LLM prête pour la production est plus difficile : cela nécessite du RAG, du contrôle d'accès, de l'abstraction de fournisseur, de l'évaluation, de la journalisation, de la discipline de déploiement et une couche applicative contrôlée autour du modèle.","\u002Fuploads\u002F2026\u002F06\u002Follama-is-not-the-product-building-production-ready-open-llm-applications-1782679361640-h0usqf.webp","2026-06-28T16:39:00.000Z",{"id":1171,"slug":1172,"title":1173,"excerpt":1174,"featuredImage":1175,"publishedAt":1176},"485","enterprise-ai-architecture-what-changes-when-ai-enters-a-company","Architecture de l’IA en entreprise : ce qui change lorsque l’IA entre dans une entreprise","L'architecture de l'IA en entreprise explique comment l'IA transforme les systèmes d'entreprise à travers l'autorité des données, l'identité, les autorisations, les fournisseurs, les risques, la gouvernance, l'évaluation, la conformité et les opérations.","\u002Fuploads\u002F2026\u002F10\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company-1791478161363-czrwaq.webp","2026-10-08T10:48:00.000Z",{"id":1178,"slug":1179,"title":1180,"excerpt":1181,"featuredImage":1182,"publishedAt":1183},"489","agentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act","L'IA agentique expliquée : quand un système d'IA peut planifier, utiliser des outils et agir","L'IA agentique utilise des modèles au sein de boucles d'exécution multi-étapes où ils peuvent choisir des outils, observer les résultats, mettre à jour l'état et adapter leur action suivante dans des limites explicites d'exécution et de permissions.","\u002Fuploads\u002F2026\u002F10\u002Fagentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act-1791481499084-wnji2a.webp","2026-10-08T11:43:00.000Z",{"id":1185,"slug":1186,"title":1187,"excerpt":1188,"featuredImage":1189,"publishedAt":1190},"478","what-is-rag-the-simplest-explanation-of-how-it-works","Qu'est-ce que le RAG ? L'explication la plus simple de son fonctionnement","Le RAG semble compliqué, mais l'idée est simple : avant qu'une IA ne réponde, elle recherche d'abord des informations utiles dans une source de connaissances et transmet ces informations au modèle de langage. Ce guide explique le RAG, les LLM, l'état, la mémoire et les outils à l'aide d'un modèle mental simple.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z",{"id":1192,"slug":1193,"title":1194,"excerpt":1195,"featuredImage":1196,"publishedAt":1197},"477","computer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system","Agents d'utilisation de l'ordinateur : pourquoi une démonstration réussie peut tout de même être un système peu fiable","Les agents d'utilisation de l'ordinateur peuvent désormais accomplir d'impressionnants flux de travail sur navigateur et sur bureau, mais une seule exécution réussie prouve la capacité—non la fiabilité. Cet article montre comment tester la répétabilité, la robustesse environnementale, le contrôle à long horizon, la conscience de l'état, la vérification des résultats et la gestion sécurisée des objectifs.","\u002Fuploads\u002F2026\u002F09\u002Fcomputer-use-agents-why-a-successful-demo-can-still-be-an-unreliable-system-1790352854690-75qnrg.webp","2026-09-25T12:13:00.000Z","fallback",[],[]]