Databricks montre comment créer des agents durables avec Temporal et Lakebase, mais la démo révèle la partie difficile

Databricks a publié le 8 septembre une implémentation de référence montrant comment créer des agents durables avec Temporal et Lakebase malgré les pannes de workers, les nouvelles tentatives et les revues sur plusieurs jours. Le système applique cette architecture à l'évaluation de prêts personnels, où la perte d'une vérification achevée peut compromettre la traçabilité d'une décision.

L'évolution importante n'est ni un nouveau framework d'agents ni un modèle plus grand. Databricks et Temporal ont réparti l'état de l'agent entre deux systèmes aux responsabilités distinctes. Temporal préserve le flux de contrôle, tandis que Lakebase expose des données opérationnelles interrogeables par les applications, les réviseurs et les analystes.

Cette répartition crée aussi la tension centrale. L'exécution durable peut récupérer le travail enregistré, mais elle ne peut pas garantir qu'un effet externe ne se produise qu'une seule fois. L'application doit toujours disposer d'identifiants stables, d'écritures de base de données protégées, de règles de versionnement des politiques et de mécanismes de réconciliation lorsque les composants divergent.

Databricks transforme la durabilité des agents en système testable

L'implémentation de référence traite un agent comme un processus métier de longue durée, et non comme une session de chat temporaire.

L'implémentation de référence suit une demande de prêt, de la collecte des éléments probants jusqu'à une décision humaine. Son agent exécute séparément des vérifications de crédit, de revenus, de ratio dette-revenu et de politiques de souscription.

L'exemple utilise des demandeurs et des fournisseurs simulés ; il ne traite donc pas de véritables demandes de prêt. Ce choix maintient l'expérience centrée sur le comportement d'exécution plutôt que sur les performances d'un modèle de crédit.

Un demandeur type présente un score de crédit de 665 et un indicateur de retard de paiement non significatif. L'agent recueille les éléments, évalue les seuils de politique propres à l'objet du prêt et génère une recommandation. Il ne peut pas prendre la décision finale d'octroi.

Un souscripteur doit approuver, refuser ou demander des informations complémentaires. Cette dernière option prolonge le même dossier dans un autre tour d'agent, en conservant les éléments précédents et la justification du réviseur.

Le scénario est volontairement plus complexe qu'une simple requête à un modèle. Un worker peut s'arrêter après l'achèvement de plusieurs vérifications. Une écriture en base de données peut être validée avant que son achèvement ne soit signalé à Temporal. Un réviseur peut laisser le dossier ouvert pendant plusieurs jours.

Un navigateur obsolète peut aussi soumettre une commande dépassée après que le dossier a évolué. Pendant ce temps, la politique de souscription peut changer sans déploiement correspondant de l'application.

Ces situations font émerger six exigences concrètes : récupération, nouvelles tentatives contrôlées, attentes durables, visibilité opérationnelle, gouvernance à l'exécution et historique d'audit. Une transcription seule ne peut pas y répondre.

Une transcription enregistre les messages, mais pas nécessairement l'intégralité du flux de contrôle. Elle n'indique pas automatiquement quelle opération s'est achevée, quel résultat a été accepté ou quelle commande a fait progresser le processus.

L'implémentation attribue donc à chaque exécution de prêt un Workflow Temporal. Un Workflow est un flux de contrôle durable dont l'historique enregistré permet à un autre worker de reconstruire son état.

Les appels aux modèles, aux bases de données et aux outils de souscription s'exécutent sous forme d'Activities. Une Activity est une opération réessayable dont le résultat peut être enregistré dans l'Event History du Workflow.

Les réponses des réviseurs arrivent sous forme de Signals, des commandes asynchrones transmises à un Workflow ouvert. Temporal peut conserver cette attente sans réserver un processus worker pendant plusieurs jours.

React et FastAPI assurent l'application destinée aux utilisateurs. Ils lancent les exécutions, affichent les éléments probants, répertorient les dossiers et soumettent les décisions de revue. Temporal Cloud stocke l'historique d'exécution et distribue les tâches aux workers.

Lakebase Postgres héberge la projection destinée à l'application. Une projection est une représentation interrogeable de l'état actuel du workflow, construite à partir des mises à jour produites durant l'exécution.

Unity Catalog reste la source des règles de souscription. Une table synchronisée en continu rend ces règles disponibles via Lakebase, afin que les workers puissent lire une politique actualisée sans déploiement de code.

Cette architecture rend le comportement des agents face aux défaillances visible et reproductible. Elle transforme la durabilité, d'une promesse générale, en un ensemble de contrats précis de récupération et de cohérence.

Toutefois, la démo ne fusionne pas ces contrats dans une seule base de données. Temporal et Lakebase restent des systèmes distincts, et l'écart entre eux soulève les questions d'ingénierie les plus difficiles.

La mémoire d'un agent n'est pas son état d'exécution

Un agent durable a besoin de décisions enregistrées concernant le flux de contrôle, et pas seulement de messages stockés ou de mémoires récupérées.

De nombreux systèmes d'agents présentent la persistance comme de la mémoire. Ils sauvegardent une conversation, récupèrent des documents antérieurs ou placent un résultat intermédiaire dans une base de données. Ces capacités aident les modèles à retrouver du contexte, mais elles ne reconstruisent pas l'exécution.

Supposons qu'un worker termine une vérification de crédit puis s'arrête. Un remplaçant doit déterminer si le résultat a été enregistré, si une nouvelle tentative est sûre et quelle opération doit être exécutée ensuite.

C'est un problème de flux de contrôle. Il comprend les Activities planifiées, les résultats terminés, les minuteurs, les commandes humaines acceptées, les tentatives de nouvelle exécution et le cycle de revue en cours.

Temporal stocke ces informations dans un Event History ordonné. Lors de la relecture, le code du workflow consomme ces événements enregistrés et reconstruit des variables telles que les éléments probants, l'utilisation de jetons et l'état de la revue.

Un résultat d'Activity enregistré est renvoyé lors de la relecture au lieu d'être exécuté de nouveau. Ainsi, une vérification de crédit terminée ou une réponse de modèle enregistrée reste figée pour cette exécution de workflow.

Un achèvement non enregistré présente un cas différent. Un fournisseur de modèles peut finir de traiter une requête juste avant que le worker perde sa connectivité. Si Temporal ne reçoit jamais le résultat, il peut planifier une autre tentative.

Cette limite importe car les appels aux modèles ne sont ni dépourvus d'effets secondaires ni garantis déterministes. Une seconde réponse peut différer de la première, même avec une entrée identique.

La démonstration attribue des politiques de nouvelle tentative à chaque type d'opération. Les Activities de modèles autorisent jusqu'à quatre tentatives dans une fenêtre schedule-to-close de trois minutes.

Les Activities d'outils autorisent jusqu'à trois tentatives avec un délai start-to-close de 60 secondes. Les Activities Lakebase autorisent jusqu'à cinq tentatives avec un délai start-to-close de 15 secondes.

Ces chiffres décrivent la configuration de l'exemple, et non des valeurs par défaut universelles pour la production. Les équipes doivent définir les limites de nouvelle tentative selon le comportement des fournisseurs, les objectifs de latence, les modes de défaillance et les conséquences en aval.

Le modèle d'exécution durable de Temporal traite la récupération des processus en préservant l'historique nécessaire à la relecture. Il ne rend pas automatiquement un paiement, un e-mail, une mutation de base de données ou une requête à un modèle sûrs à répéter.

Chaque opération externe nécessite un contrat d'idempotence. L'idempotence signifie que des tentatives répétées convergent vers un résultat voulu unique plutôt que de produire des effets dupliqués.

La démo de prêt construit ce contrat avec des identifiants déterministes. Une exécution, un message, un appel d'outil, un événement, un cycle de revue et une décision de réviseur reçoivent chacun une identité stable.

Les clés primaires et contraintes d'unicité de Postgres empêchent les nouvelles tentatives de créer un nombre illimité de copies. Les upserts permettent à une tentative répétée de cibler la même ligne logique.

Les mises à jour protégées ajoutent une couche supplémentaire. Elles n'autorisent que des transitions d'état valides, comme le passage d'un appel d'outil en attente à son achèvement sans rouvrir un enregistrement terminal.

Pourtant, même une mise à jour protégée doit être interprétée avec soin. PostgreSQL peut affecter zéro ligne sans déclencher d'erreur lorsque la cible a déjà atteint un état terminal.

L'article Databricks reconnaît que l'enveloppe Activity actuelle ne transforme pas toujours ce résultat de zéro ligne en échec. Le code de production devrait inspecter l'état stocké avant de le considérer comme inoffensif.

Ce détail distingue une référence d'ingénierie utile d'un modèle de production achevé. L'orchestration durable fournit le mécanisme de récupération, tandis que les développeurs d'applications définissent encore des règles métier sûres.

Le même principe s'applique au-delà de la souscription. Les fournisseurs de paiement ont besoin de clés d'idempotence, les systèmes d'e-mail d'identifiants de messages stables et les outils non pris en charge d'enregistrements de réconciliation.

Les équipes qui construisent un agent interne ont également besoin d'une couche d'éléments probants consultable. Une base de connaissances d'ingénierie structurée peut aider les personnes à examiner la documentation, les décisions et le contexte technique entourant ces workflows.

La leçon plus large est précise : la mémoire aide un modèle à se souvenir, tandis que l'exécution durable aide un système à continuer. Les agents de production ont généralement besoin des deux, mais ils ne sont pas interchangeables.

Créer des agents durables avec Temporal et Lakebase en séparant les responsabilités

La conception fonctionne parce que Temporal et Lakebase détiennent des formes de vérité différentes pour des consommateurs différents.

Temporal possède la vérité d'exécution. Son historique détermine quelles tâches se sont achevées, quels minuteurs se sont déclenchés, quels Signals sont arrivés et ce qu'un worker en relecture doit faire ensuite.

Lakebase possède la vue actuelle de l'application. Il stocke l'état des exécutions, les messages, les éléments probants des outils, les enregistrements de revue, les événements opérationnels, les métadonnées de recommandation et les métriques de nouvelle tentative dans des tables relationnelles.

Cette répartition permet à l'interface utilisateur d'interroger les dossiers en cours avec des schémas SQL ordinaires. Les réviseurs peuvent trouver les dossiers en attente, examiner une recommandation ou comparer les mesures opérationnelles entre exécutions.

Les éléments probants apparaissent avant la clôture d'un Workflow. Dès que la recherche de politique est terminée, le résultat structuré devient disponible avec les seuils, les valeurs réelles, les résultats des règles, la justification et la source de la politique.

C'est important dans les systèmes soumis à une revue humaine. Un réviseur ne devrait pas devoir attendre la fin de tout le processus pour consulter les éléments à l'origine d'une recommandation.

L'application utilise deux schémas Lakebase. Le schéma agent_ops contient les enregistrements opérationnels, tandis que agent_policy contient une copie en lecture seule de la politique de souscription gouvernée.

Chaque Activity écrit des lignes avec des identifiants alignés sur le Workflow. Une nouvelle tentative peut donc mettre à jour le même enregistrement logique pendant que la projection de base de données rattrape son retard.

Lakebase ne devient pas partie intégrante de la relecture Temporal. Cette frontière empêche les requêtes ordinaires de l'application de décider de l'exécution du workflow, mais elle signifie aussi que les mises à jour ne sont pas atomiques entre les deux systèmes.

Un événement Temporal peut être enregistré alors qu'une projection Lakebase accuse temporairement un retard. Une écriture en base de données peut aussi être validée avant que Temporal n'enregistre l'achèvement correspondant de l'Activity.

L'architecture accepte cet écart et s'appuie sur la cohérence éventuelle. La cohérence éventuelle signifie que des vues distinctes peuvent brièvement diverger, mais convergent grâce aux nouvelles tentatives et aux écritures déterministes.

C'est une conception raisonnable pour les tableaux de bord et les listes de dossiers. Elle exige davantage de prudence lorsqu'une vue de base de données sert à valider une commande affectant l'état métier.

Lakebase apporte un accès Postgres familier et une indexation orientée application. Son modèle de base de données opérationnelle prend également en charge la mémoire des agents, l'état actuel et les charges de travail de service de fonctionnalités.

Son calcul peut s'adapter automatiquement dans des limites configurées. La mise à l'échelle jusqu'à zéro peut suspendre le calcul inactif, bien que la première requête après une période d'inactivité puisse subir une latence d'activation.

Ces fonctionnalités de base de données aident à gérer un trafic d'agents irrégulier. Elles n'éliminent pas la planification de capacité, les limites de connexion, la configuration des pools ou les tests de récupération.

La trajectoire des politiques est tout aussi importante. Unity Catalog stocke des seuils propres à chaque finalité, notamment des règles de crédit et de ratio d’endettement. Une table synchronisée en continu présente ces valeurs dans Lakebase.

Les responsables des politiques peuvent mettre à jour la source sans redéployer le worker ni l’API. Une consultation ultérieure peut lire les règles propagées depuis Postgres.

Cela évite d’intégrer chaque seuil métier dans le code applicatif. Cela soulève également une question de temporalité des politiques, à laquelle la couche d’orchestration doit répondre explicitement.

Un dossier ouvert doit-il conserver les règles appliquées à son ouverture, ou adopter une politique plus récente lors d’un tour ultérieur ? Les deux choix ont des conséquences sur la cohérence, l’auditabilité et le traitement des clients.

La démonstration enregistre les seuils appliqués et la source avec la recommandation. Ces éléments permettent aux examinateurs de reconstituer quelle politique a éclairé un résultat donné.

Lorsque Lakebase n’est pas disponible, l’exemple peut utiliser une politique de test et enregistrer ce mécanisme de repli. L’article note à juste titre qu’un workflow réglementé pourrait plutôt échouer de manière sécurisée.

Ce choix ne peut pas être délégué à une bibliothèque de nouvelles tentatives. Les responsables produit, les équipes conformité et les ingénieurs doivent définir si une politique obsolète ou de repli est légalement et opérationnellement acceptable.

Le chemin de retour proposé utilise Lakebase Change Data Feed. Une fois activé, il peut capturer les mutations de la base de données et les publier dans des tables d’historique Delta gérées par Unity Catalog.

Databricks indique que le flux regroupe les modifications environ toutes les 15 secondes. Cet intervalle convient à l’audit et à l’analyse rétrospectives, tandis que l’application lit directement l’état courant depuis Lakebase.

Cependant, le dépôt ne fait que préparer ses schémas pour cette voie. Il ne contient pas d’exécution observée de bout en bout du flux dans l’environnement cible.

Construire des agents durables avec Temporal et Lakebase exige donc trois frontières nettes : la vérité d’exécution, la vérité opérationnelle et l’historique analytique gouverné.

Le modèle devient précieux lorsque ces frontières sont explicites. Il devient dangereux lorsque les équipes supposent que le mot « durable » signifie que chaque composant est toujours d’accord.

La revue humaine met en lumière le compromis de cohérence

L’attente de l’underwriter montre pourquoi la durabilité doit inclure l’identité des commandes, le rejet des états obsolètes et une validation indépendante du Workflow.

Après que le modèle a produit une recommandation, le Workflow crée un identifiant de revue à partir de l’exécution et du tour en cours. Il enregistre la revue en attente dans Lakebase et passe à AWAITING_REVIEW.

Temporal attend alors une condition sans mobiliser un worker. Le Workflow ouvert peut survivre au remplacement d’un processus pendant que l’humain prend le temps de répondre.

L’API accepte une approbation, un refus ou une demande d’informations complémentaires. Elle vérifie d’abord si Lakebase indique toujours que la revue concernée est en attente.

Elle compare également l’identifiant de revue envoyé avec le cycle de revue actuel. Une divergence produit un conflit au lieu de transmettre une décision manifestement obsolète.

Cette vérification préalable dans la base de données améliore l’expérience utilisateur, mais elle ne fait pas autorité. La projection Lakebase peut être en retard sur Temporal, notamment lorsqu’une Activity effectue de nouvelles tentatives.

L’API envoie donc la commande sous forme de Signal, et le Workflow la valide à nouveau par rapport à l’état d’exécution. Les décisions dupliquées ou obsolètes sont ignorées au sein du flux de contrôle durable.

Cette seconde vérification est essentielle. Un onglet de navigateur peut rester ouvert pendant qu’un autre examinateur fait avancer le dossier, ou une requête antérieure peut arriver après le début d’un nouveau cycle de revue.

Une réponse HTTP 202 confirme uniquement que Temporal a reçu le Signal. Elle ne signifie pas que le Workflow a accepté la décision métier.

Le client doit actualiser la vue Lakebase pour observer l’état résultant. Cette distinction évite de confondre un accusé de réception de transport avec une approbation de prêt.

Lorsque le Workflow accepte une décision, une Activity Lakebase idempotente la persiste. L’approbation ou le refus termine l’exécution.

Une demande d’informations complémentaires reprend l’exécution. Le motif de l’examinateur devient un nouveau message utilisateur, le tour avance et la recommandation suivante reçoit un nouvel identifiant de revue.

Ce mécanisme donne à chaque cycle de revue une frontière stable. Il rend également visible le compromis principal : l’état applicatif réactif est distinct de l’état d’exécution faisant autorité.

Les équipes doivent concevoir le système en tenant compte de désaccords temporaires. Les interfaces doivent communiquer clairement les commandes en attente, les conflits, les projections retardées et les actions obsolètes rejetées.

Les tableaux de bord opérationnels doivent également distinguer une attente intentionnelle d’une panne. Un dossier en attente d’un underwriter est sain, tandis qu’une Activity bloquée dans des tentatives répétées nécessite une intervention.

La démonstration expose des métriques aux niveaux du Workflow, du tour et de la tentative d’Activity. Les opérateurs peuvent inspecter l’historique Temporal, interroger l’état Lakebase et vérifier séparément l’environnement du worker.

Cette séparation aide à diagnostiquer si un retard provient de la revue humaine, de la disponibilité du modèle, de l’authentification à la base de données ou d’un outil défaillant.

Elle ajoute également une surface opérationnelle. Les équipes doivent surveiller Temporal, Lakebase, les déploiements de workers, les pools de connexions, les tâches de synchronisation et les contrats qui les relient.

L’authentification introduit une autre préoccupation de longue durée. Le client Lakebase utilise OAuth de machine à machine et actualise son pool de connexions avant l’expiration des identifiants temporaires de base de données.

Sans rotation des identifiants, un worker peut échouer selon un calendrier prévisible même si son Workflow demeure récupérable. Un flux de contrôle durable ne rend pas utilisables des connexions expirées.

Les développeurs qui comparent les frameworks d’agents durables devraient donc regarder au-delà de la prise en charge des points de contrôle. Ils devraient se demander comment les commandes sont identifiées, comment les effets de bord sont dédupliqués et où réside l’état faisant autorité.

Ils devraient aussi tester délibérément les interactions obsolètes. Ouvrez deux sessions de revue, faites avancer l’une d’elles, puis soumettez l’ancienne décision.

Une implémentation correcte devrait rejeter ou ignorer en toute sécurité cette commande. Elle devrait conserver suffisamment d’éléments pour expliquer le résultat ultérieurement.

L’exemple du prêt est utile parce qu’il relie ces détails à une décision importante. L’approbation humaine n’est pas une pause décorative entre deux appels au modèle.

Il s’agit d’une transition d’état avec identité, autorisation, contexte de politique et exigences d’audit. Cela en fait un test de durabilité plus exigeant qu’un assistant conversationnel redémarrant après une erreur.

La démonstration ne prouve pas l’aptitude à la production

Databricks présente une architecture crédible, mais ses propres éléments de preuve laissent sans réponse la conformité du crédit, l’échelle et la validation complète de la boucle de données.

Le dépôt indique que 21 tests réussissent et couvrent le séquencement des workflows, le comportement de revue, la construction OAuth, la persistance idempotente, les contrats de métriques, le démarrage de l’API et les paramètres des workers.

Un exercice de récupération après crash utilise un fournisseur déterministe. Il arrête l’exécution du worker et vérifie que la progression enregistrée survit au retour du processus.

Ces tests étayent l’affirmation limitée de durabilité. Ils montrent que le flux de contrôle et les contrats de persistance de l’exemple se comportent comme prévu face à certaines défaillances sélectionnées.

Ils ne valident pas l’agent comme système de prêt. Les dossiers des demandeurs et les réponses des fournisseurs sont des données de test, tandis que le fournisseur scripté par défaut évite une dépendance à un modèle en direct.

Le dépôt n’établit ni la qualité d’un modèle de prêt, ni la conformité réglementaire, la sécurité en production, la disponibilité régionale ou les performances à grande échelle. Databricks indique directement ces limites.

L’exercice de crash local s’est également exécuté avec Lakebase désactivé. Il isole la récupération Temporal, mais ne vérifie pas la récupération sur l’ensemble du chemin de données intégré.

De même, le chemin Change Data Feed demeure une tâche d’activation et de déploiement. L’exemple prépare les tables, mais ne montre pas l’arrivée observée de l’historique de bout en bout.

Change Data Feed était en Public Preview au moment de la parution de l’article. Ce statut de préversion compte pour les équipes qui exigent des engagements de support matures ou une couverture régionale validée.

La base de données et le Workflow ne partagent pas de transaction. Des identifiants stables et les nouvelles tentatives assurent la convergence, mais les équipes ont toujours besoin de réconciliation en cas de divergence prolongée ou inattendue.

Un processus de réconciliation de production devrait repérer les Workflows sans projections correspondantes. Il devrait aussi détecter les effets de base de données validés dont les résultats d’Activity ne sont jamais entrés dans l’Event History.

La synchronisation des politiques mérite le même examen. Une exécution ultérieure peut consommer une politique mise à jour sans déploiement, mais une exécution ouverte nécessite une règle documentée de version de politique.

Le comportement de repli crée un autre risque. La démonstration peut substituer une politique de test lorsque Lakebase est désactivé ou qu’une ligne de politique n’est pas disponible.

Ce comportement facilite le développement local, mais un repli silencieux serait inacceptable dans de nombreux environnements réglementés. Le système enregistre le repli, mais les responsables des politiques doivent décider si l’exécution doit se poursuivre.

Les performances restent non testées dans les éléments de preuve publiés. Les charges de travail des agents peuvent générer des écritures en rafales, de longs historiques, des transcriptions volumineuses et des files de revue inégales.

La rétention de l’historique Temporal, le volume de tentatives, la latence du modèle, la concurrence des workers, les limites de connexion à la base de données et les mises à jour de projection influencent tous le comportement du système.

L’autoscaling de Lakebase peut répondre à la demande, mais les nouvelles connexions et les données réchauffées restent importantes. Le passage à zéro peut également troquer l’efficacité en période d’inactivité contre une latence de réveil.

Les exigences de sécurité vont au-delà de TLS et des identifiants temporaires. Une véritable plateforme d’underwriting nécessiterait une autorisation stricte, des contrôles sur les données sensibles, des règles de rétention et des frontières d’accès à l’audit.

La recommandation du modèle requiert aussi une gouvernance indépendante. L’enregistrement des éléments de preuve et de la politique améliore la traçabilité, mais n’établit pas que la recommandation est équitable ou exacte.

Une évaluation complète testerait le raisonnement lié aux actions défavorables, les éléments de preuve manquants, les données contradictoires des fournisseurs, les changements de politique et les tentatives de manipulation des entrées d’outils.

Elle testerait également des incidents opérationnels traversant les frontières entre composants. Citons notamment une synchronisation de politique indisponible, des projections retardées, une rotation partielle des identifiants et des fournisseurs externes indisponibles.

L’architecture doit donc être lue comme conçue pour la production, et non comme certifiée pour la production. Cette distinction renforce la référence, car elle rend visible le travail restant.

Databricks a montré comment répartir les responsabilités entre l’orchestration, le stockage opérationnel et les données gouvernées. Il n’a pas supprimé la nécessité de valider chaque contrat sous une charge réelle.

Trois signaux montreront si ce modèle tient la route

Les prochains éléments de preuve devraient tester la récupération intégrée, la cohérence des politiques et l’adoption au-delà de la démonstration contrôlée d’underwriting.

Le premier signal est un déploiement Change Data Feed observé de bout en bout. Le système publié prépare les tables opérationnelles, mais laisse inachevées l’activation du flux et la vérification de sa destination.

Une validation réussie devrait suivre une exécution, des éléments de preuve des outils à la revue humaine puis à l’historique géré par Unity Catalog. Elle devrait également documenter le délai, les doublons, les changements de schéma et la récupération après interruption.

Ce résultat renforcerait l’affirmation selon laquelle l’activité opérationnelle peut revenir dans l’historique analytique gouverné. Une dépendance persistante à une voie non vérifiée affaiblirait l’histoire complète de la boucle de données.

Le deuxième signal est une étude publique de charge et de défaillance utilisant Lakebase tout au long du test de récupération. Elle devrait inclure des crashs de workers, des nouvelles tentatives de base de données, la rotation des identifiants et le retard de projection.

Des résultats utiles présenteraient le comportement de complétion, la distribution des tentatives, le rejet des commandes obsolètes et le temps nécessaire à la convergence de l’état applicatif.

Cela testerait l’architecture comme système combiné plutôt que de valider la récupération Temporal de manière isolée. Cela révélerait également où apparaissent les limites de mise à l’échelle ou les goulots d’étranglement opérationnels.

Le troisième signal est l’adoption dans un véritable workflow avec revue humaine. Le prêt n’est qu’une démonstration, mais des exigences similaires existent dans le traitement des sinistres, les achats, la réponse aux incidents de sécurité et les approbations réglementées.

Un déploiement crédible devrait expliquer comment il versionne les politiques, réconcilie les états, contrôle le comportement de repli et audite les interventions humaines. Ces pratiques comptent davantage que le fournisseur de modèle choisi.

Les preuves issues d’un tel déploiement étayeraient le jugement central de l’article. Les agents durables sont des applications distribuées dont les défaillances doivent être explicitement modélisées.

Un déploiement qui réduit la durabilité à des points de contrôle de conversation indiquerait l’inverse. Il laisserait les effets de bord, les longues attentes et les politiques changeantes en dehors du contrat de reprise.

Pour les développeurs, la question immédiate n’est pas de savoir si chaque agent a besoin de Temporal et Lakebase. De nombreuses tâches courtes et en lecture seule ne justifient pas deux systèmes gérés et une couche de projection.

La question est de savoir si un agent peut survivre à son worker, modifier un état externe, attendre des personnes ou appliquer une politique qui évolue indépendamment. Ces caractéristiques créent le besoin d’une exécution durable.

Si elles décrivent votre système, examinez l’architecture de l’agent, reproduisez ses tests de crash et remettez en question chaque effet de bord réessayable. Testez ensuite ce qui se passe lorsque la vérité d’exécution et la vérité opérationnelle divergent temporairement.

C’est la norme pratique pour les équipes qui cherchent à créer des agents durables avec Temporal et Lakebase. Commencez par un flux de travail à conséquences, définissez l’autorité de chaque système et faites des preuves de reprise un élément de l’examen produit.