Diop Daily #142 — October 2026

October 17, 2026 · 9 min read · durable execution · agent runtime · institutional continuity

The Agent Needs a Life Between Turns

A short conversation can make an agent look complete. A long task reveals whether it has a life. Research, software maintenance, procurement, publishing, and administrative work all contain pauses that exceed a context window: a person must approve a step, a tool returns an uncertain result, a worker disappears, a provider changes, or the institution has to wait for an external event. The system must preserve the work through that interval and resume with the right state.

This is the distinction between a session and an institution. A session remembers what was said. An institutional runtime must know what was intended, what was committed, what effect may have happened, what remains uncertain, who may authorize the next step, and which project state a new worker should inherit. Long-horizon agency therefore depends on durable execution: a runtime that makes continuation a designed property rather than a lucky recovery from a transcript.

An agent becomes dependable when its work can outlive the process that happened to carry it.

The turn is a unit of risk

Temporal’s October 8 account of running the Pi coding agent on its workflow engine gives the problem a useful shape. The experiment places agent turns across a fleet of workers and kills workers while they are operating. A later worker can continue from the shared session and project state without automatically repeating an interrupted tool call. The report describes request identifiers, checkpoints, recorded outcomes, and project snapshots as parts of the recovery design. These are implementation claims from one system, not proof that all agent runtimes now recover safely.

The architectural lesson is broader than the product. A model call is a computation. A tool call can be a consequence. Sending a payment, editing a repository, issuing a notice, changing a record, or publishing a page may alter the world before the agent receives a result. If the worker dies after the external system accepts the request but before the local runtime records the response, a blind retry can duplicate the consequence.

A durable turn should therefore carry a continuity record with at least:

Intent: the requested outcome, the principal who asked for it, and the constraints that bound the work.
Checkpoint: the exact state from which the next worker may continue, including model, tools, policy, and project versions.
Effect status: whether an external action has not started, is known to have completed, failed, or has an unknown outcome.
Authority: the approval, delegation, budget, and expiry conditions that remain valid for the next step.
Recovery rule: the read-before-retry, compensation, escalation, or human decision required when the outcome cannot be known automatically.

This record turns a crash from an improvisation into a bounded decision. It also preserves a distinction that many demos erase: the agent may understand the task while the runtime remains unable to prove what happened.

Unknown outcomes need their own state

Traditional retry logic often assumes that a failed request did not take effect. External systems make that assumption unsafe. A network timeout can occur after a bank accepted a transfer. A deployment command can lose its connection after the platform created the release. A message service can acknowledge delivery while the local process is still waiting. The correct next action may be a lookup, a reconciliation, a compensation, or a pause. It may not be another invocation.

The runtime needs a vocabulary for this ambiguity. “Unknown” is a useful state because it stops the system from converting missing evidence into permission. It tells the next worker to inspect the external effect, consult a request identifier, compare the ledger, or ask an authorized person. An institution that cannot represent uncertainty will eventually pay for it through duplicate actions, contradictory records, and difficult disputes.

This is where durable execution separates itself from simple task queues. A queue can make work available again. A continuity runtime must know which step was safe to repeat, which side effect requires an idempotency key, which result can be reused, and which decision needs a human. The commercial value sits in the semantics of continuation, not in the number of jobs a dashboard displays.

Handoff is a capability, not a failure mode

Google’s October description of google/adk-recipes includes Horizon, a reference harness for long-horizon agents. The account names cross-session memory, per-user sandboxes, secrets management, guardrails, resumable multi-step tasks, and evaluation rubrics for memory recall, injection resistance, tool selection, and halting. The same repository is organized for developers and coding assistants, with machine-readable manifests and runnable tests. The point is not that a curated recipe becomes production infrastructure by appearing in a repository. The point is that long-lived work requires a bundle of state, boundaries, and tests that a single prompt cannot carry.

Google’s October 13 report on an eleven-hour performance run across a roughly 205,000-line codebase makes the economic pressure visible. The team gave an agent a long-running objective, repository-specific skills, maintainer conventions, benchmarks, and a full test suite. The report says the run produced measurable optimizations, while earlier work that lacked the repository’s conventions introduced changes that reviewers rejected. Long runs create value when the runtime carries the institution’s method into the work and leaves evidence that another operator can review.

Handoff should preserve more than a chat transcript. A new worker needs the project tree, the last accepted checkpoint, pending approvals, evaluation results, unresolved questions, cost budget, and the rules that define an acceptable change. A provider change should preserve the task’s meaning even if the model’s style changes. A human interruption should leave a clean place to return, rather than forcing a second person to reconstruct the entire history from logs.

African institutions need continuation under their own conditions

Durable execution has a direct sovereignty dimension. Institutions across Africa often operate across intermittent connectivity, distributed teams, shared devices, mobile payment rails, changing languages, and uneven access to compute. A workflow that assumes one continuously connected process and one foreign service can make local capacity fragile even when the model itself is capable.

A publisher may need an agent to prepare a multilingual edition across several review sessions. A cooperative may collect field records offline and reconcile them when a connection returns. A public office may pause a case until a human authority is reachable. A laboratory may move a job from an expensive cloud worker to a local machine without losing its evidence. In each case, the institution needs to own the continuation record: the authority, state, language, correction path, and conditions that define legitimate resumption.

NIST’s AI Agent Standards Initiative places authentication, identity infrastructure, open protocols, and security evaluations in one strategic frame. Durable execution adds the time dimension to that frame. The question is not only which agent is acting and what it is allowed to do. It is also which agent is resuming, from which checkpoint, with which evidence, after which interruption. Portability means carrying that answer across workers and providers.

Where the investable surface is widening

The commercial object is the durable execution layer: infrastructure that preserves intent, state, effects, authority, and recovery semantics so long-running agent work can continue without silently repeating its consequences.

Durable workflow engines: runtimes that checkpoint agent steps, pause for signals, resume across workers, and keep execution history independent from one process.
Effect ledgers: systems that bind external actions to request identifiers, idempotency keys, observed outcomes, and compensation procedures.
Handoff fabrics: portable state packages carrying project files, policy versions, approvals, evaluation fixtures, budgets, and unresolved decisions across runtimes.
Interruption and approval controls: mechanisms that stop a workflow at a consequential boundary and return it to an authorized human without losing its place.
Recovery testing: chaos and replay services that kill workers, delay tools, change providers, corrupt connections, and measure whether the institution can resume safely.

Underwriting can begin with operational measurements: the percentage of steps with explicit checkpoints; the share of external effects carrying idempotency and reconciliation evidence; the time required to resume after worker loss; the rate of duplicate side effects in fault injection; the proportion of workflows that can move between providers; and the number of human approvals that return to the exact decision boundary rather than restarting the entire task.

A durable runtime earns its position by lowering the cost of interruption without hiding the risk of continuation. Its moat is the accumulated knowledge of how institutions pause, reconcile, approve, compensate, and resume. That knowledge is closer to operating infrastructure than to a model feature, and it remains useful when models, clouds, and interface styles change.

Build the life between turns

An institution can test this layer with one workflow that already suffers from expensive interruption: a software release, a research import, a procurement approval, a multilingual publication, or a service case. Define the principal, the desired outcome, the irreversible effects, the approval points, and the external records that can confirm each effect.

Checkpoint before every consequential tool call, including the request identifier and the authority that permits it.
Record the effect as unknown when the runtime loses contact before it can confirm the outcome.
Require the next worker to reconcile the external state before it retries or compensates.
Move the work across a second worker or provider while preserving the project state, policies, fixtures, and pending decisions.
Kill the worker at different points and measure whether the resumed task reaches the same controlled decision without duplicating side effects.

The test should include human interruption, delayed messages, revoked authority, changed dependencies, partial connectivity, and a language variant that changes the interpretation of a request. A workflow that survives only the clean path has demonstrated automation. A workflow that can explain its pause, preserve its uncertainty, and continue under a new operator has demonstrated institutional capacity.

The agentic economy will be described through faster models and broader tool access. Its serious infrastructure will be judged in the quiet interval after a process dies and before the work resumes. The institution that owns that interval owns the difference between an agent that can act and an agent whose work can be carried forward.

Sources

L’agent a besoin d’une vie entre deux tours

Une conversation courte peut donner l’impression qu’un agent est complet. Une tâche longue révèle s’il a une vie. La recherche, la maintenance logicielle, les achats, l’édition et le travail administratif comportent tous des pauses qui dépassent une fenêtre de contexte : une personne doit approuver une étape, un outil renvoie un résultat incertain, un worker disparaît, un fournisseur change ou l’institution doit attendre un événement extérieur. Le système doit préserver le travail pendant cet intervalle et reprendre avec le bon état.

C’est la différence entre une session et une institution. Une session se souvient de ce qui a été dit. Un runtime institutionnel doit savoir ce qui était prévu, ce qui a été engagé, quel effet a pu se produire, ce qui reste incertain, qui peut autoriser l’étape suivante et quel état du projet un nouveau worker doit recevoir. L’action à long horizon dépend donc de l’exécution durable : un runtime qui fait de la continuité une propriété conçue, au lieu de la laisser à une récupération chanceuse depuis une transcription.

Un agent devient fiable lorsque son travail peut survivre au processus qui le portait à cet instant.

Le tour est une unité de risque

Le récit publié par Temporal le 8 octobre sur l’exécution de l’agent de programmation Pi sur son moteur de workflows donne une forme utile au problème. L’expérience répartit les tours de l’agent sur une flotte de workers et interrompt ces workers pendant leur travail. Un worker ultérieur peut continuer à partir de l’état partagé de la session et du projet sans répéter automatiquement un appel d’outil interrompu. Le texte décrit les identifiants de requête, les points de contrôle, les résultats enregistrés et les instantanés du projet comme des éléments du dispositif de reprise. Ce sont des affirmations d’implémentation propres à un système, et non la preuve que tous les runtimes agentiques récupèrent désormais sans risque.

La leçon architecturale dépasse le produit. Un appel de modèle est un calcul. Un appel d’outil peut produire une conséquence. Envoyer un paiement, modifier un dépôt, émettre un avis, changer un dossier ou publier une page peut transformer le monde avant que l’agent ne reçoive un résultat. Si le worker meurt après l’acceptation de la demande par le système externe mais avant l’enregistrement local de la réponse, une nouvelle tentative aveugle peut dupliquer la conséquence.

Un tour durable devrait donc porter au minimum un dossier de continuité :

Intention : résultat demandé, mandant qui l’a demandé et contraintes qui bornent le travail.
Point de contrôle : état exact depuis lequel le prochain worker peut continuer, avec les versions du modèle, des outils, de la politique et du projet.
État de l’effet : action externe non commencée, connue comme achevée, échouée ou de résultat inconnu.
Autorité : approbation, délégation, budget et conditions d’expiration encore valides pour l’étape suivante.
Règle de reprise : lecture avant nouvelle tentative, compensation, escalade ou décision humaine nécessaire lorsque le résultat ne peut pas être établi automatiquement.

Ce dossier transforme une panne en décision bornée. Il préserve aussi une distinction effacée par de nombreuses démonstrations : l’agent peut comprendre la tâche alors que le runtime est incapable de prouver ce qui s’est passé.

Les résultats inconnus ont besoin de leur propre état

La logique classique des nouvelles tentatives suppose souvent qu’une demande défaillante n’a pas produit d’effet. Les systèmes externes rendent cette hypothèse dangereuse. Un délai réseau peut survenir après l’acceptation d’un virement par une banque. Une commande de déploiement peut perdre sa connexion après la création de la release par la plateforme. Un service de messages peut confirmer la livraison tandis que le processus local attend encore. L’action correcte peut être une consultation, un rapprochement, une compensation ou une pause. Ce ne sera pas forcément une nouvelle invocation.

Le runtime a besoin d’un vocabulaire pour cette ambiguïté. « Inconnu » est un état utile, car il empêche le système de transformer l’absence de preuve en permission. Il indique au worker suivant qu’il doit examiner l’effet externe, consulter un identifiant de requête, comparer le registre ou interroger une personne autorisée. Une institution incapable de représenter l’incertitude finira par la payer au moyen d’actions dupliquées, de dossiers contradictoires et de litiges difficiles.

C’est ici que l’exécution durable se distingue d’une simple file de tâches. Une file peut rendre le travail disponible à nouveau. Un runtime de continuité doit savoir quelle étape peut être répétée sans danger, quel effet secondaire exige une clé d’idempotence, quel résultat peut être réutilisé et quelle décision demande un humain. La valeur commerciale réside dans la sémantique de la reprise, non dans le nombre de tâches affichées par un tableau de bord.

Le transfert est une capacité, pas un échec

La description publiée par Google en octobre au sujet de google/adk-recipes inclut Horizon, un harnais de référence pour les agents à long horizon. Le texte cite la mémoire intersessions, les environnements isolés par utilisateur, la gestion des secrets, les garde-fous, les tâches séquentielles reprenables et les grilles d’évaluation portant sur le rappel, la résistance à l’exfiltration par injection, la sélection d’outils et l’arrêt. Le même dépôt est organisé pour les développeurs et les assistants de programmation, avec des manifestes lisibles par machine et des tests exécutables. Le point n’est pas qu’une recette publiée devient une infrastructure de production par sa seule présence dans un dépôt. Le point est que le travail durable exige un ensemble d’état, de frontières et de tests qu’un prompt unique ne peut pas porter.

Le rapport publié par Google le 13 octobre sur une exécution de onze heures dans une base de code d’environ 205 000 lignes rend la pression économique visible. L’équipe a donné à un agent un objectif de longue durée, des compétences propres au dépôt, les conventions des mainteneurs, des benchmarks et une suite complète de tests. Le rapport indique que l’exécution a produit des optimisations mesurables, tandis qu’un travail antérieur dépourvu des conventions du dépôt avait introduit des changements rejetés par les reviewers. Les longues exécutions créent de la valeur lorsque le runtime porte la méthode de l’institution dans le travail et laisse des preuves qu’un autre opérateur peut examiner.

Le transfert doit préserver davantage qu’une transcription. Un nouveau worker a besoin de l’arbre du projet, du dernier point de contrôle accepté, des approbations en attente, des résultats d’évaluation, des questions non résolues, du budget de coût et des règles qui définissent un changement acceptable. Un changement de fournisseur doit préserver le sens de la tâche même si le style du modèle change. Une interruption humaine doit laisser un lieu propre où revenir, sans contraindre une seconde personne à reconstruire toute l’histoire à partir des journaux.

Les institutions africaines ont besoin d’une continuité selon leurs propres conditions

L’exécution durable possède une dimension directe de souveraineté. Les institutions africaines travaillent souvent avec une connectivité intermittente, des équipes distribuées, des appareils partagés, des rails de paiement mobile, des langues changeantes et un accès inégal au calcul. Un workflow qui suppose un processus connecté en permanence et un service étranger unique peut fragiliser la capacité locale, même lorsque le modèle est compétent.

Un éditeur peut avoir besoin d’un agent pour préparer une édition multilingue au fil de plusieurs sessions de revue. Une coopérative peut recueillir des dossiers de terrain hors ligne et les rapprocher au retour de la connexion. Un service public peut suspendre un dossier jusqu’à ce qu’une autorité humaine soit joignable. Un laboratoire peut déplacer une tâche d’un worker cloud coûteux vers une machine locale sans perdre ses preuves. Dans chaque cas, l’institution doit posséder le dossier de continuité : l’autorité, l’état, la langue, la voie de correction et les conditions qui définissent une reprise légitime.

L’AI Agent Standards Initiative du NIST place l’authentification, l’infrastructure d’identité, les protocoles ouverts et les évaluations de sécurité dans un même cadre stratégique. L’exécution durable ajoute la dimension temporelle à ce cadre. La question ne porte pas seulement sur l’agent qui agit et sur ce qu’il est autorisé à faire. Elle porte aussi sur l’agent qui reprend, le point de contrôle depuis lequel il reprend, les preuves dont il dispose et l’interruption qui a précédé. La portabilité consiste à transporter cette réponse entre workers et fournisseurs.

Là où la surface d’investissement s’élargit

L’objet commercial est la couche d’exécution durable : une infrastructure qui préserve l’intention, l’état, les effets, l’autorité et les règles de reprise afin que le travail agentique à long horizon puisse continuer sans répéter silencieusement ses conséquences.

Moteurs de workflows durables : runtimes qui enregistrent les étapes, se mettent en pause sur signal, reprennent entre workers et conservent l’historique hors d’un seul processus.
Registres d’effets : systèmes qui relient les actions externes aux identifiants de requête, aux clés d’idempotence, aux résultats observés et aux procédures de compensation.
Fabrics de transfert : paquets d’état portables transportant fichiers de projet, versions de politiques, approbations, fixtures d’évaluation, budgets et décisions en attente entre runtimes.
Contrôles d’interruption et d’approbation : mécanismes qui arrêtent un workflow à une frontière importante et le rendent à une personne autorisée sans perdre sa position.
Tests de reprise : services de chaos et de reconstitution qui arrêtent des workers, retardent des outils, changent de fournisseur, perturbent les connexions et mesurent la reprise sûre de l’institution.

La souscription peut commencer par des mesures opératoires : pourcentage d’étapes disposant d’un point de contrôle explicite ; part des effets externes munis d’une preuve d’idempotence et de rapprochement ; temps nécessaire à la reprise après la perte d’un worker ; taux d’effets secondaires dupliqués lors d’une injection de panne ; proportion de workflows capables de changer de fournisseur ; et nombre d’approbations humaines qui reviennent à la frontière de décision exacte au lieu de redémarrer toute la tâche.

Un runtime durable gagne sa place en réduisant le coût de l’interruption sans masquer le risque de la reprise. Son avantage vient du savoir accumulé sur la manière dont les institutions suspendent, rapprochent, approuvent, compensent et reprennent. Ce savoir relève davantage de l’infrastructure opératoire que d’une fonction de modèle, et il reste utile lorsque les modèles, les clouds et les styles d’interface changent.

Construire la vie entre deux tours

Une institution peut tester cette couche avec un workflow qui souffre déjà d’interruptions coûteuses : release logicielle, import de recherche, approbation d’achat, publication multilingue ou dossier de service. Définissez le mandant, le résultat recherché, les effets irréversibles, les points d’approbation et les registres externes capables de confirmer chaque effet.

Créez un point de contrôle avant chaque appel d’outil important, avec l’identifiant de requête et l’autorité qui le permet.
Enregistrez l’effet comme inconnu lorsque le runtime perd le contact avant de pouvoir confirmer le résultat.
Obligez le worker suivant à rapprocher l’état externe avant toute nouvelle tentative ou compensation.
Déplacez le travail vers un second worker ou fournisseur en conservant l’état du projet, les politiques, les fixtures et les décisions en attente.
Arrêtez le worker à différents moments et mesurez si la tâche reprise atteint la même décision contrôlée sans dupliquer les effets.

Le test doit inclure une interruption humaine, des messages retardés, une autorité révoquée, des dépendances modifiées, une connectivité partielle et une variante linguistique qui change l’interprétation d’une demande. Un workflow qui ne survit qu’au chemin propre a démontré une automatisation. Un workflow qui peut expliquer sa pause, préserver son incertitude et continuer sous la responsabilité d’un nouvel opérateur a démontré une capacité institutionnelle.

L’économie agentique sera décrite à travers des modèles plus rapides et un accès élargi aux outils. Son infrastructure sérieuse sera jugée dans l’intervalle silencieux qui suit la mort d’un processus et précède la reprise du travail. L’institution qui possède cet intervalle possède la différence entre un agent capable d’agir et un agent dont le travail peut être porté plus loin.