Diop Daily #133 — October 2026

October 6, 2026 · 10 min read · outcome accounting · agent economics · sovereignty

Who Pays for the Second Attempt?

The first attempt is the seductive unit of AI economics. A model receives a prompt, calls a tool, returns an answer, and produces a clean line on a usage dashboard. The institution pays for tokens and declares a workflow. The second attempt is where the institution discovers what it actually bought: a retry after a malformed call, a human review after an uncertain answer, a correction after a polished error, a translation check, or a delay that changes the value of the result.

This is why the price of intelligence cannot be read from the price of a token. OpenAI’s July guidance for AI investment recommends measuring “cost per accepted outcome,” including model and tool use, attempts, completion rate, latency, and human review. Its September usage-analytics guidance connects spend with task categories, model choice, speed, training, and business outcomes. Stanford’s 2026 AI Index reports that productivity gains are largest in structured, measurable work where outputs are easy to monitor, while compute spending and infrastructure costs continue to rise. These sources point toward one accounting problem: an AI system has an economic unit only when an institution can define acceptance and count the work required to reach it.

The cheap answer is the answer that reaches an accepted state without hiding the cost of getting there.

The token is an input, not a result

Token pricing is attractive because it is precise. A provider can state a rate, a dashboard can record consumption, and a buyer can compare models on a familiar axis. That precision becomes misleading when the workflow has consequential failure modes. A low-cost model that requires three retries and twenty minutes of review may be more expensive than a higher-cost model that produces a usable result on the first pass. A fast response that creates a dispute can consume more institutional capacity than a slower response that arrives with the evidence needed for approval.

The full cost of an agentic task has several components:

Inference: the model calls, context, reasoning budget, and output tokens used to produce a proposal.
Tool work: API calls, browser actions, retrieval, storage, payment attempts, and external services touched by the proposal.
Correction: retries, re-planning, data repair, translation review, human checking, and recovery after a failed action.
Time: latency, queueing, escalation, and the interval during which a person or process waits for a usable state.
Consequence: the cost of a wrong publication, a missed deadline, a duplicated payment, an exposed record, or a decision that must be reversed.

The last two categories are often invisible in model dashboards. They live in calendars, support queues, finance systems, editorial corrections, and the attention of people who were never counted as part of the AI workflow. An institution that measures only inference is measuring the machine’s appetite while leaving the organization’s metabolism unpriced.

Acceptance is a governed state

“Accepted outcome” sounds simple until a real institution has to define it. A support answer may be accepted when the customer’s issue is resolved and the record is correctly updated. A code change may be accepted when tests pass, review is complete, security checks are green, and the change can be maintained by the team. A research brief may be accepted when its sources are accessible, its claims are bounded, its rights are clear, and another reader can follow the reasoning.

Each definition contains a threshold, an authority, and a route for disagreement. Acceptance belongs to the institution that bears the consequence. A provider can report that a model generated an answer; the buyer has to decide whether the answer can enter the work.

This changes the design of observability. A serious outcome ledger should join the model trace to the institutional state:

the task, owner, principal, and intended outcome;
the model, context, tools, and policy version used in the attempt;
the first result and every retry, escalation, or correction;
the reviewer, test, source, or business rule that established acceptance;
the time, financial cost, human capacity, and residual uncertainty carried forward.

This record does more than calculate a margin. It tells the organization which workflows are becoming reliable, which ones are consuming hidden labor, and which forms of intelligence are worth reserving for difficult cases. It also gives the institution a way to compare providers without confusing a cheap proposal with a cheap operation.

The second attempt is where local conditions appear

Imported benchmarks often describe an idealized workflow: stable connectivity, abundant compute, a dominant language, standardized records, and a reviewer who can intervene quickly. The second attempt exposes the conditions that the benchmark omitted. A request may need to be translated into a local language. A mobile connection may drop during a payment call. A document may be stored in a format that the retrieval system cannot parse. A community institution may require a human authority that the imported workflow has no field to represent.

For African institutions, these conditions are part of the economic object. The Institute for Security Studies has argued that African AI sovereignty depends on investment in power, connectivity, computing, cooling, and data ecosystems. The consequence for agent systems is practical: an outcome ledger must include the scarce resources that make a workflow possible. Compute imported from elsewhere, bandwidth paid at the edge, language review performed by a local expert, and recovery work carried by a small institution all belong in the cost of the result.

The ledger should account for these constraints accurately, without romanticizing them. A workflow that appears cheap because it excludes translation, local validation or intermittent connectivity transfers its cost to the institution that has the least margin for absorbing it. Measurement becomes an instrument of sovereignty when it makes these transfers visible.

From usage analytics to institutional learning

Usage analytics tell a buyer where activity is happening. Outcome accounting asks what the activity changed. The difference is the difference between a meter and a memory.

Suppose an institution sees that one team consumes far more model credits than another. The first reaction might be to reduce access or route the team to a cheaper model. A better investigation asks what work the credits represent. Are the extra attempts caused by poor source data, an ambiguous policy, an inadequate tool contract, a language gap, or a workflow whose acceptance test is too weak? Each answer requires a different intervention.

The ledger should therefore preserve cause, not merely volume. A useful classification might record:

productive exploration that has not yet reached a production workflow;
repeatable work whose cost and quality are within an agreed envelope;
avoidable loops caused by weak instructions, tools, context, or routing;
necessary review for high-consequence work;
unresolved failure that requires a change to the institution rather than another prompt.

Over time, this classification becomes a map of operating knowledge. It shows where a small model is sufficient, where a frontier model earns its cost, where a human decision is the actual bottleneck, and where the organization should repair its records or policies before buying more intelligence. Capital can then follow proven capacity rather than raw activity.

Where the investable surface is widening

The commercial object is the outcome ledger: infrastructure that attributes the full cost of accepted machine work across models, tools, people, time, language, and consequence. It sits beside usage analytics but reaches into the state that makes work count.

Outcome accounting systems: ledgers that join model traces, workflow states, approvals, correction events, and accepted results into a cost-per-outcome view.
Correction-aware routing: allocators that choose models and tools based on expected total cost, completion probability, review burden, latency, and consequence rather than token price alone.
Acceptance registries: versioned definitions of what counts as good enough for a domain, with owners, tests, evidence requirements, and appeal paths.
Capacity and review markets: systems that schedule scarce human expertise, local-language validation, domain review, and recovery work as measurable production resources.
Sovereign cost observability: infrastructure that exposes the power, connectivity, localization, data-hosting, and provider-dependence costs carried by an institution or region.

Underwriting can begin with measures that a buyer can inspect: cost per accepted outcome; acceptance rate on the first attempt; correction minutes per task; retry causes; time from proposal to approval; local-language quality variance; percentage of outcomes with complete evidence; and the share of work whose cost remains portable when a provider changes. These measures do not guarantee a good business. They make the business legible enough to govern.

The strongest products in this layer will sell disciplined allocation. They will help a finance leader distinguish productive demand from waste, a technical leader decide where to spend evaluation effort, a public institution protect scarce human review, and an investor assess whether machine capacity is becoming reusable operating leverage. Their defensibility will come from domain-specific acceptance data and from the accumulated record of why a workflow succeeds or needs another attempt.

Build the ledger before scaling the call volume

An institution can begin with one workflow that matters. Define the accepted state in language the owner recognizes. Record the model and tool costs. Add human review, delay, translation, failed calls, and correction. Classify every second attempt. Revisit the ledger after a fixed period and ask which intervention reduced the full cost without lowering the quality bar.

Then test the ledger itself by changing the model, removing a tool, introducing a slower connection, translating the task, requiring a different reviewer and forcing a refusal. The system should preserve enough evidence to show whether the workflow became cheaper because the machine improved, because a human absorbed more work, or because a consequence disappeared from the measurement.

The market will continue to advertise intelligence in tokens, parameters, and benchmark scores. Institutions will buy something more concrete: accepted work under a cost and risk envelope. The second attempt is where that envelope becomes visible. Count it honestly, and AI economics can become a discipline of institutional learning rather than a ceremony around usage.

Sources

Qui paie la deuxième tentative ?

La première tentative est l’unité séduisante de l’économie de l’IA. Un modèle reçoit une consigne, appelle un outil, renvoie une réponse et produit une ligne propre dans un tableau d’usage. L’institution paie les tokens et déclare un workflow. La deuxième tentative révèle ce qu’elle a réellement acheté : une nouvelle tentative après un appel mal formé, une revue humaine après une réponse incertaine, une correction après une erreur bien présentée, une vérification de traduction ou un retard qui modifie la valeur du résultat.

C’est pourquoi le prix de l’intelligence ne peut pas être lu dans le prix d’un token. Les recommandations publiées par OpenAI en juillet pour l’investissement dans l’IA proposent de mesurer le « coût par résultat accepté », en incluant l’usage du modèle et des outils, les tentatives, le taux d’achèvement, la latence et la revue humaine. Ses recommandations de septembre sur l’analyse des usages relient les dépenses aux catégories de tâches, au choix du modèle, à la vitesse, à la formation et aux résultats d’entreprise. L’AI Index 2026 de Stanford indique que les gains de productivité sont les plus importants dans les travaux structurés et mesurables dont les sorties sont faciles à surveiller, tandis que les dépenses de calcul et d’infrastructure continuent d’augmenter. Ces sources convergent vers un problème comptable : un système d’IA possède une unité économique seulement lorsqu’une institution peut définir l’acceptation et compter le travail nécessaire pour l’atteindre.

La réponse bon marché est celle qui atteint un état accepté sans dissimuler le coût du chemin.

Le token est une entrée, pas un résultat

Le prix des tokens séduit parce qu’il est précis. Un fournisseur peut annoncer un tarif, un tableau peut enregistrer la consommation et un acheteur peut comparer les modèles selon un axe familier. Cette précision devient trompeuse lorsque le workflow comporte des modes d’échec lourds de conséquences. Un modèle peu coûteux qui exige trois nouvelles tentatives et vingt minutes de revue peut coûter plus cher qu’un modèle plus cher par token qui produit un résultat utilisable au premier passage. Une réponse rapide qui déclenche un litige peut consommer davantage de capacité institutionnelle qu’une réponse plus lente accompagnée des preuves nécessaires à l’approbation.

Le coût complet d’une tâche agentique comporte plusieurs éléments :

Inférence : appels du modèle, contexte, budget de raisonnement et tokens de sortie utilisés pour produire une proposition.
Travail des outils : appels d’API, actions dans un navigateur, récupération, stockage, tentatives de paiement et services externes touchés par la proposition.
Correction : nouvelles tentatives, nouvelle planification, réparation des données, revue de traduction, contrôle humain et reprise après une action échouée.
Temps : latence, mise en file, escalade et intervalle pendant lequel une personne ou un processus attend un état utilisable.
Conséquence : coût d’une publication erronée, d’une échéance manquée, d’un paiement dupliqué, d’un dossier exposé ou d’une décision à inverser.

Les deux dernières catégories restent souvent invisibles dans les tableaux de modèles. Elles vivent dans les calendriers, les files d’assistance, les systèmes financiers, les corrections éditoriales et l’attention de personnes qui n’ont jamais été comptées comme faisant partie du workflow IA. Une institution qui mesure seulement l’inférence mesure l’appétit de la machine en laissant le métabolisme de l’organisation sans prix.

L’acceptation est un état gouverné

« Résultat accepté » paraît simple jusqu’au moment où une institution réelle doit le définir. Une réponse d’assistance peut être acceptée lorsque le problème du client est résolu et que le dossier est correctement mis à jour. Une modification de code peut être acceptée lorsque les tests réussissent, que la revue est terminée, que les contrôles de sécurité sont au vert et que l’équipe peut maintenir la modification. Une note de recherche peut être acceptée lorsque ses sources sont accessibles, ses affirmations délimitées, ses droits clairs et son raisonnement suivi par un autre lecteur.

Chaque définition contient un seuil, une autorité et une voie de désaccord. L’acceptation appartient à l’institution qui porte la conséquence. Un fournisseur peut signaler qu’un modèle a produit une réponse ; l’acheteur doit décider si cette réponse peut entrer dans le travail.

Cette distinction transforme la conception de l’observabilité. Un registre sérieux des résultats devrait relier la trace du modèle à l’état institutionnel :

la tâche, le responsable, le mandant et le résultat visé ;
le modèle, le contexte, les outils et la version de la politique utilisés lors de la tentative ;
le premier résultat et chaque nouvelle tentative, escalade ou correction ;
le réviseur, le test, la source ou la règle métier qui a établi l’acceptation ;
le temps, le coût financier, la capacité humaine et l’incertitude résiduelle reportés.

Ce dossier ne sert pas seulement à calculer une marge. Il indique à l’organisation quels workflows deviennent fiables, lesquels consomment du travail caché et quelles formes d’intelligence méritent d’être réservées aux cas difficiles. Il donne aussi à l’institution un moyen de comparer les fournisseurs sans confondre une proposition bon marché avec une opération bon marché.

La deuxième tentative révèle les conditions locales

Les benchmarks importés décrivent souvent un workflow idéalisé : connectivité stable, calcul abondant, langue dominante, dossiers standardisés et réviseur capable d’intervenir rapidement. La deuxième tentative expose les conditions que le benchmark a laissées de côté. Une demande doit parfois être traduite dans une langue locale. Une connexion mobile peut tomber pendant un appel de paiement. Un document peut être conservé dans un format que le système de récupération ne sait pas analyser. Une institution communautaire peut exiger une autorité humaine pour laquelle le workflow importé n’a aucun champ.

Pour les institutions africaines, ces conditions appartiennent à l’objet économique. L’Institute for Security Studies a soutenu que la souveraineté africaine en matière d’IA dépend d’investissements dans l’électricité, la connectivité, le calcul, le refroidissement et les écosystèmes de données. La conséquence pour les systèmes agentiques est concrète : un registre des résultats doit inclure les ressources rares qui rendent un workflow possible. Le calcul importé, la bande passante payée à la périphérie, la revue linguistique réalisée par un expert local et le travail de reprise porté par une petite institution font tous partie du coût du résultat.

Il ne s’agit pas de créer une comptabilité séparée qui romantise la contrainte. Il s’agit d’en établir une qui soit exacte. Un workflow qui paraît bon marché parce qu’il exclut la traduction, la validation locale ou la connectivité intermittente transfère son coût à l’institution qui a le moins de marge pour l’absorber. La mesure devient un instrument de souveraineté lorsqu’elle rend ces transferts visibles.

Des analyses d’usage à l’apprentissage institutionnel

Les analyses d’usage indiquent où se trouve l’activité. La comptabilité des résultats demande ce que cette activité a changé. La différence sépare un compteur d’une mémoire.

Supposons qu’une institution constate qu’une équipe consomme beaucoup plus de crédits de modèle qu’une autre. La première réaction peut être de réduire l’accès ou d’orienter l’équipe vers un modèle moins cher. Une meilleure enquête demande quel travail représentent ces crédits. Les tentatives supplémentaires viennent-elles de mauvaises données sources, d’une politique ambiguë, d’un contrat d’outil insuffisant, d’un manque linguistique ou d’un test d’acceptation trop faible ? Chaque réponse appelle une intervention différente.

Le registre doit donc conserver la cause, pas seulement le volume. Une classification utile peut distinguer :

l’exploration productive qui n’a pas encore atteint un workflow de production ;
le travail répétable dont le coût et la qualité restent dans une enveloppe convenue ;
les boucles évitables causées par des consignes, outils, contextes ou routages faibles ;
la revue nécessaire pour un travail à fortes conséquences ;
l’échec non résolu qui demande une modification de l’institution plutôt qu’une nouvelle consigne.

Avec le temps, cette classification devient une carte du savoir opératoire. Elle montre où un petit modèle suffit, où un modèle de frontière justifie son coût, où une décision humaine est le véritable goulot d’étranglement et où l’organisation doit réparer ses dossiers ou ses politiques avant d’acheter davantage d’intelligence. Le capital peut alors suivre la capacité démontrée plutôt que l’activité brute.

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

L’objet commercial est le registre des résultats : une infrastructure qui attribue le coût complet du travail machine accepté entre modèles, outils, personnes, temps, langues et conséquences. Il se situe à côté des analyses d’usage, mais atteint l’état qui permet au travail de compter.

Systèmes de comptabilité des résultats : registres reliant les traces des modèles, les états des workflows, les validations, les corrections et les résultats acceptés dans une vue du coût par résultat.
Routage conscient de la correction : allocateurs choisissant les modèles et les outils selon le coût total attendu, la probabilité d’achèvement, la charge de revue, la latence et la conséquence, plutôt que selon le seul prix du token.
Registres d’acceptation : définitions versionnées de ce qui est suffisamment bon pour un domaine, avec responsables, tests, exigences de preuve et voies de recours.
Marchés de capacité et de revue : systèmes qui planifient l’expertise humaine rare, la validation en langue locale, la revue de domaine et le travail de reprise comme des ressources de production mesurables.
Observabilité souveraine des coûts : infrastructure exposant les coûts d’électricité, de connectivité, de localisation, d’hébergement des données et de dépendance aux fournisseurs supportés par une institution ou une région.

La souscription peut commencer par des mesures inspectables : coût par résultat accepté, taux d’acceptation à la première tentative, minutes de correction par tâche, causes des reprises, temps entre proposition et approbation, variation de qualité selon la langue locale, pourcentage de résultats avec preuves complètes et part du travail dont le coût reste portable lors d’un changement de fournisseur. Ces mesures ne garantissent pas une bonne entreprise. Elles rendent l’entreprise assez lisible pour être gouvernée.

Les produits les plus solides de cette couche vendront une allocation disciplinée. Ils aideront un responsable financier à distinguer la demande productive du gaspillage, un responsable technique à décider où investir dans l’évaluation, une institution publique à protéger sa revue humaine rare et un investisseur à déterminer si la capacité machine devient un levier opérationnel réutilisable. Leur défense viendra des données d’acceptation propres au domaine et du relevé accumulé des raisons pour lesquelles un workflow réussit ou demande une nouvelle tentative.

Construire le registre avant d’augmenter les appels

Une institution peut commencer par un workflow qui compte. Définissez l’état accepté dans une langue que le responsable reconnaît. Enregistrez les coûts du modèle et des outils. Ajoutez la revue humaine, le retard, la traduction, les appels échoués et la correction. Classez chaque deuxième tentative. Relisez le registre après une période fixe et demandez quelle intervention a réduit le coût complet sans abaisser le seuil de qualité.

Testez ensuite le registre lui-même en changeant de modèle, en retirant un outil, en introduisant une connexion plus lente, en traduisant la tâche, en exigeant un autre réviseur et en forçant un refus. Le système doit conserver assez de preuves pour montrer si le workflow est devenu moins cher parce que la machine s’est améliorée, parce qu’une personne a absorbé davantage de travail ou parce qu’une conséquence a disparu de la mesure.

Le marché continuera de faire la publicité de l’intelligence en tokens, en paramètres et en scores de benchmark. Les institutions achèteront quelque chose de plus concret : du travail accepté dans une enveloppe de coût et de risque. La deuxième tentative rend cette enveloppe visible. Comptons-la honnêtement, et l’économie de l’IA pourra devenir une discipline d’apprentissage institutionnel plutôt qu’une cérémonie autour de l’usage.